Open Stack

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):
>>>
>>> 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.
>>
>> 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
>> approach.
>
> 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
> https://github.com/openstack/taskflow/tree/master/taskflow/jobs/backends
> 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?
>>>
>>> -Josh
>>>
>>> __________________________________________________________________________
>>>
>>>
>>> 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
>
> __________________________________________________________________________
> 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