[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:55:32 UTC 2015
Excerpts from Doug Hellmann's message of 2015-06-22 10:50:06 -0400:
> 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.
We had a similar issue with the CORS middleware needing a config object.
Perhaps we need a piece of middleware to set up the config using
parameters coming in from the paste.ini (application, name, default
config file, etc.). If that middleware sets up the global config
instance, other middleware could be written to rely on it being earlier
in the pipline.
Doug
More information about the OpenStack-dev
mailing list