Open Stack

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.

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)

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.

Doug



>
> It seems to me that having this separation of concerns in oslo.messaging
> would be good idea. My plan is to move out the configuration object out
> of the basic object, like I did in the first patch.
>
> I don't plan to break the configuration handling or so, I just think it
> should be handled in a separate, individually testable part of the code.
>
> Ultimately, this would allow oslo.messaging to not be 'oslo' only, and
> just being friendly with oslo.config and therefore OpenStack. A goal I
> wish we'd had in more oslo library. :)
>
> If you think this is a bad idea, well, feel free to mark the blueprint
> as so and I'll drop the work.
>
>
> ¹  https://review.openstack.org/56068
>
> ²
> https://blueprints.launchpad.net/ceilometer/+spec/messaging-decouple-cfg
>
> --
> Julien Danjou
> ;; Free Software hacker ; independent consultant
> ;; http://julien.danjou.info
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> 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/20131118/79ee9ba1/attachment.html>