<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, May 20, 2013 at 4:45 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">On 20/05/13 16:11 -0400, Doug Hellmann wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
On Mon, May 20, 2013 at 12:48 PM, Flavio Percoco <[1]<a href="mailto:flavio@redhat.com" target="_blank">flavio@redhat.com</a>><div class="im"><br>
wrote:<br>
<br>
The problem with that drivers specify all sorts of different options,<br>
so we can't have any sort of consistent API for creating a Transport.<br>
We need the constructors for driver classes to all take the same<br>
parameters, and for those parameters to encode everything about the<br>
transport -- no peeking at the config from within the driver -- so that<br>
applications that need to connect to multiple transports and targets<br>
(ceilometer, cells, etc.) can pass the required parameter(s) to create<br>
a new connection no matter which driver is being used.<br>
IOW, instead of eliminating the URL option, the goal is to eliminate<br>
*all of the other* driver-specific options, and encode their values in<br>
the URLs. That leaves deployers able to configure everything that they<br>
can today, while Oslo only has to know about the "scheme" portion of<br>
the URL to figure out which driver to load. The drivers are also then<br>
free to interpret the other fields of the URL in whatever way makes the<br>
most sense for the driver.<br>
For backwards compatibility, we would obviously need to have a way to<br>
read the existing configuration format and create the URLs to pass to<br>
the drivers, but that's not difficult.<br>
</div></blockquote>
<br>
But all drivers have a conf instance, right? I was thinking that using<br>
that conf instance, drivers could register their options and read them<br>
from there. Drivers constructors would be consistent, no custom args /<br>
kwargs, everything read from the config instance.<br></blockquote><div><br></div><div style>A single conf instance does not solve the problem of connecting to multiple transports that need different configurations. For example, in ceilometer, we listen to notifications on the exchanges for all of the other projects. Right now we create separate connections where only the exchange varies. However, we would prefer for ceilometer not to know that exchanges are a meaningful concept to the driver at all, since they *aren't* for some drivers. In the case of cells, the IP where the exchange is located also changes (assuming each cell has its own rabbit/qpid cluster). That might be the case for ceilometer, as well, if a single ceilometer cluster is being used to collect data about several cells (or even deployments).</div>
<div style><br></div><div style>Eric will need to weigh in, but I think this is especially a problem with 0mq because of the exchange vs. port question.</div><div style><br></div><div style>One thing we explored early on was having separate configuration sections for each connection, and reusing the same option names. The config parser doesn't like that, and I'm not really a fan either. It also doesn't solve the problem for cells, which need to store the connection parameters somewhere other than the config file. A single URL specifying all of the connection settings supports all of the use cases.</div>
<div style> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
More complex drivers will, most likely, have to specify custom options<br>
anyway, I doubt we'll be able to completely get rid of those. My<br>
concern is that those "more complex" drivers will have to create a<br>
custom connection url - comma separate netlocs for qpid's case for<br>
example - which, IMHO, makes the implementation less cleaner and<br>
deployers will have to know how to encode that URL with the accepted<br>
parameters anyway.<br></blockquote><div><br></div><div style>Yes, I agree, that's a problem we need to solve. I haven't done an exhaustive analysis, but it seems like anything set in an individual option now could potentially be made a query parameter. I could see some of the drivers that have required settings using the "path" in the URL for those. For example, an rabbit URL might look like:</div>
<div style><br></div><div style> rabbitmq://user:password@host:port/exchange?param_only_rabbit_uses=value</div><div style><br></div><div style>QPid might do something like:</div><div style><br></div><div style><div> qpid://user:password@primary_host:port/exchange?alternate_host=ip&alternate_host=ip</div>
<div><br></div><div style>or</div><div><br></div><div><div> qpid://user:password@primary_host:port/exchange?alternate_host=ip,ip</div></div><div><br></div><div style>This is very similar to the way we're already specifying the storage settings in ceilometer.<br>
</div></div><div style><br></div><div style>If there are driver-specific parameters that control how the driver works but not where it talks (timeouts, etc.) those could conceivably be kept as separate options. I would prefer, though, that drivers not define options at all because it introduces a dependency between the driver and the config library that isn't really necessary.</div>
<div style><br></div><div style>Doug</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
I see the benefit of having a "common" url but we might be<br>
complicating things instead of simplifying them, configuration wise.</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Thoughts?<br>
<br>
FF<div class=""><div class="h5"><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>
</div></div></blockquote></div><br></div></div>