Open Stack

Thank you, Eric, for your descriptions!

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.

Thank you, Russell, for your proposition!

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.

On Mon, Nov 17, 2014 at 5:03 PM, Eric Windisch <eric at windisch.us> wrote:

>
>
> 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
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141118/8ad2d10a/attachment.html>