https://github.com/openstack/requirements/blame/master/README.rst#L95-L100 <https://github.com/openstack/requirements/blame/master/README.rst#L95-L100>
Doug, Is it still relevant? I’m just trying to understand how to enforce upper-constraints.txt in the best way for our jobs like py27, py34 etc. Renat Akhmerov @Nokia > On 19 May 2016, at 12:15, Renat Akhmerov <renat.akhme...@gmail.com> wrote: > >> >> On 18 May 2016, at 22:51, Joshua Harlow <harlo...@fastmail.com >> <mailto:harlo...@fastmail.com>> wrote: >> >> Roman Dobosz wrote: >>> On Tue, 17 May 2016 21:41:11 -0700 >>> Joshua Harlow<harlo...@fastmail.com <mailto: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/ >>>> <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/ >>>> <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). > > > We’ll most likely proceed with #1 (special case is #4) for now just for > progress sake. > > It seems to me that we as a community may just need to accumulate more > data/experience/patterns well realized so that we could explain value of > certain patterns more clearly. Through our endeavours and researches > hopefully we’ll be able to communicate our thoughts better. As far as > semantical differences RPC vs Messaging vs Jobs vs Notifications vs Concrete > implementation of any of those, it’s simply a matter of how we want to do it, > less a matter of what is right. I’m just saying this that it’s OK for now > that we can’t come to a consensus. We need to keep in touch and exchange our > ideas. Excuse me, it’s just a lyric digression. > > Renat Akhmerov > @Nokia
__________________________________________________________________________ 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
