Open Stack

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

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