Excerpts from Doug Hellmann's message of 2016-05-03 16:45:47 -0500: > Excerpts from Joshua Harlow's message of 2016-05-03 14:24:13 -0700: > > Howdy folks, > > > > So I meet up with *some* of the mistral folks during friday last week at > > the summit and I was wondering if we as a group can find a path to help > > that project move forward in their desire to have some kind of process > > than ack (vs the existing ack then process) in there usage of the > > messaging layer. > > > > I got to learn that the following exists in mistral (sad-face): > > > > https://github.com/openstack/mistral/blob/master/mistral/engine/rpc.py#L38 > > > > And it got me thinking about how/if we can as a group possibly allow a > > variant of https://review.openstack.org/#/c/229186/ to get worked on and > > merged in and release so that the above 'hack' can be removed. > > Based on the comments on that patch, it looks like the consensus was to > add a new method (to the client & dispatcher & whatever else needs it) > to implement the new semantics. That way it's clear from the caller > side what is expected, and it even makes it possible to adopt the new > capability in other projects without having to go all-or-nothing. > > That said, I agree with Mehdi that *most* RPC calls throughout OpenStack, > not being idempotent, should not use process-then-ack.
We also need to understand how the new semantics work for drivers other than Rabbit. We have a lot of renewed interest in zmq for example. Doug __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
