On 22/06/15 09:02 AM, Sean Dague wrote:
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?
i coded it under the impression of the latter -- the "swift not using oslo" part made me have to make a few adjustments. i'd be happy to accommodate both options if it's possible.

--
gord


__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to