[openstack-dev] [ceilometer] can we get ceilometermiddleware to use a config file instead of transport_url?
blk at acm.org
Mon Jun 22 21:45:11 UTC 2015
On Mon, Jun 22, 2015 at 2:43 PM, Doug Hellmann <doug at doughellmann.com>
> 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
> > > really think it should depend on oslo_config.
> > Ok, here is where I'm confused. Ceilometer middleware *already* depends
> > on oslo_config.
> > And it does stuff with it here:
> > But regardless, it uses oslo_messaging, which uses oslo_config. So it
> > seems like the only issue at hand is middleware retriggering conf
> > 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
> 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.
Whatever is decided for this, I assume it'll also apply to the auth_token
middleware, since that uses oslo.config, too. We already have a bug and
a proposed change that isn't passing jenkins.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev