most swift daemons don't honor log_name

Then again, it may be better to just fix this in get_logger by treating name as a fallback option only.

In addition to having to update less files, it'd probably make more sense. If those daemons actually intended to override a user specified log_name setting it would have been clearer to force them to write:
conf['log_name'] = 'object-updater'
self.logger = get_logger(conf)

More than likely the intent is to provide a default log_name if conf doesn't define one - i.e.
self.logger = get_logger(conf, conf.get('log_name', 'object-updater'))

But in this case, there's no reason not to just do that for them inside get_logger, similarly to how run_wsgi accepts a default port to use only if there isn't already one specified in the conf.

I grepped around for calls to get_logger - I think it's probably safe for get_logger to just be updated so that name defaults to swift and is only used when the conf is missing the 'log_name' key.

Ah, I'm glad I found this bug; now I don't have to make my own. I've got no idea what's really going on under the covers, but I do know that setting log_name in my [filter:section] didn't do what I expected at all. The local_conf passed to filter_factory doesn't even have log_name in it!

A little more info: paste-deploy conf stuff is broken, in my opinion. If you specify a setting in [DEFAULT] and in a subsection, only the default value comes through. This is without any swift code present.

The only way to get the proxy to use anything other than LOG_LOCAL0 is to put the config setting in the [DEFAULT] section instead of the [app:proxy-server] section as the documentation indicates.

If this is not going to be corrected by the BEXAR release then the documentation should be changed to reflect the current behavior.

Ah, figured a bit more out:

So if you have this conf file:

[DEFAULT]
name1 = globalvalue
name2 = globalvalue

[pipeline:main]
pipeline = myapp

[app:myapp]
use = egg:mypkg#myapp
name1 = localvalue
set name2 = localvalue
name3 = localvalue

The app_factory will get:

global {'__file__': '/etc/mypkg/wsgi.conf', 'here': '/etc/mypkg', 'name2': 'localvalue', 'name1': 'globalvalue'}
local {'name3': 'localvalue'}

So, if an item is specified in the [DEFAULT] section, it can only ever be in that section. If you specify it in the subsection plainly, it'll be ignored. If you specify it in the subsection, but prefix that with 'set', it'll override the value in the [DEFAULT] section, but note that the value is still in the [DEFAULT] section, just overridden -- it won't be in the subsection still. Any items only in the subsection will remain there.

I think this is going to keep screwing with people no matter the documentation because it's screwy. (But, of course, we should try our best in the docs still.)

I would say we should just reparse the damned conf file in our app_factory and filter_factory methods, but there's no way to know which subsection is yours. The user can config several instances of your app/filter (multiple auths, for instance) and paste.deploy doesn't give you enough information in the _factory call.

Looks like we'll just have to field support questions on this for a long while...

I have a working branch linked which documents the paste.deploy configuration file habits; but I still need to work through how we interact with it in the Swift code and make sure that's all okay and understood.

I think I got it all sorted out. A combination of knowing how the paste.deploy config should work (updated docs) and fixing our get_logger code.