<div dir="ltr">Renat,<div><br></div><div>Please file a blueprint to discuss the problem and options against oslo-specs repository so we can get a headstart before the Tokyo summit.</div><div><br></div><div>thanks,</div><div>dims</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 24, 2015 at 9:03 AM, Renat Akhmerov <span dir="ltr"><<a href="mailto:rakhmerov@mirantis.com" target="_blank">rakhmerov@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">(Resending the email that I sent last week but it doesn’t seem to have been sent out actually…)<div><br><div><blockquote type="cite">On 19 Aug 2015, at 21:44, Doug Hellmann <<a href="mailto:doug@doughellmann.com" target="_blank">doug@doughellmann.com</a>> wrote:<br><br>Excerpts from Nikolay Makhotkin's message of 2015-08-19 17:16:14 +0300:<br><blockquote type="cite">Hi, Davanum!<br><br>Have you already read the thread [1]? It is about acknowledge feature in<br>oslo.messaging. Particularly, about the absent of this feature in<br>oslo.messaging.<br><br>The guys from messaging said that it is very problematically to add that<br>kind of feature to oslo.messaging because it does not fit to<br>oslo.messaging's approach.<br></blockquote><br>The Oslo libraries are meant to evolve as the needs to the applications<br>evolve. That process works best when it comes about through<br>collaboration between all of us, and the Oslo team has taken on the<br>mission of enabling that collaboration. What I'm hearing in this<br>request is "the library our community has written doesn't do something<br>we want, so rather than work on it with other members of our community<br>we want to adopt a different library that is missing different<br>features" [2].<br></blockquote><br>Doug, yes, I agree. That’s why we decided to start the thread that Nikolay pointed to. To collaborate on that.<br><br>My point is the following: we’re not getting rid of oslo.messaging for several reasons (community standard,<br>its developers have better vision and expertise at messaging etc.). In any case we’ll have oslo.messaging as one of our <br>implementations for rpc layer (by it I mean very Mistral specific interface to distribute tasks over executors and similar).<br>And we’re, of course, ready to further work with you on evolving oslo.messaging in the right direction.<br>At the same time we still have an idea of implementing our RPC alternatively (w/o oslo.messaging) just for<br>purely time reasons, in other words, we want to have that missing feature as soon as possible because our<br>customers are already using Mistral in production and it affects them. But once we got all needed in oslo.messaging<br>we can get rid of our own implementation at all.<br><br><br><blockquote type="cite">As far as I can tell from reading the thread you linked to, you<br>weren't told "no" just that it might be harder than just moving the<br>place we send acknowledgments inside the current driver, and we're<br>likely to need your help with the implementation.  The thread sort<br>of died off, so perhaps that wasn't clear.<br></blockquote><br>We can try to help with this.<br><br><blockquote type="cite">You have what seems to be a new case -- perhaps its an old case<br>that was never being handled properly and everyone actually always<br>wanted this, I don't know. Either way, handling that case will<br>require a change to the semantics of the library, which means we<br>need to be careful about how we do it, but it's not impossible or<br>unwanted.<br></blockquote><br>Changing semantics seemed to be exactly the main challenge we had in mind.<br>It made us think it would hardly be implemented within oslo.messaging any time soon.<br>If you’re saying it’s not impossible then it’s good, we need to discuss how it may be<br>implemented in a backwards compatible manner.<br><br><blockquote type="cite">However we implement it, we need to ensure backwards compatibility<br>for applications relying on the current behavior. For example,<br>perhaps the application would pass a flag to the messaging library<br>to control whether ACKs are sent before or after processing (we<br>don't want that as a configuration option, because it's the application<br>developer who needs to handle any differences in behavior, rather<br>than the deployer). We should start out with the default behavior<br>set to what we have now, and then we can experiment with changing<br>it in each application before changing the default in the library.<br><br>So, if you're interested in working with us on that, let us know.<br></blockquote><br>Yes, we are. What would be the next practical steps that you could suggest?<br><br>Thanks<span class="HOEnZb"><font color="#888888"><br><br>Renat</font></span></div></div></div><br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Davanum Srinivas :: <a href="https://twitter.com/dims" target="_blank">https://twitter.com/dims</a></div>
</div>