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