Open Stack

On Mon, May 20, 2013 at 12:48 PM, Flavio Percoco <flavio at redhat.com> 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?
>
> 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.
>
> I'm proposing to use rpc_backend and leave the connection parameters
> definition to the implementation.
>

The problem with that drivers specify all sorts of different options, so we
can't have any sort of consistent API for creating a Transport. We need the
constructors for driver classes to all take the same parameters, and for
those parameters to encode everything about the transport -- no peeking at
the config from within the driver -- so that applications that need to
connect to multiple transports and targets (ceilometer, cells, etc.) can
pass the required parameter(s) to create a new connection no matter which
driver is being used.

IOW, instead of eliminating the URL option, the goal is to eliminate *all
of the other* driver-specific options, and encode their values in the URLs.
That leaves deployers able to configure everything that they can today,
while Oslo only has to know about the "scheme" portion of the URL to figure
out which driver to load. The drivers are also then free to interpret the
other fields of the URL in whatever way makes the most sense for the driver.

For backwards compatibility, we would obviously need to have a way to read
the existing configuration format and create the URLs to pass to the
drivers, but that's not difficult.

Doug


>
> Also, from my experience with kombu managing connection URLs at a
> higher level can be painful for both the lib and backends
> implementation.
>
> Thoughts?
>
> Cheers,
> FF
>
> [0]
> https://github.com/markmc/**oslo-incubator/blob/messaging/**
> openstack/common/messaging/**transport.py#L25<https://github.com/markmc/oslo-incubator/blob/messaging/openstack/common/messaging/transport.py#L25>
>
> [1]
> https://github.com/FlaPer87/**oslo-incubator/blob/messaging-**
> qpid/openstack/common/**messaging/_drivers/impl_qpid.**py#L45<https://github.com/FlaPer87/oslo-incubator/blob/messaging-qpid/openstack/common/messaging/_drivers/impl_qpid.py#L45>
>
> --
> { 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/20130520/f826ea3e/attachment.html>