On 06/22/2015 01:15 PM, Michael Krotscheck wrote: > Having _just_ done this, a couple of suggestions. > > - If the middleware is NOT optional - that is, it provides some kind of > a fundamental component or specification of the API, like ETag caching, > CORS, or DB Session management - then the middleware should be added > during the app initialization routine, likely in the app factory. In > this case, we have tight control over the initialization order, and can > make sure that oslo.config is there first. Yay config. > > - If the middleware _is_ optional, then I really feel this problem is > solved by pastedeploy's filter_factory pattern. It lets you define as > many required parameters as you want, and spits back a middleware > instance. That way you have the freedom to set whatever configuration > options you want, or omit the middleware altogether. > > http://pythonpaste.org/deploy/#paste-filter-factory > > Ultimately, what you should want is to ask a factory method for a thing > with some configuration options, and it spits an instance back at you. > If your project doesn't support pastedeploy, that limits your options > (ahem-ironic-ahem). Otherwise, it's really a team decision on whether > something is a 'Fundamental feature' or something that's optional. > > In the case of Ceilometer? Sorry, but I think it's optional. You should > be able to run any component of openstack without ceilometer. So I don't > really think it should depend on oslo_config.
Ok, here is where I'm confused. Ceilometer middleware *already* depends on oslo_config. https://github.com/openstack/ceilometermiddleware/blob/master/ceilometermiddleware/swift.py#L42 And it does stuff with it here: https://github.com/openstack/ceilometermiddleware/blob/master/ceilometermiddleware/swift.py#L107 But regardless, it uses oslo_messaging, which uses oslo_config. So it seems like the only issue at hand is middleware retriggering conf parsing. Because the current model of requiring simultaneous code lands in oslo_messaging and ceilometermiddleware, and simultaneous config updates in every installer and config management system to configure the same thing in 2 different ways, does seem like a long term win. And honestly just prohibits most of what people seem to want to do with new messaging approaches. -Sean -- Sean Dague http://dague.net __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev