[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 13:02:02 UTC 2015

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?


Sean Dague

More information about the OpenStack-dev mailing list