Open Stack

Dmitry Tantsur wrote:
> 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 ;)

Ya, that's what I expected :-/

I wonder how we can think about/work towards the longer/better path 
instead of the short term (it works sorta right now)... It reminds me of 
this saying, 'when all u have is a hammer, everything looks like a nail',

https://en.wiktionary.org/wiki/if_all_you_have_is_a_hammer,_everything_looks_like_a_nail 
(for those who have no idea what this means) ;)

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