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 <[email protected]> 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. _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
