<div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Nov 18, 2013 at 5:05 AM, Julien Danjou <span dir="ltr"><<a href="mailto:julien@danjou.info" target="_blank">julien@danjou.info</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Oslo developers,<br>
<br>
It seems my latest patch¹ on oslo.messaging scared Mark, so I'll try to<br>
discuss it a bit on this mailing list as it is more convenient.<br>
<br>
I've created a blueprint² as requested by Mark. That seems necessary<br>
since it will be spread on several patch.<br>
<br>
Now to the core. oslo.messaging API mixes usage of parameters and<br>
configuration file object. Such as you have to provide a configuration<br>
object for basic API usage, even if you don't have a configuration<br>
object.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">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.</div>
<div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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:</div>
<div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"> from oslo.config import cfg</div><div class="gmail_default" style="font-size:small"> from oslo.messaging import config as om_config</div>
<div class="gmail_default" style="font-size:small"> from oslo.messaging import transport</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"> base_url = cfg.CONF.rpc_url</div>
<div class="gmail_default" style="font-size:small"> full_url = om_config.update_url_from_config(base_url, cfg.CONF)</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">
trans = transport.get_transport(full_url)</div></div><div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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).</div>
<div class="gmail_default" style="font-size:small"></div><div class="gmail_default" style="font-size:small">Applications that do not use oslo.config would just call get_transport().</div><br></div><div><div class="gmail_default" style="font-size:small">
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.</div>
<div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Doug</div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
It seems to me that having this separation of concerns in oslo.messaging<br>
would be good idea. My plan is to move out the configuration object out<br>
of the basic object, like I did in the first patch.<br>
<br>
I don't plan to break the configuration handling or so, I just think it<br>
should be handled in a separate, individually testable part of the code.<br>
<br>
Ultimately, this would allow oslo.messaging to not be 'oslo' only, and<br>
just being friendly with oslo.config and therefore OpenStack. A goal I<br>
wish we'd had in more oslo library. :)<br>
<br>
If you think this is a bad idea, well, feel free to mark the blueprint<br>
as so and I'll drop the work.<br>
<br>
<br>
¹ <a href="https://review.openstack.org/56068" target="_blank">https://review.openstack.org/56068</a><br>
<br>
² <a href="https://blueprints.launchpad.net/ceilometer/+spec/messaging-decouple-cfg" target="_blank">https://blueprints.launchpad.net/ceilometer/+spec/messaging-decouple-cfg</a><br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Julien Danjou<br>
;; Free Software hacker ; independent consultant<br>
;; <a href="http://julien.danjou.info" target="_blank">http://julien.danjou.info</a><br>
</font></span><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>