Another data point: at this summit session we discussed delivering to
users notifications about events in the cloud:
https://etherpad.openstack.org/p/newton-alternatives-to-polling
It's pretty critical that this have at-least-once delivery semantics,
because in future people will be using this to do things like triggering
automated recovery when e.g. an instance dies.
The sane way to accomplish this would be to have all services accept a
list of Zaqar queues in which to dump notifications (Zaqar already has
at-least-once delivery semantics). Unfortunately this means changing a
lot of APIs, and this was pre-empted at the session by Nova cores
indicating that they would never ever accept such a change.
The alternative proposed was to create some sort of proxy that listens
for notifications, sanitises them and drops them into the appropriate
Zaqar queues. So this would be an example that:
* Requires at-least-once delivery semantics
* Is fundamentally a message queue (not a job queue, and not RPC)
* Receives notifications sent from oslo.messaging
For those reasons I think it makes sense to have some sort of
abstraction in oslo.messaging to permit this.
I am sympathetic to the idea that we should try to make clear that this
is for occasions when you are absolutely sure that these are the
semantics you want, as in the case of Mistral. Everyone just turning
this option on because it sounds safer would be bad. And the risk is
high, because the default "at-most-once delivery with no recovery from
lost messages" sounds mad when you first hear it. Actually it _is_ mad.
But "at-least-once delivery with no handling for duplicate messages" is
worse. So +1 for a separate messaging type in addition to call and cast
if that will help make clear who this is and is not for.
cheers,
Zane.
On 06/05/16 18:56, Joshua Harlow wrote:
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
__________________________________________________________________________
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
