[openstack-dev] [oslo][mistral] Saga of process than ack and where can we go from here...
dtantsur at redhat.com
Mon May 9 06:49:47 UTC 2016
On 05/07/2016 01:00 AM, Joshua Harlow wrote:
> Dmitry Tantsur wrote:
>> On 05/03/2016 11:24 PM, Joshua Harlow wrote:
>>> 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):
>>> 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.
>> Hey, lemme weigh in from ironic-inspector PoV.
>> As you maybe remember, we also need a queue with possibility of both
>> ways of ack'ing for our HA work. So something like this patch doesn't
>> seem to help us at all. We'll probably have to cargo-cult the mistral
> U seem to be thinking about the queue as an implementation vs thinking
> about what API do u really need and then say backing that API by a queue
> (if u so want to).
> Thus where https://review.openstack.org/#/c/260246/ comes into play here
> because it thinks about the API first and the impl second (and if u
> really want 2 impls, well they are at
> but I'm avoiding trying to bring those into the picture, because the
> top-level API seems unclear here still).
> I guess it goes back to the 'why are people trying to use a message
> queue as a work queue' when the semantics of these are different (and
> let's not get into why we use a message queue as an RPC layer while we
> are at it, ha).
And I have a trivial answer: because that's all we have working right now ;)
>> Is it possible to have a manual ack feature? I.e. for the handler to
>> choose when to ack.
>>> I also would like to come to some kind of understanding that we also
>>> (mistral folks would hopefully help here) would remove this kind of
>>> change in the future as the longer term goal (of something like
>>> https://review.openstack.org/#/c/260246/) would progress.
>>> Thoughts from folks (mistral and oslo)?
>>> Anyway we can create a solution that works in the short term (allowing
>>> for that hack to be removed) and working toward the longer term goal?
>>> OpenStack Development Mailing List (not for usage questions)
>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> OpenStack Development Mailing List (not for usage questions)
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev