Wednesday, 2026-04-01

*** ykarel_ is now known as ykarel04:09
ttxHappy release day!06:43
ttxWearing my "Well, it worked in DevStack" t-shirt to celebrate06:43
opendevreviewRodolfo Alonso proposed openstack/releases master: Release stable/2026.1 ovsdbapp 2.16.1  https://review.opendev.org/c/openstack/releases/+/97946006:59
fricklerCI is looking fine afaict, so start the countdown ;)08:32
elodillesyepp, so far so good08:34
elodillesfingers crossed :]08:34
ttxPatch is ready to W+109:44
elodillesyepp09:46
elodillesthe plan is to +W at 10:00 UTC, but we can do it sooner if you think09:47
fungiokay, i'm awake(ish)09:48
elodillesgood morning fungi o/09:49
elodilles"All Systems Operational" according to status.pypi.org09:49
elodilleshttps://status.python.org/09:49
elodillesto be precise...09:49
elodilleszuul & gerrit seems to be fine, too09:50
fungii agree things look healthy in zuul09:50
fungii love the smell of new releases in the morning09:51
elodilles🚬 :)09:51
elodilleskolla doesn't have too many patches on the gate either o:)09:52
elodilleswhich is a good opportunity to start the release :D09:52
elodillesokay, let's do it. i'm impatient o:)09:55
* elodilles +W'd the release patch09:56
fungiyay!09:56
fungizuul estimates we're 2 minutes from merging10:05
elodillesyeah, but it's based on the usual release patches and this has many releases, so validate job will take its time o:)10:07
elodilles2025.2 Flamingo release patch finished 32 mins in October :)10:07
elodillesand i think we had worse than that before. once it took like 50+ mins10:08
fungiyeah, i think zuul underestimates the runtime for releases-tox-validate because that job doesn't normally have to iterate over as many projects10:09
elodillesyepp10:10
fungiwatching the log stream gives a better indication of progress10:10
fungiwe're ~halfway through the alphabet10:11
elodillesyepp, we are at letter 'n' so far :]10:13
elodillesthough 'o' and 'p' is a bit overrepresented i think10:14
elodillesbut things are moving10:14
elodillesthe soup is "cooking" (if i can say that to a cold soup o:))10:16
ttxSean Michael Kerner said his Gazpacho article will be full of soup puns10:17
elodilles:)10:18
fungislurp-slurp!10:20
fungii trust smk's comedy routine10:21
fungivalidation has reached the end of the alphabet10:22
elodilleszun10:23
elodillesshould be the last?10:24
fricklercongratulations :) (1518.81 seconds)10:24
fungiyes10:24
elodillesit's still running by me :-o10:24
opendevreviewMerged openstack/releases master: 2026.1 Gazpacho final releases for cycle-with-rc projects  https://review.opendev.org/c/openstack/releases/+/98243810:24
elodillesthere it is ^^^ \o/10:25
elodillesnow the post jobs10:25
fungithis time you can even see the node request for tag-releases in action on the requests tab10:28
elodilles:-o10:28
fungiaccepted and building in rax-ord10:28
fungii guess nova is being a little slow there10:29
fungibut the job's finally running now10:32
fungiadjutant-ui has entered the release pipeline10:33
fungifollowed by a lot more10:33
elodilleshttps://zuul.opendev.org/t/openstack/status/pipeline/tag10:34
elodillesdeliverables are popping up :-o10:34
fungihttps://pypi.org/project/adjutant-ui/#files has our uploaded sdist and wheel10:37
funginow a few seconds old10:37
elodillesadjutant-ui -- Wed, 01 Apr 2026 10:36:57 GMT -- 12.0.010:38
elodillesyepp10:38
elodillesand yepp, release pipeline is also increasing, now 42 items: https://zuul.opendev.org/t/openstack/status/pipeline/release10:45
elodilles#50 and 15 events :-o10:50
elodilles(sorry, that was 'result events' :))10:51
elodilles5510:51
elodilleszun is on the list and now the count is slowly decreasing10:54
elodillesthe count is 10 and i think that missing-releases can be started as the relevant jobs have finished11:05
elodilles(the remaining jobs are 'announce-release' and 'propose-update-constraints' jobs)11:06
fricklerrunning11:07
fungii think we'll have at least the manila rc1 missing from this cycle that's already known11:08
fungi(because pypi wouldn't accept it)11:08
elodilleswell, the script checks for the latest releases, so manila final release should be fine11:09
elodillesmanila -- Wed, 01 Apr 2026 11:01:04 GMT -- 22.0.011:09
fungiah okay, i thought this was the one that checked for missing files from all releases11:09
elodillesfungi: https://paste.opendev.org/show/bhsyYPItEeBcWdaLlKIE/11:12
fungiyep cool, thanks11:13
ttxbreaking for lunch, brb11:14
elodillesbon apetit o/11:15
elodillesrelease pipeline is empty11:15
elodillestag pipeline still has nova in it :)11:15
elodillespublish-openstack-releasenotes-python3 is running there for almost 30 mins now11:16
funginova's reno runs are massive11:16
fricklerno missing-releases issues found for me11:20
fricklerelodilles: ready for https://review.opendev.org/c/openstack/openstack-manuals/+/981758 then? or wait for nova renos to be done?11:22
frickleriiuc they have a lot of translations11:24
fungino new messages in https://lists.openstack.org/archives/list/release-job-failures@lists.openstack.org/ so as long as the nova release notes build succeeds we appear to be in the clear11:28
fricklercurrently building ko_KR, not sure how many langs still come after that11:29
frickleroh, was the final one11:29
fricklernow waiting for elodilles to unblock the docs update11:32
elodillesyepp. nova reno job has finished \o/11:35
elodillesand no missing-releases in my run either11:36
elodilles(well, two false alarm i think:11:36
elodilles  did not find python 3 wheel https://tarballs.openstack.org/ansible-role-atos-hsm/ansible_role_atos_hsm-11.0.0-py3-none-any.whl11:36
elodilles  did not find python 3 wheel https://tarballs.openstack.org/ansible-role-thales-hsm/ansible_role_thales_hsm-11.0.0-py3-none-any.whl11:36
elodillesbut these are "known" issues afair)11:36
elodillesfrickler: yes, i think you can +W the openstack-manuals patch, though we have plenty of time fortunately11:38
fricklerwell those have combined wheels still, so not an issue? they also have no change merged for multiple cycles, which confused me with the "diff-start" anomaly once again (like every cycle I need to dig deep to remember what is going on there)11:38
elodillesyes, unfortunately those are quite abandoned repos :/11:40
elodillesnext cycle we shouldn't even release them if possible11:40
fungiif they're really abandoned, i wonder if they can be retired11:43
elodillesi don't know, but given it haven't got any patches over multiple cycles now...11:49
elodillesokay, the openstack-manuals patch merged >>> https://review.opendev.org/c/openstack/openstack-manuals/+/98175811:51
elodillesso ~1 hr from now and things will be updated on docs.o.o, right?11:52
fungilikely11:53
fungibased on previous releases11:53
fungipromote-openstack-manuals in the promote pipeline is the job responsible11:54
elodillesand it's running for 21 minutes already12:02
elodilless/21/1412:03
elodilles21 was the remaining minutes12:03
elodillespromote job has finished12:29
frickler"Currently viewing 2026.1 which is the current supported release." yay12:31
fricklerttx: when you're done lunching you could give https://review.opendev.org/c/openstack/releases/+/982898 a second vote?12:33
ttxyes12:43
ttxdone12:44
fricklercool, let's hope the current crawler attacks don't hamper this12:56
elodilles:S12:59
fricklerthere goes hoping, mostly everything failed https://zuul.opendev.org/t/openstack/build/c0cc411c15d04bb4933ca0dcb7917ca712:59
elodilles /o\13:00
elodillesshould we wait or should we recheck immediately? O.o13:00
ttxGNU TLS handshake? sounds like a one-off?13:00
ttxI'd recheck, given the tshirt I'm wearing13:01
ttxdone13:01
fungiyeah, all our gitea servers got overrun with some sort of crawler activity in the past 30 minutes. i'm not hopeful that recheck is going to fare any better13:02
ttxhah13:02
fungithe backends are all slammed and not returning content13:02
ttxI'm feeling lucky!13:02
ttxheadliens: "AI prevented OpenStack from being released on time for first time in 15 years"13:03
elodilleswe were so close to a release without any issues... /o\13:04
elodillesshould we prepare a patch to noop the failing jobs for the patch to be able to merge?13:05
ttxI'm not sure that noop patch would be able to land under current conditions13:08
ttxIt's one of those times I wish our CI jobs used a gitea server that is not part of the public rotation13:09
ttxonly_for_us_gitea.opendev.org13:10
opendevreviewElod Illes proposed openstack/releases master: [CI] Temporarily reduce zuul jobs number  https://review.opendev.org/c/openstack/releases/+/98305513:16
elodillesi mean something like this ^^^13:16
elodilleswhat we are missing now is releases.o.o update only. (though it's bad if the pages cannot be reached when the release is announced.... O.o)13:19
opendevreviewElod Illes proposed openstack/releases master: [CI] Temporarily reduce zuul jobs number  https://review.opendev.org/c/openstack/releases/+/98305513:21
ttxLet's wait for fungi's assessment13:21
elodilles+113:22
fungiyes, i think frickler is trying to work out the offenders' ip addresses so we can try to temporarily firewall them13:23
fungii'm looking at porting the anubis implementation we just added to the mailing list server to our gitea backends13:23
opendevreviewElod Illes proposed openstack/releases master: [CI] Temporarily reduce zuul jobs number  https://review.opendev.org/c/openstack/releases/+/98305513:46
opendevreviewElod Illes proposed openstack/releases master: [CI] Temporarily reduce zuul jobs number  https://review.opendev.org/c/openstack/releases/+/98305513:51
Clark[m]What part of the process relies on gitea? Historically, we've tried really hard to ensure zuul jobs don't need to talk to gitea for things but I know Openstack in particular hasn't always been great about following those rules. In particular zuul speaks to Gerrit and manages its own got repo caches and got repo state which is pushed into the tests nodes so you should never need to talk to gitea in a zuul job unless the point of the14:01
Clark[m]zuul job was to check gitea itself14:01
fricklerClark[m]: the tox jobs, not sure about the details currently, e.g. https://zuul.opendev.org/t/openstack/build/c0cc411c15d04bb4933ca0dcb7917ca714:03
gthiemongeHi folks, it was reported to me that the gunicorn release in upper-constraints in gazpacho has a regression that triggers deadlocks (https://github.com/benoitc/gunicorn/discussions/3509), it's fixed in recent versions. I have prepared a workaround for octavia (for master and 2026.1), we will be able to remove the workaround when the new release is included in requirements on master. but is 14:15
gthiemongethere a way to update the requirements for 2026.1 (post-release of course)?14:15
fricklergthiemonge: this is more of a question for the requirements team, but yes, under the given circumstances I think we could do it. I'm assuming this is causing sporadic testing failures?14:25
zigoI'm done packaging final versions. Zero change with latest RCs this year.14:26
clarkbfrickler: sorry had to step away for a few, but that link is helpful14:28
fungii'm going to bypass testing to merge 982898 since we have confidence that it was passing check jobs earlier14:29
gthiemongefrickler: yeah I opened a launchpad for octavia https://bugs.launchpad.net/octavia/+bug/2146523 it triggers timeouts in our tests, but the impact might be more limited for the end users, like a delay in the creation of a load balancer14:29
clarkbfrickler: and the rest of the release team. It looks like that failing job is fetching git tags then confirming the tags are pushed? Is that something we can consider good enough/done if we run that against gerrit instead of gitea?14:29
clarkbI suspect that we might end up rerunning replication to gitea anyway with the servers there being unhappy so I'm not sure we need to double check the git tag state on gitea?14:29
ttxclarkb: we could14:29
gthiemongefrickler: I forgot that requirements has its own channel, I'll ask them there14:30
fungithe releases were already validated via manual script run after all the tags were done, so should be fine regardless14:30
ttxfor the release missing patch we really don't need testing14:30
clarkbgot it14:31
ttxfungi: are you still working on a workaround, or should we just merge Elod's test-skipping thing temporarily14:31
ttxsince we are 30min away14:31
elodillesi guess fungi can admin-approve the patch to skip testing, maybe in that sense my patch is not needed14:32
elodillesbut both could work as a workaround for now14:32
ttxoh yes, force-approving would be easier14:33
ttxrather than disable, merge, enable14:33
ttxI triple-checked it and it is rather safe14:34
opendevreviewMerged openstack/releases master: Mark 2026.1 Gazpacho as released  https://review.opendev.org/c/openstack/releases/+/98289814:35
opendevreviewElod Illes proposed openstack/releases master: DNM: release-test with required-repo  https://review.opendev.org/c/openstack/releases/+/98307414:36
ttxalright we are a go14:40
elodillesyepp, patch has merged. though releases.o.o is not updated yet14:41
ttxelodilles: you can send the announcement(s) as soon as that publishes14:42
-opendevstatus- NOTICE: The opendev.org site is currently experiencing overwhelming load adversely impacting git operations and repository browsing since 12:20 UTC today, mitigation work is in progress14:42
elodillesttx: ACK, prepared the mails, feel free to rephrase if you want to add something: https://etherpad.opendev.org/p/relmgmt-weekly-emails14:43
fungipublish-tox-docs-releases failed in post14:47
fricklerpublishing seems to have worked, though it still says "2026-04-01 estimated" as initial release date? but at least "maintained"14:47
elodillesfrickler: nope, it's not updated, the next state is where it shows "maintained" :/14:48
fricklerah, wrong column, meh14:49
fungilooking at https://zuul.opendev.org/t/openstack/build/fdfe17a2031f4b6f8f9f1bd085a7254c it's not clear to me what url it was trying to request14:49
ttxlgtm14:50
ttxplease send!14:51
ttx(added a "more contributors" remark)14:51
fungii'm standing by for openstack-announce moderation14:51
ttxstill waiting on the docs refresh run right14:52
fungittx: no, the publish-tox-docs-releases job failed14:53
ttxah14:54
fungi"Task Run tox without tests failed..." with a traceback indicating pip hit an ssl connection error but doesn't say what url it tried to hit14:54
ttxhmm, maybe simpler at this stage to consider it "released" even if the website still says "estimated", since we don't really know when that will be fixed14:55
ttxso my vote is on sending the email so that the 10am CT PR does not go out before we announce14:56
ttxelodilles: ^14:57
elodillesfungi: meanwhile, i've sent the mail to 'announce' ML, feel free to moderate-unblock it when things looks acceptable14:57
fungiannouncement accepted in moderation queue now14:58
ttxand you can send to the discuss list as well14:59
elodilleswill do as soon as I can see the mail in ML and can add the link in the mail14:59
ttx++14:59
elodillesok, so there is the link: https://lists.openstack.org/archives/list/openstack-announce@lists.openstack.org/thread/7WU5RWBRB4UQQAIHMTCKMTIEDRATHVGD/15:00
ttxconfirmed15:00
elodillesand mail sent to openstack-discuss15:02
fungias soon as we get the gitea servers responding again, i'm going to reenqueue the failed releases site change on the assumption it was related to the outage15:02
elodillesthere it is: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/Y5DZJV2DZLZ6PQ2HIRFGGJY2Y6ODELTW/15:03
fungiat least we got the mailing list server responding again, thanks to clarkb's change to slap anubis in front of the service15:06
clarkbfungi: I wish that solutions like that felt like a victory15:07
fungiin a war of attrition, every victory feels like a defeat15:08
sean-k-mooneyelodilles: https://releases.openstack.org/index.html has not been updated yet to relfect the fact now in Maintained status instead of development15:18
sean-k-mooneyfungi: oh is that related to the failed release site change message above?15:19
clarkbyes that is a known issue15:19
sean-k-mooneyack15:19
fungias soon as gitea is responding again (what we think but can't confirm caused the releases site publication job to fail because the tox logs don't say what url pip was trying to fetch) i'll ask zuul to rerun it and that should get it updated15:20
sean-k-mooneyout of interest is there a reason we use https://releases.openstack.org/gazpacho/ instead of https://releases.openstack.org/2026.1/15:20
sean-k-mooneywe adopted the offical release number in favor of the name in most other places15:21
sean-k-mooneyit woudl make finding the release sechdule ectra easier15:21
elodillessean-k-mooney: release tooling still uses the 'name' instead of the 'id'15:26
sean-k-mooneyyep which i personally find harder to work with15:28
sean-k-mooneybut also have not had tiem to even consider what it woudl take to change the release repo ectra to use the number instead of the name15:29
sean-k-mooneyi assume that part fo why it was not doen no one has had time to think about it properly15:29
fungi2c28ee8 is running again in release-post again now15:29
fungipublish-tox-docs-releases got past the point where it failed last time15:34
fungiupdated releases site content was copied successfully into afs, next vos release will happen in ~4 minutes15:35
fricklerhttps://releases.openstack.org/ does look way more correct now15:45
fricklerso ... party time? \o/15:45
elodilles~o~15:54
elodillesfancy :)15:54
ttxLooks like it16:03
ttxcongrats!16:03
ttxOpenStack map has been updated to match release contents too16:03
sean-k-mooneyindeed it does16:12
-opendevstatus- NOTICE: Load on the opendev.org Gitea backends is under control again for now, if any Zuul jobs failed with SSL errors or disconnects reaching the service they can be safely rechecked16:13

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