Open Stack

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.

>   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"]}