Open Stack

Hey Doug,

On Mon, 2013-11-18 at 11:29 -0500, Doug Hellmann wrote:
> On Mon, Nov 18, 2013 at 5:05 AM, Julien Danjou <julien at danjou.info> wrote:
> 
> > Hi Oslo developers,
> >
> > It seems my latest patch¹ on oslo.messaging scared Mark, so I'll try to
> > discuss it a bit on this mailing list as it is more convenient.
> >
> > I've created a blueprint² as requested by Mark. That seems necessary
> > since it will be spread on several patch.
> >
> > Now to the core. oslo.messaging API mixes usage of parameters and
> > configuration file object. Such as you have to provide a configuration
> > object for basic API usage, even if you don't have a configuration
> > object.
> >
> 
> IIRC, one of the concerns when oslo.messaging was split out was
> maintaining support for existing deployments with configuration files that
> worked with oslo.rpc. We had said that we would use URL query parameters
> for optional configuration values (with the required values going into
> other places in the URL), but that format wouldn't be backwards compatible
> if a deployment already had the other configuration settings listed
> individually.

I hadn't ever considered exposing all configuration options via the URL.
We have a lot of fairly random options, that I don't think you need to
configure per-connection if you have multiple connections in the one
application.

> One way to address that difference is to make the use of oslo.config an
> explicit step, before instantiating a Transport using a URL. Given a URL
> for a transport and an oslo.config object, an application could ask
> oslo.messaging to build a new URL containing all of the settings from the
> config that apply. Something like:
> 
>     from oslo.config import cfg
>     from oslo.messaging import config as om_config
>     from oslo.messaging import transport
> 
>     base_url = cfg.CONF.rpc_url
>     full_url = om_config.update_url_from_config(base_url, cfg.CONF)
> 
>     trans = transport.get_transport(full_url)

I don't think anyone would thanks us for the horrific URLs that would
result from this.

But if we did this, I'd just make it:

  from oslo.config import cfg
  from oslo.messaging import config as om_config

  transport = om_config.get_transport_from_config(cfg.CONF)

> update_url_from_config() would use the base_url to determine the driver,
> load the option definitions for that driver, then pull the values out of
> the config object and construct a new URL starting with the base and
> including the extra settings (thus preserving backwards-compatibility for
> the existing config files).
> 
> Applications that do not use oslo.config would just call get_transport().
> 
> As an alternative, and to preserve API compatibility with the existing
> release of oslo.messaging, we could just change get_transport() to allow
> the first argument to be None (instead of removing it entirely). When it is
> a valid config object, we would go through the steps we do now to get
> configuration options. When it is None, we would skip those steps.

API compatibility isn't yet important. We haven't done a first release
yet and no projects are using the library.

Mark.