| *** ykarel_ is now known as ykarel | 06:01 | |
| *** elodilles_pto is now known as elodilles | 08:13 | |
| elodilles | hi o/ | 08:13 |
|---|---|---|
| elodilles | (sorry for the sudden pto, but actually i was down with some 'flu-like' illness with high fever in the past days :S but now i'm back \o/ ... not 100% well yet, so will start slowly...) | 08:14 |
| opendevreview | Merged openstack/releases master: Replace SLURP diagram with fancier version https://review.opendev.org/c/openstack/releases/+/940417 | 12:05 |
| elodilles | noonedeadpunk: hi o/ sorry, a question, do we wait for anything for OSA's 2023.1 Antelope branches to move unmaintained? it would be good to set 2023.1 Antelope state back to 'Unmaintained' as soon as possible | 12:23 |
| noonedeadpunk | elodilles: so I'd need to land https://review.opendev.org/c/openstack/openstack-ansible/+/939944 | 12:27 |
| noonedeadpunk | but I really do not understand so far why deploy guide is failing... | 12:27 |
| noonedeadpunk | so if you can have a brief look on this one - it will be much appreciated | 12:27 |
| opendevreview | Elod Illes proposed openstack/releases master: Transition unmaintained/victoria to EOL https://review.opendev.org/c/openstack/releases/+/937515 | 12:36 |
| opendevreview | Elod Illes proposed openstack/releases master: Transition unmaintained/victoria to EOL https://review.opendev.org/c/openstack/releases/+/937515 | 12:44 |
| elodilles | noonedeadpunk: ACK, looking | 12:44 |
| opendevreview | Elod Illes proposed openstack/releases master: Transition unmaintained/victoria to EOL https://review.opendev.org/c/openstack/releases/+/937515 | 13:02 |
| elodilles | noonedeadpunk: locally i cannot reproduce the issue as things build fine. maybe tox / virtualenv / setuptools or something needs to be pinned. | 13:18 |
| elodilles | (well i have some breakage in a ubuntu-noble env, definitely coming from setuptools, but that's a bit different...) | 13:21 |
| noonedeadpunk | yeah, so had a hassle as well... | 13:22 |
| noonedeadpunk | and it obviously used to work before... so it's smth related to unmaintained, I guess... But I can't figure what exactly so far | 13:22 |
| frickler | oh, I think that's related to some sphinx bump, but that has been a while | 13:26 |
| frickler | looks like the job is pulling sphinx-8.1.3, so something broken about u-c | 13:27 |
| frickler | yes, pulling requirements from master, likely since stable/2023.1 is gone https://storage.bhs.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_5de/939944/2/check/build-openstack-deploy-guide/5dec858/zuul-info/inventory.yaml | 13:29 |
| frickler | noonedeadpunk: so I'd suggest to just make that job non-voting for now, it should work again on unmaintained/2023.1 | 13:29 |
| frickler | (the other option would be to override the requirements checkout to the correct branch) | 13:31 |
| opendevreview | Elod Illes proposed openstack/releases master: Transition unmaintained/victoria to EOL https://review.opendev.org/c/openstack/releases/+/937515 | 13:31 |
| noonedeadpunk | oh, that's a good one. | 13:34 |
| noonedeadpunk | anyway makes sense to override checkout for u-c in tox | 13:34 |
| noonedeadpunk | thanks frickler! | 13:34 |
| noonedeadpunk | as indeed it takes u-c from zuul, which has master u-c | 13:35 |
| opendevreview | Merged openstack/releases master: Release magnum 18.0.1 for caracal https://review.opendev.org/c/openstack/releases/+/940235 | 13:42 |
| opendevreview | Merged openstack/releases master: Release os-traits 3.3.0 https://review.opendev.org/c/openstack/releases/+/940363 | 13:42 |
| opendevreview | Merged openstack/releases master: python-openstackclient 7.1.4 https://review.opendev.org/c/openstack/releases/+/940190 | 13:48 |
| opendevreview | Merged openstack/releases master: Add dates for 2025.2/"F" elections https://review.opendev.org/c/openstack/releases/+/939927 | 14:11 |
| fungi | just a heads up, when https://review.opendev.org/940273 merges in zuul/zuul-jobs, we're going to want to do an immediate release-test test. i suspect some parts of openstack's release automation may not yet be compatible with the sdist filename normalization in newer setuptools | 15:00 |
| fungi | basically, - and . in the project name part of an sdist's filename will get transformed to _ like already happens with wheel filenames | 15:00 |
| fungi | so the good news is that this will silence the warnings we've been getting from pypi for months any time we release a project with a - or . in its name, and we presumably already have name transformation routines in place for dealing with matching wheel filenames, but we'll probably need to adapt those to do the same for sdists going forward | 15:02 |
| frickler | fungi: do you want to propose that release-test release? should I hold back from approving those zuuljobs changes until that is ready? | 15:02 |
| fungi | i can go ahead and propose it, sure. it turns out 940273 will *also* probably make it possible for our release jobs to run on noble now | 15:03 |
| elodilles | ACK, ping me if we need to +2+W the release-test release | 15:13 |
| opendevreview | Jeremy Stanley proposed openstack/releases master: Releasing release-test https://review.opendev.org/c/openstack/releases/+/940458 | 15:13 |
| fungi | frickler: elodilles: ^ | 15:13 |
| fungi | once we're ready | 15:14 |
| elodilles | +1 | 15:16 |
| opendevreview | Jeremy Stanley proposed openstack/releases master: Releasing release-test https://review.opendev.org/c/openstack/releases/+/940458 | 15:35 |
| clarkb | fungi: those zuul-jobs changes have the +2s they need if you want to +A in coordination with ^ | 15:54 |
| frickler | they don't share a queue, so we'll need to wait for them to be merged first? I can approve the test patch right after that | 16:01 |
| clarkb | yes that sounds right | 16:03 |
| fungi | agreed | 16:04 |
| fungi | i've approved 940273 in zuul/zuul-jobs now | 16:19 |
| fungi | looks like it hit something that caused one of its gate jobs to fail uploading logs, so it's likely to take some time to land | 16:27 |
| frickler | bummer. seems we're also a bit slow in getting jobs started in the first place | 16:39 |
| fungi | yes, seems that way | 16:39 |
| clarkb | there is a stack of kolla-ansible changes that could use our quote a few times over in the openstack check queue | 16:44 |
| frickler | ah, right, I just checked the queue length and that didn't look too bad. but yes, those changes touch some central parts of kolla and thus trigger most available jobs | 16:52 |
| fungi | rechecked 940273 just now | 17:04 |
| fungi | things seem to have sped up, eta 2 minutes to merge | 17:17 |
| fungi | and it's merged, 940458 can be approved now | 17:20 |
| fungi | also i strongly recommend *not* approving any other release requests until we see 940458 work all the way through | 17:31 |
| clarkb | any reason to not approve it as is? I guess just waiting for a second reviewer? | 17:42 |
| clarkb | wondering how necessary that is for release-test | 17:42 |
| fungi | i think it's just waiting for someone with approval rights to get back to their keyboard | 17:45 |
| frickler | yes, did that now, sorry for the delay | 17:53 |
| clarkb | thanks! I just didn't want everyone to go into a fosdem coma this weekend and have it get ignored | 17:53 |
| fungi | no need to apologize! just trying to keep the window of broken as narrow as possible if we need to make adjustments | 17:54 |
| fungi | perfect timing actually, since i'm done with lunch and can analyze job logs as soon as they're up | 17:55 |
| fungi | granted, it looks like we're being treated to another long wait for nodes | 17:59 |
| fungi | eta 5 minutes, then we should get the tag job enqueued | 18:07 |
| opendevreview | Merged openstack/releases master: Releasing release-test https://review.opendev.org/c/openstack/releases/+/940458 | 18:11 |
| fungi | so far so good | 18:11 |
| fungi | tag-releases is running | 18:12 |
| clarkb | its done and now the reelase pipeline has jobs | 18:14 |
| fungi | yeah, and release-openstack-python is finally running now... this is really the first part i'm particularly wary of, making sure the signing and upload tasks still find the right sdist filename after newer setuptools normalizes the - to a _ | 18:21 |
| clarkb | and assuming we get all the way to pypi we probably fetch the artifacts and inspect them for completeness? | 18:22 |
| fungi | sdist contents look right | 18:23 |
| fungi | signed and uploaded, i think? | 18:23 |
| fungi | yeah, even though it's openstack_release_test in the filename now | 18:23 |
| fungi | i guess we rely on wildcards there so it "just works" | 18:24 |
| clarkb | https://pypi.org/project/openstack-release-test/8.0.0/#files | 18:24 |
| clarkb | and ya that sdist has content that I would expect. The version is correct | 18:26 |
| fungi | yep, so i think the releasing part is working, the only remaining concerns i have are for the check scripts the release managers run manually that check for the existence of artifacts on tarballs.o.o and pypi | 18:26 |
| fungi | hopefully we can get a release manager to exercise those as soon as is convenient, but that's far less urgent since it looks like the actual releasing isn't breaking at least | 18:26 |
| fungi | also no warning e-mail from pypi this time, as hoped | 18:28 |
| fungi | so it seems like that's finally solved | 18:29 |
| fungi | also this presumably unblocks moving release jobs to noble now | 18:29 |
| clarkb | I think you may still need the zuul-jobs update to install twince to a venv | 18:30 |
| clarkb | *twine | 18:30 |
| fungi | oh, good point | 18:30 |
| clarkb | since twine is a separate tool from pyproject-build | 18:30 |
| fungi | i forgot it was being pip installed into the system python environment | 18:30 |
| clarkb | it was using --user, but ya | 18:31 |
| clarkb | (I still don't understand why --user is considered bad but that ship has long sailed I'm sure) | 18:31 |
| fungi | because if you run a system python application in your user account, it may pick up libs installed in ~/.local | 18:32 |
| fungi | and that was apparently also adding confusion | 18:32 |
| clarkb | wow ya that is compeltely unexpected behavior from python | 18:33 |
| fungi | well, i mean, that's how pip install --user was designed to work. it was simply a bad idea | 18:34 |
| fungi | the --user installs don't go into a venv, they're user-specific lib installs | 18:35 |
| fungi | so it's like having a venv that's always activated and has system-site-packages imports enabled | 18:36 |
| fungi | but specific to that user | 18:36 |
| *** hspease99[m] is now known as hspease[m] | 19:04 | |
| elodilles | fungi: clarkb: i've quickly run the missing-releases command (with a minor modification to check release-test as well because that is by default skipped :S) and the result is this: https://paste.opendev.org/show/bKcD3cPZiHm8YcH3GVAg/ | 19:32 |
| elodilles | so this tool needs some update as well | 19:32 |
| elodilles | but that should be an easy update i guess | 19:33 |
| fungi | i suspected that would be the case | 19:34 |
| fungi | but yeah, simple to fix and only critical as we get closer to the coordinated release | 19:35 |
| fungi | all in all this broke a lot less stuff than i anticipated | 19:35 |
| elodilles | +1 | 19:36 |
| elodilles | wow. doing a grep on deliverables/epoxy/* for 'tarball-base' shows weird inconsistency... half of the deliverables are with '_' the other half with '-'... so might be we don't even have an issue, just release-test is configured wrongly in tarball-base field... | 19:49 |
| elodilles | anyway, i'm out for the day, as we don't have to solve this today o:) | 19:50 |
| elodilles | (rewriting to 'tarball-base: openstack_release_test' the command passes for release-test...) | 19:53 |
| fungi | yes, the change we merged to zuul-jobs technically didn't do this, newer setuptools did | 20:27 |
| fungi | the change we merged just happens to result in latest setuptools getting used when building the sdist and wheel | 20:28 |
| fungi | so anything else that resulted in setuptools 70.2.0 or newer being used would have had the same effect | 20:28 |
| fungi | (and that setuptools release was made on 2024-07-01 so it's been quite a while) | 20:29 |
| clarkb | its probably a good idea to check what you have as an input then also check the normalized form though | 21:20 |
| clarkb | unless you want to force everything to be input in the normalized form in the first place | 21:21 |
| fungi | yeah, i mean, that's going to be necessary for backwards compatibility. that script checks ancient releases not just the most recent | 21:30 |
| clarkb | ah yup then you'd need to check both forms | 21:31 |
| fungi | looks like the release team meeting tomorrow is skipped, so i'll try to provide some reminders next week | 23:17 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!