Monday, 2024-03-04

opendevreviewMerged openstack/project-config master: Retire OpenStack-Chef: remove project from infra  https://review.opendev.org/c/openstack/project-config/+/91010007:53
*** tosky_ is now known as tosky11:36
fricklerwho is our resident pbr specialist? seems the CI has some issues, I'd just drop tempest-full in favor of the -py3 version, but not so sure about the other failures https://review.opendev.org/c/openstack/pbr/+/91069013:33
fungiit's mostly been stephenfin, clarkb and me these days13:35
fungii think tempest-full is in there mainly to keep pbr changes from breaking tempest jobs on stable branches that haven't dropped python 2.7 support yet13:36
clarkbfungi: correct15:26
clarkbbecause you can't easily control the version of pbr used due to how install requires work15:26
clarkbthe fix for that previuosly has been to override projects from stable branches to tags as the transition happens15:26
clarkbI think that we're approaching the point where swift may be one of the only things caring about python2.7? One option may be to replace that tempest full job with a swift install job or something along those lines15:27
fricklertimburke: ^^ is there a standalone swift job without devstack?15:31
fungifwiw, looks like pbr is the only project running the tempest-full job since a while, and it was passing up until something changed between 2024-02-06 02:34:20 utc (last success) and 2024-02-07 02:39:57 utc (first failure)15:35
fungilast non-pbr run of that job was for an openstack/keystone stable/train branch change in december15:36
clarkbthe job runs against ussuri in pbr I think as that was the last python2.7 release?15:37
clarkboh nope its train15:37
clarkbI was off by one15:37
fungiopenstack/python-openstackclient (stable/train) and openstack/requirements (stable/stein) also ran it circa september15:38
clarkbfwiw it is good that we got a -1 on https://review.opendev.org/c/openstack/pbr/+/909581 that is appropriate15:38
clarkbI'm going to -2 that change15:38
fricklertrain was eoled some weeks ago, so things would have to be replaced by tags indeed15:38
clarkbfrickler: ya I'm guessing the set of overrides is simply incompelte at this point and needs to be updated. That is probably a good intermediate step15:39
fungiyeah, my guess, without checking, is that the bulk of the stable/train eol happened around the time that job began failing15:40
frickleryes, some followup to https://review.opendev.org/c/openstack/pbr/+/906072/2/.zuul.yaml will be needed for all other required repos15:40
fricklerthen next I'm wondering why this periodic job seems to have stopped running on Feb 29 https://zuul.opendev.org/t/openstack/builds?job_name=pbr-installation-openstack&project=openstack/pbr15:44
clarkbok I posted a -2 to https://review.opendev.org/c/openstack/pbr/+/90958115:44
clarkbit is unfortunate that PBR has become an attractive nuisance around python2 cleanup15:44
clarkbfrickler: the pbr-installation-openstack job may try and use tripleo repos that were removed?15:45
clarkboh yup thats what https://review.opendev.org/c/openstack/pbr/+/910690/2/.zuul.yaml aims to fix15:47
clarkbwe might need to squash these two changes together?15:47
fricklerno, the failure appeared on Feb 22. seems pip freeze output changed: testtools.matchers._impl.MismatchError: 'pkg-b' not in 'build==1.0.3\npackaging==23.2\npbr @ file:///home/zuul/src/opendev.org/openstack/pbr\npkg_b==0.0\npyproject_hooks==1.0.0\ntest_markers==0.0\ntomli==2.0.1'15:48
fricklerpkg_b vs. pkg-b15:48
fungipip's project name normalization bites us again15:48
fungihttps://virtualenv.pypa.io/en/latest/changelog.html15:51
fungithat likely coincides15:51
clarkbso we have three things: train-eol overrides on tempest-full, fixing package install checks with normalized names and the tripleo project removals.15:52
clarkbI've got a change in progress for the first, gmann pushed one for the third thing, just need a fix for the normalization15:53
fungiv20.25.1 (2024-02-21) was uploaded to pypi 2024-02-22 01:45:30 utc15:53
fungiUpgrade embedded wheels: setuptools 69.0.3 to 69.1.0, pip 23.3.2 to 24.015:53
fungipip 24.0 release notes mention https://github.com/pypa/pip/pull/12477 which talk about setuptools 69 preserving ) in name metadata rather than converting to -15:55
fricklerah, I've been trying to compare good and bad job logs, but plain "pip freeze" doesn't report the pip version itself15:56
fungier, preserving _ i mean15:56
opendevreviewClark Boylan proposed openstack/pbr master: Add more train-eol overrides for python2 tempest-full  https://review.opendev.org/c/openstack/pbr/+/91096115:56
clarkbwe will likely need to squash all these fixes together but there is a split out train-eol override change15:56
fricklerfungi: that sounds very much like the issue we see15:57
fungifrickler: yeah, its probably some change in package name normalization by pip 24.0 and/or setuptools 69 which got quietly updated in a patch release of virtualenv around the time the failures started15:57
clarkbya immediately zuul returns a -1. I'll squash into gmann's change and then yall can squash into that15:58
opendevreviewClark Boylan proposed openstack/pbr master: Omnibus PBR CI fixups  https://review.opendev.org/c/openstack/pbr/+/91069016:01
clarkbthat test installs pkg_b and expects that pip freeze will list it as pkg-b. pip/setuptools/etc updated to preserve pkg_b instead of normalizing to pkg-b?16:05
clarkbif so I can quickly update 910690 to s/-/_/ if we think that is appropriate16:05
clarkbthe test case is checking that python version markers work so the actual python package we isntall isn't super critical I don't think16:06
fungichecking git blame might be good to see if there was a normalization-related reason for that check, but yeah seems like it was just "match the expected output" and now the expected output has changed due to external forces16:06
clarkbya if this test was testing normalization I would be more concerned, But it just wants to check that we can use python version markers16:07
clarkbya code was always written that way I think ebacuse it normalized that way16:08
fricklermaybe make the check work with both variants? like some distro may still be building+testing with older pip?16:09
opendevreviewClark Boylan proposed openstack/pbr master: Omnibus PBR CI fixups  https://review.opendev.org/c/openstack/pbr/+/91069016:09
clarkbhrm ya I guess we acn do that too16:10
opendevreviewClark Boylan proposed openstack/pbr master: Omnibus PBR CI fixups  https://review.opendev.org/c/openstack/pbr/+/91069016:15
clarkbthe tempest full job was/is running on jammy? Overriding devstack to train-eol caused the job to fail beacuse the test node wasn't supported. We should've previously been checking out stable/train of devstack though so I'm really confused how this was passing previously16:28
clarkbwhen it passed it ran on bionic16:29
clarkboh I know when stable/train was a branch it got the stable/train devsatck configs16:30
clarkbbut now that branch is goen that info is gone so we have to override it ourselves I guess16:30
clarkband this creates a problem beacuse devstack has special nodesets /me will figure this out16:30
fungiwe should be able to copy the nodeset definition from the train-eol tag?16:37
clarkbyup. The nodeset is still alive on master actually16:37
clarkbthis is one of thsoe things that I would like to see projects cleaning up around release time, so I've gone ahead and copied it over with a new name to make it more stable16:38
clarkbjust waiting on test results before pushing a new patchset to see if anything else needs fixing16:38
opendevreviewClark Boylan proposed openstack/pbr master: Omnibus PBR CI fixups  https://review.opendev.org/c/openstack/pbr/+/91069016:50
clarkbok this still fails and it points out a problem17:00
clarkbwe're running the newer job definition even with devstack told to checkout train-eol17:00
clarkbcurrent issue is we appear to be using global virtualenvs but we shouldn't for that old job. I'm going to set the flag to disable that, but if that doesn't work then maybe we should consider dropping the job and adding a swift install check job17:01
clarkbor just relying on python2 unittests to ensure compatibility17:01
clarkboh no the issue is even more subtle than that. We ran ensure-virtualenv previously but no logner do that beacuse we assume we can use python3 -m virtualenv?17:05
clarkbso ya the tempest-full job while existing in newer devstack does not appear to work anymore/17:05
clarkbah ya beacuse tempest defines the job but devstack managed the setup and with stable/train tempest gone that setup specific to python2 is gone17:06
clarkbI'm going to propose we just remove the job, keep the unittests running python2 and if swift wants extra coverage can help us add a swift job to pbr cc timburke 17:06
opendevreviewClark Boylan proposed openstack/pbr master: Omnibus PBR CI fixups  https://review.opendev.org/c/openstack/pbr/+/91069017:13
clarkbgmann: ^ fyi it might be time to clean that job out of tempest now17:14
opendevreviewClark Boylan proposed openstack/pbr master: Omnibus PBR CI fixups  https://review.opendev.org/c/openstack/pbr/+/91069017:23
opendevreviewClark Boylan proposed openstack/project-config master: CentOS 7 removal prep changes  https://review.opendev.org/c/openstack/project-config/+/91097818:18
opendevreviewClark Boylan proposed openstack/openstack-zuul-jobs master: Cleanup legacy CentOS 7 jobs and nodesets  https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/91097918:19
opendevreviewClark Boylan proposed openstack/project-config master: CentOS 7 removal prep changes  https://review.opendev.org/c/openstack/project-config/+/91097818:24
opendevreviewClark Boylan proposed openstack/project-config master: CentOS 7 removal prep changes  https://review.opendev.org/c/openstack/project-config/+/91097818:26
gmannclarkb: thakns for updating. will check if any more usage otherwise remove19:06
fungii asked a related question in #openstack-qa19:12
opendevreviewMerged openstack/project-config master: CentOS 7 removal prep changes  https://review.opendev.org/c/openstack/project-config/+/91097821:49
clarkbfungi: frickler https://review.opendev.org/c/openstack/pbr/+/910690 did end up passing. If we're happy with the reduction in python2 test coverage (I think the unittests are probably sufficient) we can proceed with that change21:53
fungilgtm21:56

Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!