On Tue, 17 May 2016 21:41:11 -0700 Joshua Harlow <harlo...@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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev