<div dir="ltr">Thank you, Eric, for your descriptions!<div><br></div><div>I'm very new to rpc and oslo.messaging. So I can be wrong in the idea of how it all designed and I can be wrong in a particular formulations. But I'm highly motivated in improvement of the rpc/oslo.messaging knowledge. I'm going to clarify all your descriptions and come back with updated propositions.</div><div><br></div><div>Thank you, Russell, for your proposition!</div><div><br></div><div>I'll pay attention to AMQP 1.0 as soon as possible. I'm not sure I can take it all to work but for sure I'll have an understanding about AMQP 1.0 in a nearest future.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 17, 2014 at 5:03 PM, Eric Windisch <span dir="ltr"><<a href="mailto:eric@windisch.us" target="_blank">eric@windisch.us</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Mon, Nov 17, 2014 at 5:44 AM, Ilya Pekelny <span dir="ltr"><<a href="mailto:ipekelny@mirantis.com" target="_blank">ipekelny@mirantis.com</a>></span> wrote:<br><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></span><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><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><font color="#000000" face="verdana, arial, helvetica, sans-serif">From the current code docstring:</font></div><div><font color="#000000" face="verdana, arial, helvetica, sans-serif"><div>    ZmqBaseReactor(ConsumerBase):</div><div>        """A consumer class implementing a centralized casting broker (PULL-PUSH).</div><div><br></div><div>This approach is pretty unusual for ZeroMQ. Fortunately we have a bit of raw developments around the problem. These changes can introduce performance improvement. But to proof it we need to implement all new features, at least at WIP status. So, I need to be sure that the community doesn't avoid such of improvements.</div><div></div></font></div></div></blockquote><div><br></div></span><div>Again, the design implemented expects a broker running per machine (the zmq-receiver process). Each machine might have multiple workers all pulling messages from queues. Initially, the driver was designed such that each topic was mapped to its own ip:port, but this was not friendly to having arbitrary consumers of the library and required a port mapping file be distributed with the application. Plus, it's valid to have multiple consumers of a topic on a given host, something that is only possible with a distributed broker.</div><div><br></div><div>As I left the driver, long review queues prevented me from merging a pile of changes to improve performance and increase reliability. I believe the architecture is still sound, even if much of the code itself is bad. What this driver needs is major cleanup, refactoring, and better testing.</div><div><br></div><div>Regards,</div><div>Eric Windisch </div></div><br></div></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>