openstack team mailing list archive

[Doug Hellmann <doug.hellmann@xxxxxxxxxxxxx>]

On Thu, May 31, 2012 at 10:48 AM, Mark Washenberger <
mark.washenberger@xxxxxxxxxxxxx> wrote:

>
>
> "Jay Pipes" <jaypipes@xxxxxxxxx> 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.


>
> I'm happy to work on some of these but I probably can't do the whole thing.
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>