<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 2014/11/17 23:03, Eric Windisch
wrote:<br>
</div>
<blockquote
cite="mid:CAAZDpLdZCDpDAwqtJzDBOAg9xEQOG4ssrggUQ=V7mqfhtYVBdw@mail.gmail.com"
type="cite">
<div dir="ltr"><br>
<div class="gmail_extra">On Mon, Nov 17, 2014 at 5:44 AM, Ilya
Pekelny <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:ipekelny@mirantis.com" target="_blank">ipekelny@mirantis.com</a>></span>
wrote:<br>
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div>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:</div>
<div><br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>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?</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div> </div>
</div>
</div>
</div>
</blockquote>
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.<br>
<br>
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?<br>
<br>
cheers,<br>
Li Ma<br>
</body>
</html>