[openstack-dev] [ceilometer] can we get ceilometermiddleware to use a config file instead of transport_url?

Doug Hellmann doug at doughellmann.com
Mon Jun 22 19:43:40 UTC 2015


Excerpts from Sean Dague's message of 2015-06-22 13:30:44 -0400:
> 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.

I explained this on IRC, but I'll repeat it here as a more permanent
record.

We should not have the ceilometer middleware (re)initializing
oslo.config. That combines 2 concerns (setting up configuration and
doing whatever ceilometermiddleware is already doing) in one piece
of middleware, and that will make it more difficult to combine
ceilometermiddleware with other middleware that also wants access
to the configuration settings.

If the application code isn't setting up oslo.config, then we should
have another piece of middleware do just that one thing. It can take
options from paste's config to tell it how to do that work, and then
other middleware later in the pipeline can rely on oslo.config being set
up and the config files being loaded.

Doug



More information about the OpenStack-dev mailing list