<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 31 August 2016 at 10:12, Clint Byrum <span dir="ltr"><<a href="mailto:clint@fewbar.com" target="_blank">clint@fewbar.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Excerpts from Duncan Thomas's message of 2016-08-31 12:42:23 +0300:<br>
<div><div class="h5">> On 31 August 2016 at 11:57, Bogdan Dobrelya <<a href="mailto:bdobrelia@mirantis.com">bdobrelia@mirantis.com</a>> wrote:<br>
><br>
> > I agree that RPC design pattern, as it is implemented now, is a major<br>
> > blocker for OpenStack in general. It requires a major redesign,<br>
> > including handling of corner cases, on both sides, *especially* RPC call<br>
> > clients. Or may be it just have to be abandoned to be replaced by a more<br>
> > cloud friendly pattern.<br>><br>
><br>
> Is there a writeup anywhere on what these issues are? I've heard this<br>
> sentiment expressed multiple times now, but without a writeup of the issues<br>
> and the design goals of the replacement, we're unlikely to make progress on<br>
> a replacement - even if somebody takes the heroic approach and writes a<br>
> full replacement themselves, the odds of getting community by-in are very<br>
> low.<br>
<br>
</div></div>Right, this is exactly the sort of thing I'd like to gather a group of<br>
design-minded folks around in an Architecture WG. Oslo is busy with the<br>
implementations we have now, but I'm sure many oslo contributors would<br>
like to come up for air and talk about the design issues, and come up<br>
with a current design, and some revisions to it, or a whole new one,<br>
that can be used to put these summit hallway rumors to rest.<br></blockquote><div><br></div><div>I'd say the issue is comparatively easy to describe.  In a call sequence:<br><br></div><div>1. A sends a message to B<br></div><div>2. B receives messages<br></div><div>3. B acts upon message<br></div><div>4. B responds to message<br></div><div>5. A receives response<br></div><div>6. A acts upon response<br><br></div><div>... you can have a fault at any point in that message flow (consider crashes or program restarts).  If you ask for something to happen, you wait for a reply, and you don't get one, what does it mean?  The operation may have happened, with or without success, or it may not have gotten to the far end.  If you send the message, does that mean you'd like it to cause an action tomorrow?  A year from now?  Or perhaps you'd like it to just not happen?  Do you understand what Oslo promises you here, and do you think every person who ever wrote an RPC call in the whole OpenStack solution also understood it?<br><br></div><div>I have opinions about other patterns we could use, but I don't want to push my solutions here, I want to see if this is really as much of a problem as it looks and if people concur with my summary above.  However, the right approach is most definitely to create a new and more fitting set of oslo interfaces for communication patterns, and then to encourage people to move to the new ones from the old.  (Whether RabbitMQ is involved is neither here nor there, as this is really a question of Oslo APIs, not their implementation.)<br></div></div></div></div>