[openstack-dev] [Quantum][Common] Private rpc methods / declare_topic_consumer

Doug Hellmann doug.hellmann at dreamhost.com
Wed Sep 5 21:23:42 UTC 2012

On Wed, Sep 5, 2012 at 2:42 PM, Eric Windisch <eric at cloudscaling.com> wrote:

> After a bit of a distraction, I've returned to working on some Quantum
> compatibility testing, analysis, etc. in regard to ZeroMQ.
> Currently, Quantum's NotificationDispatcher class uses
> connection.declare_topic_consumer which is not part of the standardized RPC
> abstraction. As such, it has not been implemented in the ZeroMQ driver.
> The obvious choices are to make this a required part of the abstraction,
> implementing it in impl_fake and impl_zmq, or changing the behavior of
> Quantum.  Also, relatedly, this isn't the first time this has happened in a
> project, we should really look at prefixing these private functions with _.
> I think if we had a method /like/ declare_topic_consumer available, we
> could see more asynchronous-style development in OpenStack. That could be a
> good thing. However, we might need further discussion and consensus on the
> queue_name argument, potentially removing it from the standardized form.

We needed something like declare_topic_consumer() in ceilometer and I
couldn't find another way to listen to notifications without using the AMQP
libraries directly. It's on my list of things to add to the RPC library,
but I'm still working on getting ceilometer working end-to-end, so I
haven't started circling back and "fixing" stuff like this, yet. I hope to
have more of that done in grizzly.

What I actually want is something like create_worker(), but not tied to the
RPC message envelope format because notifications aren't RPC messages. For
now we have implemented ceilometer's metering messages with RPC cast()
calls, but that was also a stop-gap so we could move forward with the rest
of the work.

I'm not sure what you mean about removing the queue name argument. That's
there so the client can indicate which messages it wants. Do you have in
mind another way to do that?


> Thoughts?
> Regards,
> Eric Windisch
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20120905/7c34a05f/attachment.html>

More information about the OpenStack-dev mailing list