Open Stack

Hi Paul

On Mon, 2013-06-17 at 15:18 -0600, Paul Mathews wrote:
> Mark,
> 
> As mentioned at the summit, we've been looking into migrating from qpid 
> to zmq. We have gone through the process of migrating nodes from one set 
> of controllers to another, but that brought about it's own set of 
> problems for us. As a result of that, I've written a patch for our use 
> that allows us to have services listen on both zmq and qpid backends.

I think that's something we could consider supporting in the new
oslo.messaging API:

  https://github.com/markmc/oslo.messaging

Basically, you'd have something like this:

  qpid_transport = messaging.get_transport(CONF, 'qpid:///...')
  zmq_transport = messaging.get_transport(CONF, 'qpid:///...')

  server = messaging.get_rpc_server(qpid_transport, target, endpoints)
  server.listen(zmq_transport)
  server.start()

See also:

  http://lists.openstack.org/pipermail/openstack-dev/2013-May/008960.html

The use case we think is most likely is where ceilometer needs to
consume notifications from different brokers.


> We 
> first check and see if the zmq receiver on the intended host is 
> listening. If it is, we deliver normally via zmq; if not, we assume the 
> destination is listening on qpid, and deliver the message to the qpid 
> host. I'm not thrilled with the current implementation in respect to 
> checking if the host is listening for zmq connections first, but due to 
> the asynchronous way in which zmq operates, it's the best solution I've 
> been able to come up with. I can't see multiple rpc backends as 
> something most people would use, and I do think my current 
> implementation of zmq checking could be more elegant. I'm fairly 
> confident it would be easy to modify to encompass rabbitmq as well, but 
> as we don't use it, I haven't looked at any of their code. I'm tempted 
> to just throw our patches up as a blog post or something, but I wonder 
> whether it's something the community might be interested in getting 
> mainlined. Do you feel like this is something I should submit for 
> review, or might there be technical or other reasons to leave it out?

I'm not 100% sure I follow all of the above, so please let me know if I
missed something.

Thanks,
Mark.