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

Sean Dague sean at dague.net
Mon Jun 22 17:30:44 UTC 2015


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



More information about the OpenStack-dev mailing list