Open Stack

On Tue, May 21, 2013 at 3:25 AM, Flavio Percoco <flavio at redhat.com> wrote:

> On 20/05/13 17:47 -0400, Doug Hellmann wrote:
>
>>   On Mon, May 20, 2013 at 4:45 PM, Flavio Percoco <[1]flavio at redhat.com>
>>
>>   wrote:
>>
>>
>>   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).
>>
>
> Oh, this changes my perspective. The transport_url is indeed useful
> for having multiple transports connected to different backends. I
> wasn't thinking about that use case, thanks for pointing it out.
>
>
>      More complex drivers will, most likely, have to specify custom
>>     options
>>     anyway, I doubt we'll be able to completely get rid of those. My
>>     concern is that those "more complex" drivers will have to create a
>>     custom connection url - comma separate netlocs for qpid's case for
>>     example - which, IMHO, makes the implementation less cleaner and
>>     deployers will have to know how to encode that URL with the accepted
>>     parameters anyway.
>>
>>   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:
>>
>>   rabbitmq://user:password@host:**port/exchange?param_only_**
>> rabbit_uses=valu
>>   e
>>   QPid might do something like:
>>
>>   qpid://user:password@primary_**host:port/exchange?alternate_**
>> host=ip&alter
>>   nate_host=ip
>>   or
>>     qpid://user:password@primary_**host:port/exchange?alternate_**
>> host=ip,ip
>>
>
> Makes sense, I was also thinking about:
>
>     qpid://user:passwd@host1:**port1,host2:port2,host3:port3/**
> exchange?option=val
>
> The above is basically how mongodb uris work. I like the fact that the
> whole comma-separate list of hosts is part of the netloc so that real
> options can be part of the query params. I guess this could be
> discussed in a separate thread, we might find a common format that
> covers most drivers.


I was just making up those examples, so if there is prior art we should
definitely take our lead from that.

Doug


>
>
>    This is very similar to the way we're already specifying the storage
>>   settings in ceilometer.
>>   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.
>>
>
> Agreed.
>
> Thanks for clarifying the need of the transport_url.
>
> Cheers,
>
> FF
>
> --
> { name: "Flavio Percoco",
>   gpg: "87112EC1",   internal: "8261386",
>   phone: "+390687502386",
>   irc: ["fpercoco", "flaper87"]}
>
> ______________________________**_________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.**org <OpenStack-dev at lists.openstack.org>
> http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130521/ea3d5743/attachment.html>