Open Stack

> On 04 May 2016, at 13:21, Mehdi Abaakouk <sileht at sileht.net> wrote:
> 
> 
>> That said, I agree with Mehdi that *most* RPC calls throughout OpenStack,
>> not being idempotent, should not use process-then-ack.
> 
> That why I think we must not call this RPC. And the new API should be clear the expected idempotent of the application callbacks.

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?

>>> Thoughts from folks (mistral and oslo)?
> 
> 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 ?


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.).

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.

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.


Renat Akhmerov
@Nokia

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160504/03c43873/attachment.html>