Open Stack

On Thu, May 31, 2012 at 11:26 AM, Doug Hellmann
<doug.hellmann at dreamhost.com> wrote:
>
>
> On Thu, May 31, 2012 at 10:48 AM, Mark Washenberger
> <mark.washenberger at rackspace.com> wrote:
>>
>>
>>
>> "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)
>
>
> It would also be useful if it had a way to subscribe to notification
> messages. From what I can tell, notifications don't work with any of the
> consumers in the existing drivers because those consumers all want to
> dispatch to a method invocation, but notifications aren't structured
> appropriately for that.
>
> I would like to abstract the "messaging" layer out of the existing nova RPC
> library and then build a compatible RPC layer on top of it. Notifications
> and other simple messages (such as meter data for ceilometer) would use the
> lower layer, and communication that truly works like RPC could use the
> higher level API. We should be able to build an agnostic RPC layer that uses
> the messaging driver, instead of having the two concepts bound up together.

A very hearty +1.

d