... >> 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 <rbtcoll...@hp.com> Distinguished Technologist HP Converged Cloud __________________________________________________________________________ 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
