Open Stack

Having _just_ done this, a couple of suggestions.

- If the middleware is NOT optional - that is, it provides some kind of a
fundamental component or specification of the API, like ETag caching, CORS,
or DB Session management - then the middleware should be added during the
app initialization routine, likely in the app factory. In this case, we
have tight control over the initialization order, and can make sure that
oslo.config is there first. Yay config.

- If the middleware _is_ optional, then I really feel this problem is
solved by pastedeploy's filter_factory pattern. It lets you define as many
required parameters as you want, and spits back a middleware instance. That
way you have the freedom to set whatever configuration options you want, or
omit the middleware altogether.

http://pythonpaste.org/deploy/#paste-filter-factory

Ultimately, what you should want is to ask a factory method for a thing
with some configuration options, and it spits an instance back at you. If
your project doesn't support pastedeploy, that limits your options
(ahem-ironic-ahem). Otherwise, it's really a team decision on whether
something is a 'Fundamental feature' or something that's optional.

In the case of Ceilometer? Sorry, but I think it's optional. You should be
able to run any component of openstack without ceilometer. So I don't
really think it should depend on oslo_config.

Michael

On Mon, Jun 22, 2015 at 7:59 AM Doug Hellmann <doug at doughellmann.com> wrote:

> 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
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150622/9f628651/attachment.html>