Open Stack

"Jay Pipes" <jaypipes at gmail.com> said:
> On 05/29/2012 04:04 AM, Mark McLoughlin wrote:
>> Adopting this pattern across all projects will actually help
>> openstack-common more generally. For example, Russell is moving the RPC
>> code into openstack-common and it has a bunch of configuration options.
>> If it can assume a global configuration object, things become much
>> easier.
> 
> Unfortunately, what this leads to is interdependencies between the
> openstack-common-rpc code and the openstack-common-cfg code. :( Now, if
> someone wants to use the openstack RPC code in their own project, they
> have to switch their way of configuring stuff to use global config
> objects. Tight coupling means less adherence to the "do one thing and do
> it well" mantra of *nix utilities and libraries and in general isn't
> good software design.


I personally would consider a rigid connection between the rpc library and
the configuration to be inappropriate in the context of openstack common.
I'm also very happy to contribute modifications that would eliminate that
connection.

There are a few other reasons I'm concerned about nova's rpc implementation
becoming the de facto standard. It has grown up organically and as such has
some significant issues we should probably address before we create a
precedent that other projects must adopt it to be good community members.

From a brief scan, it seems to me that a restructured implementation of rpc
that lands in common should

 * not be tied up with eventlet on the consumer side
 * let the consumer code decide when to ack a message
   (although maybe the concept of acking doesn't exist for all implementations?)
 * not depend on a global singleton _RPC_IMPL
 * leave out/refactor some unused or non-general aspects, such as multicall,
   fanout_cast_to_server, notify, and fanout_cast (not so sure about that last one)

I'm happy to work on some of these but I probably can't do the whole thing.