Open Stack

On Fri, 2012-06-01 at 10:37 -0400, Mark Washenberger wrote:
> Hi Mark,
> 
> Please forgive the top-posting! I always get way too wordy with
> inline replies.
> 
> Regarding configuration, I think there is another option I'd like us
> to adopt. We should implement the code as in your option #1, but then
> implement convenience factories that give the appearance of option #3
> or #2, or both, you pick. From your examples it might look something
> like this:
> 
>     class Connection(object):
>  
>         def __init__(self, broker_hostname, broker_port):
>             self.cnx = self.connect(broker_hostname, broker_port)
>  
>         def cast(self, topic, msg):
>             self.cnx.cast(topic, msg)
> 
>     def connection_from_global_conf():
>         return Connection(CONF.broker_hostname, CONF.broker_port)
> 
> I think its pretty necessary that we don't do option #3 directly.
> There are some important use cases to consider, like migrating from
> one rpc implementation to another where you might want an adapter
> that can relay messages from one to the other. Also, cells with
> kombu at least requires that one process be able to talk to multiple
> brokers.

Yeah, I think that all makes sense.

Depending on the context, we might want to require only one of #1, #2 or
#3 to be supported in order for the API to be added to openstack-common
initially. I think there'll be good reasons in different cases why only
one of the options is required by initial users of the API.

> Regarding incubation, I suppose I am confused. At what point during
> incubation do other projects start to use the shared library? I would
> imagine the answer to be "after incubation" but it sounds like there
> are several projects very eager to adopt rpc as soon as it lands in
> openstack common, even before incubation is complete.
> 
> If incubation happens before the calcifying effects of shared use
> set in, then it sounds like a great place to address the other
> rpc-specific concerns we've talked about. Otherwise I guess we're
> stuck where I thought we were, where the bar needs to be set pretty
> high to initially land in os-common.

http://wiki.openstack.org/CommonLibrary#Incubation

In openstack-common, Incubation -> Core is "we're ready to commit to
backward compatibility". None of the APIs have reached that point yet.

While an API is incubating, other projects can still use it and the API
can make backwards incompatible changes. For example, I made a backwards
incompatible change to the cfg.ConfigOpts() constructor recently and
updated all projects to use the new API.

That's exactly the case here - we want openstack.common.rpc to initially
be a reasonable API that can be used by multiple OpenStack projects (say
nova, glance and quantum) but that doesn't mean we need to commit to
maintaining backwards compatibility for the API we initially add.

Cheers,
Mark.