Earlier  
Posted Nick Remark
#openstack-nova - 2020-12-09
11:14:30 lyarwood I thouight that was a python version thing
11:14:34 stephenfin I saw something from fungi...somewhere this morning
11:14:59 sean-k-mooney stephenfin: im not sure about that you can tell virtualenv to download and decompress setuptools
11:15:08 sean-k-mooney i think by default it uses your host copy
11:15:58 sean-k-mooney there is a --setuptools<version> flag
11:16:46 stephenfin if that was the case, why is the gate failing? They (Canonical) are hardly releasing new versions of pip on 18.04 still
11:16:47 sean-k-mooney --download might also be needed
11:16:53 sean-k-mooney but i think that is for latest
11:17:01 openstackgerrit Lee Yarwood proposed openstack/nova stable/train: [stable-only] Cap bandit while also raising hacking and flake lower-constraints https://review.opendev.org/c/openstack/nova/+/766171
11:17:02 openstackgerrit Lee Yarwood proposed openstack/nova stable/train: libvirt: Skip encryption metadata lookups if secret already exists on host https://review.opendev.org/c/openstack/nova/+/765771
11:17:11 sean-k-mooney stephenfin: is it devstack or tox
11:17:18 stephenfin lyarwood: this works for me http://paste.openstack.org/show/800886/
11:17:25 sean-k-mooney the job that is failing
11:17:33 sean-k-mooney devstack install pip its self
11:17:52 stephenfin I didn't have to bump bandit, weirdly :-\
11:18:11 lyarwood huh weird I didn't need the stestr changes
11:18:15 lyarwood \o/
11:18:36 lyarwood either way lets see what the gate says
11:18:37 stephenfin lyarwood: for me, it complains that oslo.test 2.6.0 needs stestr 2.0.0
11:18:49 lyarwood that makes sense
11:20:25 lyarwood stephenfin: oh sorry I was using your previous command
11:20:33 lyarwood stephenfin: right so yeah it does, let me update that now
11:20:46 stephenfin ah, whoops, yeah, you need to append '-r requirements.txt .'
11:21:18 stephenfin hahahaha http://paste.openstack.org/show/800887/
11:21:34 stephenfin that's some dependency tree
11:21:47 stephenfin (from pipdeptree)
11:22:02 stephenfin sean-k-mooney: you were complaining about nodejs? ^
11:23:00 openstackgerrit Lee Yarwood proposed openstack/nova stable/train: [stable-only] Cap bandit while also raising hacking, flake and stestr LCs https://review.opendev.org/c/openstack/nova/+/766171
11:23:01 openstackgerrit Lee Yarwood proposed openstack/nova stable/train: libvirt: Skip encryption metadata lookups if secret already exists on host https://review.opendev.org/c/openstack/nova/+/765771
11:25:23 stephenfin I think it's fair to say the idea of maintaining a comprehensive list of lower-constraints will die pretty soon now
11:26:02 sean-k-mooney stephenfin: that has many many duplicates
11:26:24 stephenfin unless that list is updated somewhat regularly, we're going to be playing whack-a-mole as it ages (and it's already pretty well aged)
11:26:53 sean-k-mooney well we are not ment to update it ever for stable brances
11:27:07 sean-k-mooney its only ment to be updated on master
11:27:11 stephenfin you've no choice here. It was wrong
11:27:20 sean-k-mooney it was working previously
11:27:23 lyarwood `working`
11:27:26 lyarwood it wasn't
11:27:29 stephenfin no, it wasn't
11:27:32 lyarwood it's been borked for a while looking at this
11:27:34 sean-k-mooney it was passing ci
11:27:47 lyarwood pip wasn't resolving the deps correctly
11:27:59 lyarwood it does now and so it's failing in CI
11:27:59 stephenfin pass
11:27:59 stephenfin def test_advanced_feature(self):
11:28:00 sean-k-mooney because of the constrits file?
11:28:08 stephenfin advanced feature is working :)
11:28:11 lyarwood the new resolver appears to be doing things correctly
11:28:23 lyarwood the old one didn't
11:28:30 stephenfin previously, the resolver didn't go more than one dependency deep
11:28:38 lyarwood haha really
11:28:38 sean-k-mooney this is a behviaor change
11:28:45 sean-k-mooney we should not be usein gthe new resolve on stable
11:28:56 stephenfin so if you required foo=1.0.0 and bar=2.0.0, but bar required foo=1.2.0, it would work
11:29:04 stephenfin and it no longer will
11:29:14 lyarwood we capped at 20. something but it looks like this has been backported in pip?
11:29:23 stephenfin this is 20.3
11:29:26 lyarwood so unless we lower the cap again
11:29:36 sean-k-mooney stephenfin: the behvioar of the old resovler was if somethign is listed twice we use the first value
11:29:37 stephenfin so we need to cap at less than that
11:29:40 lyarwood yeah I thought 21. broke us
11:29:49 lyarwood with the new resolver
11:29:52 sean-k-mooney that was why the order of deps mattered
11:30:10 stephenfin nah, they clearly don't use semver this isn't a major release
11:30:15 stephenfin *to say this
11:30:39 sean-k-mooney so we need to cap pip right
11:30:49 sean-k-mooney and not modify the lower constraits
11:30:49 stephenfin ah, it's calver
11:31:22 stephenfin we're not changing anything
11:31:29 lyarwood oh it was 20.3
11:31:44 sean-k-mooney stephenfin: you not going to modify lower-constraits on stable. ok
11:31:48 lyarwood https://review.opendev.org/c/openstack/devstack/+/764803 was what I was thinking about in devstack
11:31:59 stephenfin no, we are, but it won't change anything
11:32:04 stephenfin because pip wasn't using that
11:32:17 stephenfin you can prove it locally too
11:32:18 sean-k-mooney pip was in the lower constraits job
11:32:56 stephenfin virtualenv .venv --python=python3.6; source .venv/bin/activate; pip install 'pip<20.3'; pip install -c lower-constraints.txt -r requirements.txt -r test-requirements.txt .
11:32:57 sean-k-mooney the semantics of the old resovler was if it saw x==1 and later x==2 it ignored the x==2
11:33:00 stephenfin then do pip freeze
11:33:11 stephenfin you'll get stestr 2.0.0 and hacking 1.1.0
11:33:13 lyarwood so there was a comment in #openstack-infra that a virtualenv bump introduced pip 20.3 btw
11:33:38 stephenfin (do that on stable/train, obviously)
11:33:40 lyarwood I'm in favor of fixing LC tbh
11:33:45 stephenfin As am I
11:33:55 lyarwood yes it's a change but it's a fix
11:34:05 stephenfin yup
11:34:09 lyarwood and ultimatley you should end up with the same env
11:35:13 lyarwood brb
11:49:51 elod btw, in old stable branches pip should not be version 20.3. so I wonder where this new behavior comes from... :/
11:52:36 elod (as for example, clearly 'hacking===0.12' (in LC) should have contradicted with hacking>=1.0.0 (in test-req) for ages)
11:54:36 elod and pip 20.3 resolver issue only appeared in grenade jobs, where pip is bootstrapped directly from pypi... hmmm...
11:55:19 lyarwood elod: I think the tox jobs are using it now after a virtualenv change that pulls in pip 20.3 by default
11:57:16 elod lyarwood: oh. interesting. so that's why :/
11:58:55 lyarwood elod: that said devstack is now failing to deploy swift so maybe we do need https://review.opendev.org/c/openstack/devstack/+/764876 on stable/train
12:05:08 elod lyarwood: it was/is there in since newton :) https://review.opendev.org/c/openstack/devstack/+/269954
12:06:03 elod so the issue must be something new with swift :/
12:14:05 lyarwood hmmm I'm not sure that's used with devstack-gate and grenade
12:14:33 openstackgerrit Lee Yarwood proposed openstack/nova stable/train: libvirt: Skip encryption metadata lookups if secret already exists on host https://review.opendev.org/c/openstack/nova/+/765771
12:14:34 openstackgerrit Lee Yarwood proposed openstack/nova stable/train: libvirt: Remove native LUKS compat code https://review.opendev.org/c/openstack/nova/+/766210
12:14:41 lyarwood either way <= stable/train is borked now

Earlier   Later