<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, May 21, 2013 at 3:25 AM, 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">On 20/05/13 17:47 -0400, Doug Hellmann wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Mon, May 20, 2013 at 4:45 PM, Flavio Percoco <[1]<a href="mailto:flavio@redhat.com" target="_blank">flavio@redhat.com</a>><div class="im"><br>
wrote:<br>
<br>
<br>
A single conf instance does not solve the problem of connecting to<br>
multiple transports that need different configurations. For example, in<br>
ceilometer, we listen to notifications on the exchanges for all of the<br>
other projects. Right now we create separate connections where only the<br>
exchange varies. However, we would prefer for ceilometer not to know<br>
that exchanges are a meaningful concept to the driver at all, since<br>
they *aren't* for some drivers. In the case of cells, the IP where the<br>
exchange is located also changes (assuming each cell has its own<br>
rabbit/qpid cluster). That might be the case for ceilometer, as well,<br>
if a single ceilometer cluster is being used to collect data about<br>
several cells (or even deployments).<br>
</div></blockquote>
<br>
Oh, this changes my perspective. The transport_url is indeed useful<br>
for having multiple transports connected to different backends. I<br>
wasn't thinking about that use case, thanks for pointing it out.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
More complex drivers will, most likely, have to specify custom<br>
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>
<br>
Yes, I agree, that's a problem we need to solve. I haven't done an<br>
exhaustive analysis, but it seems like anything set in an individual<br>
option now could potentially be made a query parameter. I could see<br>
some of the drivers that have required settings using the "path" in the<br>
URL for those. For example, an rabbit URL might look like:<br>
<br>
rabbitmq://user:password@host:<u></u>port/exchange?param_only_<u></u>rabbit_uses=valu<br>
e<br>
QPid might do something like:<br>
<br>
qpid://user:password@primary_<u></u>host:port/exchange?alternate_<u></u>host=ip&alter<br>
nate_host=ip<br>
or<br>
qpid://user:password@primary_<u></u>host:port/exchange?alternate_<u></u>host=ip,ip<br>
</blockquote>
<br></div>
Makes sense, I was also thinking about:<br>
<br>
qpid://user:passwd@host1:<u></u>port1,host2:port2,host3:port3/<u></u>exchange?option=val<br>
<br>
The above is basically how mongodb uris work. I like the fact that the<br>
whole comma-separate list of hosts is part of the netloc so that real<br>
options can be part of the query params. I guess this could be<br>
discussed in a separate thread, we might find a common format that<br>
covers most drivers.</blockquote><div><br></div><div style>I was just making up those examples, so if there is prior art we should definitely take our lead from that.</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"><div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
This is very similar to the way we're already specifying the storage<br>
settings in ceilometer.<br>
If there are driver-specific parameters that control how the driver<br>
works but not where it talks (timeouts, etc.) those could conceivably<br>
be kept as separate options. I would prefer, though, that drivers not<br>
define options at all because it introduces a dependency between the<br>
driver and the config library that isn't really necessary.<br>
</blockquote>
<br></div>
Agreed.<br>
<br>
Thanks for clarifying the need of the transport_url.<br>
<br>
Cheers,<div class="HOEnZb"><div class="h5"><br>
FF<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>