On Thu, May 31, 2012 at 11:26 AM, Doug Hellmann <doug.hellm...@dreamhost.com> wrote: > > > On Thu, May 31, 2012 at 10:48 AM, Mark Washenberger > <mark.washenber...@rackspace.com> wrote: >> >> >> >> "Jay Pipes" <jaypi...@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 _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
