Open Stack

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.akhmerov at gmail.com> wrote:
> 
>> 
>> On 18 May 2016, at 22:51, Joshua Harlow <harlowja at fastmail.com <mailto:harlowja at fastmail.com>> wrote:
>> 
>> Roman Dobosz wrote:
>>> On Tue, 17 May 2016 21:41:11 -0700
>>> Joshua Harlow<harlowja at fastmail.com <mailto: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/ <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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160519/fa0f3da2/attachment.html>