<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi, Eric<br>
<br>
Thanks a lot for your comments.<br>
<br>
<div class="moz-cite-prefix">On 06.03.15 06:21, Eric Windisch wrote:<br>
</div>
<blockquote
cite="mid:CAAZDpLcpUyffef+aUXqcv=jPdUxK3g-OrruG43S4-O_y+ph8UQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_quote" style="font-size:12.8000001907349px">On
Wed, Mar 4, 2015 at 12:10 PM, ozamiatin <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:ozamiatin@mirantis.com" target="_blank">ozamiatin@mirantis.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi,<br>
<br>
By this e-mail I'd like to start a discussion about current
zmq driver internal design problems I've found out.<br>
I wish to collect here all proposals and known issues. I
hope this discussion will be continued on Liberty design
summit.<br>
And hope it will drive our further zmq driver development
efforts.<br>
<br>
ZMQ Driver issues list (I address all issues with # and
references are in []):<br>
<br>
1. ZMQContext per socket (blocker is neutron improper usage
of messaging via fork) [3]<br>
2. Too many different contexts.<br>
We have InternalContext used for ZmqProxy, RPCContext
used in ZmqReactor, and ZmqListener.<br>
There is also zmq.Context which is zmq API entity. We
need to consider a possibility to unify their usage over
inheritance (maybe stick to RPCContext)<br>
or to hide them as internal entities in their modules
(see refactoring #6)<br>
</blockquote>
<div><br>
</div>
<div>The code, when I abandoned it, was moving toward fixing
these issues, but for backwards compatibility was doing so
in a staged fashion across the stable releases.</div>
<div><br>
</div>
<div>I agree it's pretty bad. Fixing this now, with the driver
in a less stable state should be easier, as maintaining
compatibility is of less importance.</div>
<div><br>
</div>
</div>
</div>
</blockquote>
<blockquote
cite="mid:CAAZDpLcpUyffef+aUXqcv=jPdUxK3g-OrruG43S4-O_y+ph8UQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_quote" style="font-size:12.8000001907349px">
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">3.
Topic related code everywhere. We have no topic entity. It
is all string operations.<br>
We need some topics management entity and topic itself
as an entity (not a string).<br>
It causes issues like [4], [5]. (I'm already working on
it).<br>
There was a spec related [7].<br>
</blockquote>
<div><br>
</div>
<div>Good! It's ugly. I had proposed a patch at one point, but
I believe the decision was that it was better and cleaner to
move toward the oslo.messaging abstraction as we solve the
topic issue. Now that oslo.messaging exists, I agree it's
well past time to fix this particular ugliness.</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">4.
Manual implementation of messaging patterns.<br>
Now we can observe poor usage of zmq features in zmq
driver. Almost everything is implemented over PUSH/PULL.<br>
<br>
4.1 Manual polling - use zmq.Poller (listening and
replying for multiple sockets)<br>
4.2 Manual request/reply implementation for call [1].<br>
Using of REQ/REP (ROUTER/DEALER) socket solves many
issues. A lot of code may be reduced.<br>
4.3 Timeouts waiting<br>
</blockquote>
<div><br>
</div>
<div>There are very specific reasons for the use of PUSH/PULL.
I'm firmly of the belief that it's the only viable solution
for an OpenStack RPC driver. This has to do with how
asynchronous programming in Python is performed, with how
edge-triggered versus level-triggered events are processed,
and general state management for REQ/REP sockets.</div>
<div><br>
</div>
<div>I could be proven wrong, but I burned quite a bit of time
in the beginning of the ZMQ effort looking at REQ/REP before
realizing that PUSH/PULL was the only reasonable solution.
Granted, this was over 3 years ago, so I would not be too
surprised if my assumptions are no longer valid.</div>
<div><br>
</div>
</div>
</div>
</blockquote>
I agree that REQ/REP is very limited because of their synchronous
nature and 1-to-1 connection possibility.<br>
But there are ROUTER/DEALER proxy sockets recommended to use with
REQ/REP to compose 1-to-N and N-to-N asynchronous patterns.<br>
I'm in research of that now and I didn't finally decide yet. When
everything will be clear for me I'll come with a spec on that.<br>
<blockquote
cite="mid:CAAZDpLcpUyffef+aUXqcv=jPdUxK3g-OrruG43S4-O_y+ph8UQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_quote" style="font-size:12.8000001907349px">
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">5.
Add possibility to work without eventlet [2]. #4.1 is also
related here, we can reuse many of the implemented solutions<br>
like zmq.Poller over asynchronous sockets in one separate
thread (instead of spawning on each new socket).<br>
I will update the spec [2] on that.<br>
</blockquote>
<div><br>
</div>
<div>Great. This was one of the motivations behind
oslo.messaging and it would be great to see this come to
fruition.</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">6.
Put all zmq driver related stuff (matchmakers, most classes
from zmq_impl) into a separate package.<br>
Don't keep all classes (ZmqClient, ZmqProxy, Topics
management, ZmqListener, ZmqSocket, ZmqReactor)<br>
in one impl_zmq.py module.<br>
</blockquote>
<div><br>
</div>
<div>Seems fine. In fact, I think a lot of code could be
shared with an AMQP v1 driver...</div>
</div>
</div>
</blockquote>
<br>
I'll check what can be shared. Actually I didn't yet dig into AMQP
v1 driver enough.<br>
<blockquote
cite="mid:CAAZDpLcpUyffef+aUXqcv=jPdUxK3g-OrruG43S4-O_y+ph8UQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_quote" style="font-size:12.8000001907349px">
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">7.
Need more technical documentation on the driver like [6].<br>
I'm willing to prepare a current driver architecture
overview with some graphics UML charts, and to continue
discuss the driver architecture.<br>
</blockquote>
<div><br>
</div>
<div>Documentation has always been a sore point. +2</div>
<div> </div>
</div>
<span style="font-size:12.8000001907349px">-- </span><br
style="font-size:12.8000001907349px">
<div style="font-size:12.8000001907349px">
<div dir="ltr">Regards,
<div>Eric Windisch</div>
</div>
</div>
<div hspace="streak-pt-mark" style="max-height:1px"><img
moz-do-not-send="true" style="width:0px; max-height:0px;"
src="imap://ozamiatin%40mirantis%2Ecom@imap.googlemail.com:993/fetch%3EUID%3E/%5BGmail%5D/Drafts%3E93?sender=aZXJpY0B3aW5kaXNjaC51cw%3D%3D&type=zerocontent&guid=43ae07da-6f13-40a4-88ac-ce46166d8575"><font
size="1" color="#ffffff">ᐧ</font></div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
Regards,<br>
Oleksii Zamiatin<br>
</body>
</html>