Open Stack

On 20/05/13 16:11 -0400, Doug Hellmann wrote:
>   On Mon, May 20, 2013 at 12:48 PM, Flavio Percoco <[1]flavio at redhat.com>
>   wrote:
>
>   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.

But all drivers have a conf instance, right? I was thinking that using
that conf instance, drivers could register their options and read them
from there. Drivers constructors would be consistent, no custom args /
kwargs, everything read from the config instance.

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.

I see the benefit of having a "common" url but we might be
complicating things instead of simplifying them, configuration wise.

Thoughts?

FF

-- 
{ name: "Flavio Percoco",
   gpg: "87112EC1", 
   internal: "8261386",
   phone: "+390687502386",
   irc: ["fpercoco", "flaper87"]}