[openstack-dev] Zero MQ remove central broker. Architecture change.

Li Ma skywalker.nick at gmail.com
Tue Nov 18 08:27:58 UTC 2014


On 2014/11/17 23:03, Eric Windisch wrote:
>
> On Mon, Nov 17, 2014 at 5:44 AM, Ilya Pekelny <ipekelny at mirantis.com 
> <mailto:ipekelny at mirantis.com>> wrote:
>
>     We want to discuss opportunity of implementation of the p-2-p
>     messaging model in oslo.messaging for ZeroMQ driver. Actual
>     architecture uses uncharacteristic single broker architecture
>     model. In this way we are ignoring the key 0MQ ideas. Lets
>     describe our message in quotes from ZeroMQ documentation:
>
>
> The oslo.messaging driver is not using a single broker. It is designed 
> for a distributed broker model where each host runs a broker. I'm not 
> sure where the confusion comes from that implies this is a 
> single-broker model?
>
> All of the points you make around negotiation and security are new 
> concepts introduced after the initial design and implementation of the 
> ZeroMQ driver. It certainly makes sense to investigate what new 
> features are available in ZeroMQ (such as CurveCP) and to see how they 
> might be leveraged.
>
> That said, quite a bit of trial-and-error and research went into 
> deciding to use an opposing PUSH-PULL mechanism instead of REQ/REP. 
> Most notably, it's much easier to make PUSH/PULL reliable than REQ/REP.
Hi Eric. In our production deployment, We rely on ZeroMQ driver much 
because we have more than one thousand physical machines to run 
OpenStack. The distributed nature of ZeroMQ provide more scalable 
messaging plane than RabbitMQ.

However, as you know, the driver codebase is not that mature and stable. 
The first problem we faced is that we cannot guarantee the status when 
delivering messages via PULL/PUSH. Because there's no ACK for this 
model. We are discussing the possibility to change from PULL/PUSH to 
REQ/REP. But here you said that it is much easier to make PUSH/PULL 
reliable than REQ/REP. Do you have some idea or concern to improve the 
reliability of the current model?

cheers,
Li Ma
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141118/7d650cba/attachment.html>


More information about the OpenStack-dev mailing list