Open Stack

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.

-- 
Cheers,
Roman Dobosz