Open Stack

On Mon, 2013-05-20 at 18:48 +0200, Flavio Percoco wrote:
> Hi,
> 
> The new API has an optional parameter called transport_url[0], which is
> used to specify the connection parameters for the chosen transport.
> This url is being passed to the driver instance, which has to parse
> it and, eventually, merge it with its own connection parameters -
> depending on the implementation. [1]
> 
> My question is: Do we really need it?

Yes, for ceilometer and cells

For cells, we need to to create a transport which connects us to the
parent cell.

For ceilometer, we need to create transports which allows us to listen
to the notifications from the various projects.

> I agree it is useful for some implementations but, it can also make it
> a bit more difficult for other implementations. For example, in qpid's
> case, it could either use a single host or have a list of hosts for
> HA. If transport_url is specified it will be necessary to either give
> priority to it or append its netloc to the qpid_hosts list. However,
> this behavior, most likely won't be the same for other
> implementations.

See

  https://wiki.openstack.org/wiki/Oslo/Messaging#Transport_URLs

  "Since some transports will support a clustered scenario where the
   transport must be confgured with multiple distinct (but equivalent)
   configurations, so we will support configuring a transport with a 
   set of URLs."

and

  http://lists.openstack.org/pipermail/openstack-dev/2013-April/008200.html

  Where this gets tricky is the clustered broker setup - right now, you
  just need to set qpid_hosts to a list of hostnames. To make it work with
  this setup, we'd need cfg to have a crazy interpolation scheme where
  e.g.

    foo=foo:$bar
    bar=blaa,foobar

  then referencing foo returns [foo:blaa, foo:foobar]

> I'm proposing to use rpc_backend and leave the connection parameters
> definition to the implementation.

Doesn't work for cells and ceilometer - the requirement is pretty basic,
I think. A process needs to be able to connect to arbitrary transports,
not just e.g. multiple exchanges on the same broker.

> Also, from my experience with kombu managing connection URLs at a
> higher level can be painful for both the lib and backends
> implementation.

More details?

Cheers,
Mark.