<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, May 20, 2013 at 12:48 PM, Flavio Percoco <span dir="ltr"><<a href="mailto:flavio@redhat.com" target="_blank">flavio@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
The new API has an optional parameter called transport_url[0], which is<br>
used to specify the connection parameters for the chosen transport.<br>
This url is being passed to the driver instance, which has to parse<br>
it and, eventually, merge it with its own connection parameters -<br>
depending on the implementation. [1]<br>
<br>
My question is: Do we really need it?<br>
<br>
I agree it is useful for some implementations but, it can also make it<br>
a bit more difficult for other implementations. For example, in qpid's<br>
case, it could either use a single host or have a list of hosts for<br>
HA. If transport_url is specified it will be necessary to either give<br>
priority to it or append its netloc to the qpid_hosts list. However,<br>
this behavior, most likely won't be the same for other<br>
implementations.<br>
<br>
I'm proposing to use rpc_backend and leave the connection parameters<br>
definition to the implementation.<br></blockquote><div><br></div><div style>The problem with that drivers specify all sorts of different options, so we can't have any sort of consistent API for creating a Transport. We need the constructors for driver classes to all take the same parameters, and for those parameters to encode everything about the transport -- no peeking at the config from within the driver -- so that applications that need to connect to multiple transports and targets (ceilometer, cells, etc.) can pass the required parameter(s) to create a new connection no matter which driver is being used.</div>
<div style><br></div><div style>IOW, instead of eliminating the URL option, the goal is to eliminate *all of the other* driver-specific options, and encode their values in the URLs. That leaves deployers able to configure everything that they can today, while Oslo only has to know about the "scheme" portion of the URL to figure out which driver to load. The drivers are also then free to interpret the other fields of the URL in whatever way makes the most sense for the driver.</div>
<div style><br></div><div style>For backwards compatibility, we would obviously need to have a way to read the existing configuration format and create the URLs to pass to the drivers, but that's not difficult.</div><div style>
<br></div><div style>Doug</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Also, from my experience with kombu managing connection URLs at a<br>
higher level can be painful for both the lib and backends<br>
implementation.<br>
<br>
Thoughts?<br>
<br>
Cheers,<br>
FF<br>
<br>
[0]<br>
<a href="https://github.com/markmc/oslo-incubator/blob/messaging/openstack/common/messaging/transport.py#L25" target="_blank">https://github.com/markmc/<u></u>oslo-incubator/blob/messaging/<u></u>openstack/common/messaging/<u></u>transport.py#L25</a><br>

<br>
[1]<br>
<a href="https://github.com/FlaPer87/oslo-incubator/blob/messaging-qpid/openstack/common/messaging/_drivers/impl_qpid.py#L45" target="_blank">https://github.com/FlaPer87/<u></u>oslo-incubator/blob/messaging-<u></u>qpid/openstack/common/<u></u>messaging/_drivers/impl_qpid.<u></u>py#L45</a><span class="HOEnZb"><font color="#888888"><br>

<br>
-- <br>
{ name: "Flavio Percoco",<br>
  gpg: "87112EC1",   internal: "8261386",<br>
  phone: "<a href="tel:%2B390687502386" value="+390687502386" target="_blank">+390687502386</a>",<br>
  irc: ["fpercoco", "flaper87"]}<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</font></span></blockquote></div><br></div></div>