Open Stack

On 10/15/2015 06:00 PM, Robert Collins wrote:
> ...
>>> Now there is an explicit list of what works.
>>>
>>> Isn't that *better* ?
>>>
>> Yes, it's good to know what works, does that show multiple versions of
>> the same package when multiple are known to work?
> 
> It shows the highest version we know to work. So you could in
> principle take any version less than that that is permitted by the
> package-local requirements. E.g. consider oslo.messaging and Nova.
> 
> Nova's dep on oslo.messaging is:
> oslo.messaging>=1.8.0 # Apache-2.0
> 
> upper-constraints is:
> oslo.messaging===2.5.0
> 
> So any version >= 1.8.0 and <= 2.5.0
> 
> We haven't successfully tested 2.6.0 (or it would be in
> upper-constraints), and we didn't have any failures with versions in
> between (or they would be listed in Nova's requirements as a != line.
> 
> BUT: we haven't (ever!) tested that the lowest versions we specify
> work. When folk know they are adding a hard dependency on a version we
> do raise the lower versions, but thats adhoc and best effort today.
> I'd like to see a lower-constraints.txt reflecting the oldest version
> that works across all of OpenStack (as a good boundary case to test) -
> but we need to fix pip first to teach it to choose lower versions over
> higher versions (https://github.com/pypa/pip/issues/3188 - I thought
> I'd filed it previously but couldn't find it...)
> 
> More generally, we don't [yet] have the testing setup to test multiple
> versions on an ongoing basis, so we can't actually make any statement
> other than 'upper-constraints.txt is known to work'. Note: before
> constraints we couldn't even make *that* statement. The statement we
> could make then was 'if you look up the change in gerrit and from that
> the CI dvsm test run which got through the gate, then you can
> figureout *a* version of the dependencies that worked.
> 
Thanks, this is what I was hoping.  That is, that I could use this as a
cap (even if it moves, I'm happy with moving caps :D).

>>  If so I can build a
>> range from that.  It's not better as it is because I still don't know
>> where liberty ends and mitaka begins.  Is there any place I can find that?
> 
> We don't always release every library in every release. See for
> instance this warning from Juno's global-requirements.txt:
> 
> # NOTE(tonyb): the oslo.utils acceptable versions overlap in juno and kilo
> # please ensure that any new releases are handled carefully
> oslo.utils>=1.4.0,<1.5.0 # Apache-2.0
> 
> So - there may not in fact *be* a line where liberty ends and mitaka begins.
> 
> And if we can sort out the backwards compat stuff, we should be able
> to actually get rid of that distinction, and instead say the much
> simpler thing 'we're compatible with everything released while this
> branch is supported'.
> 
> But in the interim, we're using semver everywhere, so at least for the
> internal dependencies, you could just set a cap on the next major
> version within Gentoo. It may be too restrictive, but it should work
> (and if it doesn't then we've failed at semver and we need to figure
> out how not to do that).
> 
I can use caps from upper-reqs.txt as that seems to be the best solution
atm.

>> What about a daily or weekly check without the constraints file so you
>> know when something breaks?
> 
> We generate a new list daily with the latest releases on PyPI:
> http://logs.openstack.org/periodic/propose-requirements-constraints-master/5b4e488/console.html
> is an example log from the generation of such an update. That gets
> proposed to the requirements project and can be reviewed here -
> https://review.openstack.org/#/q/status:open+project:openstack/requirements+topic:openstack/requirements/constraints,n,z
> 
> So we see things that break, and then we can propose != exclusions for
> them (or if its better, fixes to our projects - depends on the nature
> of the interaction and so on).
> 
>>  This would allow you to at least know when
>> you need to place caps and I could consume that.
> 
> Ish - it tells us where things break, and from that we can decide on
> exclusion (single bad release) or cap (deliberate API break they won't
> roll back). Caps are massively more disruptive, so we try to avoid
> them.
> 
Right, bad phrasing.

>> I'm fine with leaving
>> caps off.  If I can consume mitaka deps in liberty then that's great :D
> ...
>> It's a step backwards from my perspective, before I had a clear
>> delineation where support of something stops.  Now I don't know when it
>> stops and any given update could break the system.  I'm not sure how it
>> could be smoother for other systems.
> 
> The problem is, you didn't actually have such a line (as should be
> evident by the fact we've broken juno again and again and again since
> th release).
> 
I was primarily talking about kilo, I dropped juno as fast as I could
because of how bad it became.  kilo has been much better.

>> So, does this mean that I can just leave the packages uncapped and know
>> that they will work?  Are there tests being run for this scenario?
> 
> No, though I *want* us to get to that place, and thats the debate
> we're having about backwards compat in clients and libraries.
> 
> {Note that we've never systematically capped third party libraries and
> so they are always a potential surprise too - but its again the
> balance between presume-bad and presume-good behaviour from the
> upstreams}.
> 
> -Rob
> 
Thanks for the replies, I think I have a way forward (using upper-reqs
as a cap).  I might need to make a tool that munges the (test-)reqs.txt
to generate one as an easier reference.  having to open up two files to
reference is kinda annoying.

-- 
Matthew Thode (prometheanfire)