Open Stack

...
>> 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.

>  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).

> 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.

> 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).

> 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

-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud