Open Stack

Hi Doug,

It is sad that it may be abandoned in future OpenStack release. ZeroMQ is fantastic messaging library because it is broker-less and can be fully distributed. It is really useful in large-scale deployment scenario.

Currently we are using ZeroMQ as the message queue implementation in our production systems from Havana. We've deployed this method in multiple DCs. Abandon ZeroMQ is a great loss. AFAIK, the following can be done to make it active in OpenStack ecosystem.

(1) Provide tuning parameters for ZeroMQ context and sockets in order to fine-tune ZeroMQ for different deployment scenario.

(2) Provide comprehensive test cases for ZeroMQ.

(3) Support Devstack.

(4) Provide installation tutorial in OpenStack docs.

(5) Provide suggestions on real deployment architecture in OpenStack docs.

I would love to try to get them done step by step.

By the way, I just noticed that kombu supports ZeroMQ. I wonder how it support direct/topic/fanout. Maybe we can try the kombu way to simplify the current impl_zmq implementation. But it needs further investigation.

cheers,
Li Ma



----- Original Message -----
From: "Doug Hellmann" <doug at doughellmann.com>
To: "Sandy Walsh" <sandy.walsh at RACKSPACE.COM>
Cc: openstack at lists.openstack.org
Sent: 星期日, 2014年 9 月 07日 上午 1:01:38
Subject: Re: [Openstack] is anyone using zeromq for RPC?



On Sep 6, 2014, at 11:00 AM, Sandy Walsh <sandy.walsh at RACKSPACE.COM> wrote:

>> From: Doug Hellmann [doug at doughellmann.com]
>> On Sep 5, 2014, at 11:13 PM, Sandy Walsh <sandy.walsh at RACKSPACE.COM> wrote:
> 
>>>> From: Doug Hellmann [doug at doughellmann.com]
>>>> The zmq driver in oslo.messaging, used for internal communication
>>>> between OpenStack services, has been without a maintainer for a
>>>> significant period of time. It isn’t actively tested, and it isn’t
>>>> clear whether or not it works. The Oslo team would like to drop
>>>> support for it in Kilo, but before we do that we would like to find
>>>> out if (a) anyone uses it and (b) if any of those people would like to
>>>> contribute to maintaining it.
>>> 
>>> Why not just break it out into a separate repo? It would still be
>>> loadable via stevedore. This would let people keep using it if they
>>> desire (and, more importantly, maintain it externally) vs. the all-or-
>>> nothing inclusion/exclusion decision.
> 
>> If a maintainer is found, we can extract the files or resurrect them
>> in place at any point in the future.
> 
> Well, yeah, but that doesn't help the operators that have it deployed
> already and didn't see this thread.
> 
> Their update process will be: 1. install 2. wtf?! 3. scramble. 

I expect to make a lot of noise about it between now and the middle/end of kilo when we actually remove the driver. As I said it's not at all clear the driver even works in its current state, so I don't know if anyone could be using it as it is.

Doug

> 
>> Doug

_______________________________________________
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to     : openstack at lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack