Open Stack

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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev