So then let's all get onboard https://review.openstack.org/#/c/260246/?

I've yet to see what all these things called 'process-than-ack' not seemingly fit into that API in that review. IMHO most of what people are trying to fit into oslo.messaging here isn't really messages but are jobs to be completed that should *only* be acked when they are actually complete.

Which is in part what that review adds/does (extracts the job[1] part from taskflow so others can use it, without say taking in the rest of taskflow).

[1] http://docs.openstack.org/developer/taskflow/jobs.html

Dmitry Tantsur wrote:
On 05/04/2016 08:21 AM, Mehdi Abaakouk wrote:

Hi,

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.

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 ?


Taskflow is pretty opinionated about the whole application design. We
can't use it in ironic-inspector, but we also need process-then-ack
semantics for our HA work.

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to