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. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev