[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 14:50:06 UTC 2015

Excerpts from Sean Dague's message of 2015-06-22 09:02:02 -0400:
> On 06/22/2015 08:58 AM, Doug Hellmann wrote:
> > Excerpts from Sean Dague's message of 2015-06-22 08:08:04 -0400:
> >> In extracting the contract for RPC backends in devstack (to have most of
> >> them live in plugins) one bit of an edge case was discovered.
> >>
> >> https://github.com/openstack-dev/devstack/blob/master/lib/swift#L388
> >>
> >> The connection to the RPC mechanism from ceilometermiddleware inside of
> >> swift uses a transport url instead of an oslo.messaging config block.
> >>
> >> ceilometermiddleware requires oslo.config and oslo.messaging, so it
> >> seems like it could use an oslo config block instead.
> >>
> >> One of the reasons why this seems like a better idea is that not all the
> >> properties of a messaging connection can be encoded in just a url today.
> >> For instance, Rabbit can specify heartbeating params -
> >> https://github.com/openstack-dev/devstack/blob/master/lib/rpc_backend#L282-L287,
> >> and zmq needs matchmaker info -
> >> https://github.com/openstack-dev/devstack/blob/master/lib/rpc_backend#L282-L287
> >>
> >> (Note: zmq is not currently able to be configured for swift + ceilometer
> >> today
> >> https://github.com/openstack-dev/devstack/blob/master/lib/rpc_backend#L282-L287
> >> and given what it needs in it's config, it's not clear that it would be
> >> reasonable to do so.)
> >>
> >> 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.
> > 
> > Swift doesn't use oslo.config, so we might need to make the middleware
> > support both configuration mechanisms.
> Right, but ceilometermiddleware does. Can't it load it's config from a
> side channel? Or is it only possible for it to load it's config from the
> same file as swift?

Library code that uses oslo.config relies on having an initialized
configuration object, which means something has specified the files
to be loaded, handled command line argument parsing, etc. We wouldn't
want the middleware doing that, because doing it properly requires
knowing the name of the application it's running in and what some
of the application-specific defaults should be, and those are usually
best left to the application.


More information about the OpenStack-dev mailing list