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

Chris Dent chdent at redhat.com
Mon Jun 22 22:39:16 UTC 2015

On Mon, 22 Jun 2015, Sean Dague wrote:

> Could we deprecate the use of tranport_url in ceilometermiddleware and
> move to an actual oslo.config file somewhere instead? That would bring
> it in line with the rest of the RPC configuration for services, and
> ensure that all connections in a cluster have access to all the same
> options.

Replying on the top of the thread as it seems the responses have taken
us on a bit of a journey and I feel like instead of narrowing the goal
and figuring out what to do we've expanded scope and need to fix
everything. We can't fix everything so let's back up a bit and figure
out the original goal.

When you (Sean) and I first talked about this I understood the problem
to be that the use of just a URL was insufficient for covering the
configuration settings of the various messaging solutions and
additionally was not in keeping with convention.

I poked around in the code and discovered (as has been mentioned
elsewhere in the thread) the filter factory configuration settings are
merged into the oslo config.

So: is it appropriate, for now, to switch devstack:lib/swift to write
long form transport configuration in filter:ceilometer of swift
proxy's config (it's already writing plenty of other stuff) and kill
get_transport_url. ceilometermiddleware already calls get_transport
with a cfg.CONF that will be used for figuring out the transport url
if 'url' is None.

This doesn't solve every extant issue but it does solve some of them.

The ceilometer middleware, whether the old one that was in the
ceilometer tree or this newer one, has always struggled to exist
correctly in that weird intersection between swift and the rest of the
openstack universe, but exist it does in its not quite correct way.
Whatever we can do to make it exist better, even if its just a little
bit better, is good.

Chris Dent tw:@anticdent freenode:cdent

More information about the OpenStack-dev mailing list