<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div></div></div><div><blockquote type="cite" class=""><div class="">On 04 May 2016, at 13:21, Mehdi Abaakouk <<a href="mailto:sileht@sileht.net" class="">sileht@sileht.net</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><br class=""><blockquote type="cite" class="">That said, I agree with Mehdi that *most* RPC calls throughout OpenStack,<br class="">not being idempotent, should not use process-then-ack.<br class=""></blockquote><br class="">That why I think we must not call this RPC. And the new API should be clear the expected idempotent of the application callbacks.<br class=""></div></div></blockquote><div><br class=""></div><div>No problem. Let’s not call it RPC (btw, I completely agree with that). But it’s one of the messaging patterns and hence should be under oslo.messaging I guess, no?</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><blockquote type="cite" class=""><blockquote type="cite" class="">Thoughts from folks (mistral and oslo)?<br class=""></blockquote></blockquote><br class="">Also, I was not at the Summit, should I conclude the Tooz+taskflow approach (that ensure the idempotent of the application within the library API) have not been accepted by mistral folks ?<br class=""></div></div></blockquote></div><div class=""><br class=""></div><div class="">Speaking about idempotency, IMO it’s not a central question that we should be discussing here. Mistral users should have a choice: if they manage to make their actions idempotent it’s excellent, in many cases idempotency is certainly possible, btw. If no, then they know about potential consequences. And even in this case there’s usually a number of measures that can be taken to mitigate those consequences (reruning workflows from certain points after manually fixing problems, rollback scenarios etc.).</div><div class=""><br class=""></div><div class="">What I’m saying is: let’s not make that crucial decision now about what a messaging framework should support or not, let’s make it more flexible to account for variety of different usage scenarios. It’s normal for frameworks to give more rather than less.</div><div class=""><br class=""></div><div class="">One more thing, at the summit we were discussing the possibility to define at-most-once/at-least-once individually for Mistral tasks. This is demanded because there cases where we need to do it, advanced users may choose one or another depending on a task/action semantics. However, it won’t be possible to implement w/o changes in the underlying messaging framework.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Renat Akhmerov</div><div class="">@Nokia</div><div class=""><br class=""></div></div></div></div></body></html>