<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 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 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 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 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 style="width:0px; max-height:0px;" src="https://mailfoogae.appspot.com/t?sender=aZXJpY0B3aW5kaXNjaC51cw%3D%3D&type=zerocontent&guid=43ae07da-6f13-40a4-88ac-ce46166d8575"><font color="#ffffff" size="1">ᐧ</font></div></div>