Open Stack

On Mon, Nov 17, 2014 at 5:44 AM, Ilya Pekelny <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.


> From the current code docstring:
>     ZmqBaseReactor(ConsumerBase):
>         """A consumer class implementing a centralized casting broker
> (PULL-PUSH).
>
> 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.
>

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.

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.

Regards,
Eric Windisch
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141117/e9f14e0a/attachment.html>