Open Stack

Excerpts from Zane Bitter's message of 2016-05-10 15:13:46 -0400:
> 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.

The telemetry team has discussed pulling out the "listening" part of
ceilometer to make it easier to repurpose for cases like this. In fact,
it might be possible to write a plugin for the existing listeners
without any other changes inside ceilometer itself.

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

Yes, it's also important that this is not configurable with an option
the deployer can set, because it relates to the application's
understanding of how it will process messages and shouldn't be changed.

Doug

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