[openstack-dev] [mistral][oslo.messaging] stable/mitaka is broken by oslo.messaging 5.0.0

Joshua Harlow harlowja at fastmail.com
Wed May 18 15:51:00 UTC 2016


Roman Dobosz wrote:
> On Tue, 17 May 2016 21:41:11 -0700
> Joshua Harlow<harlowja at fastmail.com>  wrote:
>
>>>> Options I see:
>>>> Constrain oslo.messaging in global-requirements.txt for
>>>> stable/mitaka with 4.6.1. Hard to do since it requires wide
>>>> cross-project coordination.
>>>> Remove that hack in stable/mitaka as we did with master. It may
>>>> be bad because this was wanted very much by some of the users
>>>>
>>>> Not sure what else we can do.
>>> You could set up your test jobs to use the upper-constraints.txt
>>> file in
>>> the requirements repo.
>>>
>>> What was the outcome of the discussion about adding the
>>> at-least-once
>>> semantics to oslo.messaging?
>> So there are a few options I am seeing so far (there might be more
>> that I don't see also), others can hopefully correct me if they are
>> wrong (which they might be) ;)
>>
>> Option #1
>>
>> Oslo.messaging (and the dispatcher part that does this) stays as is,
>> doing at-most-once for RPC (notifications are in a different
>> category here so let's not discuss them) and doing at-most-once well
>> and battle-hardened (it's current goal) across the various backend
>> drivers it supports.
>>
>> At that point at-least-once will have to done via some other library
>> where this kind of semantics can be placed, that might be tooz via
>> https://review.openstack.org/#/c/260246/ (which has similar
>> semantics, but is not based on a kind of RPC, instead it's more like
>> a job-queue).
>>
>> Option #2
>>
>> Oslo.messaging (and the dispatcher part that does this) changes
>> (possibly allowing it to be replaced with a different type of
>> dispatcher, ie like in https://review.openstack.org/#/c/314732/);
>> the default class continues being great at for RPC (notifications
>> are in a different category here so let's not discuss them) and
>> doing at-most-once well and battle-hardened (it's current goal)
>> across the various backend drivers it supports. If people want to
>> provide an alternate class with different semantics they are
>> somewhat on there own (but at least they can do this).
>>
>> Issues raised: this though may not be wanted, as some of the
>> oslo.messaging folks do not want the dispatcher class to be exposed
>> at all (and would prefer to make it totally private, so exposing it
>> would be against that goal); though people are already 'hacking'
>> this kind of functionality in, so it might be the best we can get at
>> the current time?
>>
>> Option #3
>>
>> Do nothing.
>>
>> Issues raised: everytime oslo.messaging changes this *mostly*
>> internal dispatcher API a project will have to make a new 'hack' to
>> replace it and hope that the semantics that it has 'hacked' in will
>> continue to be compatible with the various drivers in
>> oslo.messaging. Not IMHO a sustainable way to keep on working (and
>> I'd be wary of doing this in a project if I was the owner of one,
>> because it's ummm, 'dirty').
>>
>> My thoughts on what could work:
>>
>> What I'd personally like to see is a mix of option #1 and #2, where
>> we have commitment from folks (besides myself, lol) to work on
>> option #1 and we temporarily move forward with option #2 with a
>> strict-statement that the functionality we would be enabling will
>> only exist for say a single release (and then it will be removed).
>>
>> Thoughts from others?
>
> Option #4
>
> (Which might be obvious) Directly use RabbitMQ driver, like
> pika/kombu, which can expose all the message queue features to the
> project.
>
> Issues raised: Pushback from the community due not using
> oslo.messaging and potential necessity for implementing it for other
> drivers/transports, or forcing to use particular message queue/driver
> in every project.
>

Isn't this similar/same as to option #1? Nothing about option #1 says 
(from my understanding) that it must be implemented via oslo.messaging 
(and in all likely-hood it can't be).



More information about the OpenStack-dev mailing list