Sure, but then the contract becomes between the notifier and the client, presumably? I'm not as familiar with the notification system as I should be.
I haven't written a ZeroMQ notifier yet, figuring that task would be better delayed until the move to openstack-common. -- Eric Windisch On Wednesday, April 25, 2012 at 3:29 PM, Russell Bryant wrote: > On 04/25/2012 03:22 PM, Eric Windisch wrote: > > I've heard a few people mention pulling messages off the queue, or > > communicating via RPC outside of the project, or outside of Python. In > > theory, this sounds nice, but the RPC implementations are strictly > > making sure that A can execute calls on target B and that responses get > > back to A. > > > > This has little to do with message queues, other than that message > > queues are optionally supported. You shouldn't be peeking behind that > > curtain. This is specific to each RPC mechanism and enforcing something > > this early might be more problematic than you expect. > > > > > I agree with you that any discussion of other things poking at the rpc > communications is broken and wrong. > > The only case where it does make sense is notifications. In that case, > the fact that it's using rpc is just an implementation detail. If you > enable the rabbit notifier (should probably be renamed at some point), > there is a specific AMQP message exchange where external applications > are to receive notifications from nova. > > This implementation detail means that this can also be used with zeromq > ... though I'm not sure that makes sense. There would probably be a > notifier implementation specific to zeromq that could make better use of > that messaging model. > > -- > Russell Bryant > >
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
