| opendevreview | Merged openstack/election master: Adding René Ribaud candidacy for Nova 2026.2 PTL https://review.opendev.org/c/openstack/election/+/976349 | 10:34 |
|---|---|---|
| opendevreview | Stephen Finucane proposed openstack/governance master: Onboard additional xstatic packages https://review.opendev.org/c/openstack/governance/+/976513 | 13:00 |
| elodilles | hi TC, in release management tracking page we have a task for this week to "Check with the Technical Committee to make sure Python runtimes have been determined for the next development cycle" o:) could you please add it to your agenda? (like for 2026.1 Gazpacho: https://review.opendev.org/c/openstack/governance/+/957199 ) | 13:17 |
| sean-k-mooney | for 2026.2 i belive we are droping 3.10 and requiring 3.14 supprot | 13:50 |
| sean-k-mooney | now that python is on a fixed 5 year supprot cycle and yearly release | 13:51 |
| sean-k-mooney | we can predicable drop the min and raise the max version in every .2 release | 13:51 |
| sean-k-mooney | we already do not test any distro that default to 3.10 with master | 13:52 |
| sean-k-mooney | that woudl have been ubuntu 22.04 | 13:52 |
| sean-k-mooney | ubuntu 26.04 i belive will ship with 3.14 | 13:53 |
| sean-k-mooney | although we proably wont offilaly suprpot that until 2027.1 but we shoudl start geting it into ci in 2026.2 | 13:53 |
| sean-k-mooney | assumign debian 12 is remvoed for the 2026.2 cycle the lowes python in any of the tested release woudl be 3.12 but that a seperate matter | 13:55 |
| sean-k-mooney | i would keep testing 3.11 just to keep the predicable cadance | 13:56 |
| sean-k-mooney | debiab 12 defaults to it and whiel we might nto test on that for master since trixie (13) is out we have plent of bookworm(12) testing on stable branches for the forseable future | 13:58 |
| sean-k-mooney | so it wont save use anything ci wise not to run tox jobs on 3.11 | 13:59 |
| opendevreview | Ivan Anfimov proposed openstack/openstack-manuals master: Add bug tracker link for Skyline https://review.opendev.org/c/openstack/openstack-manuals/+/976630 | 14:26 |
| opendevreview | Ivan Anfimov proposed openstack/openstack-manuals master: Add bug tracker link for Skyline https://review.opendev.org/c/openstack/openstack-manuals/+/976630 | 14:31 |
| opendevreview | Ivan Anfimov proposed openstack/openstack-manuals master: Community support - update until 2025.2 https://review.opendev.org/c/openstack/openstack-manuals/+/976630 | 14:32 |
| opendevreview | Ivan Anfimov proposed openstack/openstack-manuals master: Add bug tracker link for Skyline https://review.opendev.org/c/openstack/openstack-manuals/+/976633 | 14:33 |
| opendevreview | Ivan Anfimov proposed openstack/openstack-manuals master: Add bug tracker link for Skyline https://review.opendev.org/c/openstack/openstack-manuals/+/976633 | 14:38 |
| opendevreview | Ivan Anfimov proposed openstack/openstack-manuals master: Add bug tracker links for Skyline (console and apiserver) https://review.opendev.org/c/openstack/openstack-manuals/+/976633 | 14:39 |
| gouthamr | elodilles: ack, ty for the reminder! | 14:47 |
| gouthamr | > although we proably wont offilaly suprpot that until 2027.1 but we shoudl start geting it into ci in 2026.2 | 14:48 |
| gouthamr | +1 yeah, that'd be the goal sean-k-mooney | 14:48 |
| elodilles | thanks too o/ | 14:53 |
| *** vhari_ is now known as vhari | 15:00 | |
| opendevreview | Ivan Anfimov proposed openstack/openstack-manuals master: Community support - update until 2025.2 https://review.opendev.org/c/openstack/openstack-manuals/+/976630 | 15:12 |
| opendevreview | Cyril Roelandt proposed openstack/election master: Add Cyril Roelandt for Glance 2026.2 PTL https://review.opendev.org/c/openstack/election/+/976639 | 15:18 |
| opendevreview | Ivan Anfimov proposed openstack/openstack-manuals master: wip https://review.opendev.org/c/openstack/openstack-manuals/+/976646 | 15:43 |
| opendevreview | Ivan Anfimov proposed openstack/openstack-manuals master: wip https://review.opendev.org/c/openstack/openstack-manuals/+/976646 | 15:44 |
| opendevreview | Ivan Anfimov proposed openstack/openstack-manuals master: python-ironic-inspector-client retirement -add redirects https://review.opendev.org/c/openstack/openstack-manuals/+/976646 | 15:45 |
| opendevreview | Ivan Anfimov proposed openstack/openstack-manuals master: python-ironic-inspector-client retirement - add redirects https://review.opendev.org/c/openstack/openstack-manuals/+/976646 | 15:45 |
| opendevreview | Ivan Anfimov proposed openstack/openstack-manuals master: Community support - update until 2025.2 https://review.opendev.org/c/openstack/openstack-manuals/+/976630 | 15:46 |
| opendevreview | Ivan Anfimov proposed openstack/openstack-manuals master: Community support - update until 2025.2 https://review.opendev.org/c/openstack/openstack-manuals/+/976630 | 15:46 |
| opendevreview | Ivan Anfimov proposed openstack/openstack-manuals master: Add bug tracker links for Skyline (console and apiserver) https://review.opendev.org/c/openstack/openstack-manuals/+/976633 | 15:46 |
| opendevreview | Ivan Anfimov proposed openstack/openstack-manuals master: Community support - update until 2025.2 https://review.opendev.org/c/openstack/openstack-manuals/+/976630 | 15:55 |
| gouthamr | hmm, Ubuntu 26.04 / resolute raccoon's release date is April 23, 2026.. that's a few weeks after we begin working on H.. so it'd be a goal at best to update any Noble Numbat test jobs to that in the H release.. but, the default python version'd'be 3.14 .. something we've only needed non-voting testing in 'G'. i anticipate tempest test challenges.. it'd be nice to get started asap | 16:00 |
| clarkb | testing with locally built python is doable. The resulting python jobs aren't that much slower despite lacking extra optmizations and the several minutes of python compile time | 16:01 |
| fungi | gouthamr: it's a bit of a grey area, in the past we've sometimes made it a priority to get new ubuntu lts images available during their release freeze if there's interest, so in theory they could be ready around the gazpacho release | 16:03 |
| fungi | though if you count the start of the hibiscus cycle as being at gazpacho rc1, probably not going to be able to get them quite that early | 16:03 |
| gouthamr | ah ty clarkb fungi... true, RC1 is around the corner | 16:05 |
| fungi | ultimately it's up to the tc to decide whether hibiscus or i* has resolute as an officially tested runtime, i'm happy to try to work with you to get it available sooner if it's important | 16:06 |
| gouthamr | ++ i'll push up a draft runtimes patch and have the TC and openstack-qa folks opine on it | 16:06 |
| fungi | since 2026.2/hibiscus is not-slurp, i expect it's not super urgent to have it on the newest ubuntu lts while 2027.1/i* being slurp would be more important from an upgrade perspective | 16:07 |
| gouthamr | +1 | 16:09 |
| fungi | or stated another way, openstack 2027.1/i* is going to need to continue to have ubuntu 24.04/noble testing for slurp upgrade purposes, so getting ubuntu 26.04/resolute officially tested for openstack 2026.2/hibiscus doesn't allow us to drop the old testing platform any sooner | 16:11 |
| gmaan | it is releasing after H development started, we usually do not include after release distro vesion right? | 16:17 |
| gmaan | timing was always same for ubuntu and openstack releases, its a few weeks gap and we usually add it in the next openstack cycle | 16:18 |
| opendevreview | Ivan Anfimov proposed openstack/openstack-manuals master: Add bug tracker links for Skyline (console and apiserver) https://review.opendev.org/c/openstack/openstack-manuals/+/976633 | 16:20 |
| fungi | "the policy for officially tested runtimes is based on the LTS or stable release of the Linux Distributions at the start of the development cycle" | 16:20 |
| fungi | it doesn't say whether that's released or just available for use | 16:21 |
| gmaan | I think we are considering only released distro in our runtime | 16:22 |
| fungi | i.e. if we have ubuntu-resolute test nodes available before ubuntu officially releases it, does that count? | 16:22 |
| fungi | but similarly, it doesn't clearly define "the start of the development cycle" either | 16:22 |
| gmaan | We have not counted it in past, same situation happened many times when it was just a few weeks gaps between cycle start and distro release | 16:23 |
| gmaan | if we do that then we should do it for other distro where we clearly rejected it like CS or debain etc | 16:23 |
| fungi | sometimes we consider the final release day as the start of the next cycle, other times we consider the end of rc1 week when stable/* branches are created and master is open as the start of the next cycle | 16:23 |
| gmaan | *centos Stream | 16:23 |
| gmaan | I am checking this page and considering APril2 as start date https://releases.openstack.org/hibiscus/schedule.html | 16:24 |
| sean-k-mooney | ya for me 26.04 testing is nice to have next cycle btu shoudl not be required | 16:24 |
| gmaan | and Ubuntu 26.04 release is almost near to Milestone-1 date | 16:24 |
| sean-k-mooney | but if its in nodepool we can start adding devstack canary jobs for it | 16:24 |
| fungi | but yes, for me what matters most is not how soon can we add new testing but rather how soon can we drop old testing, and that doesn't change regardless of what we do for 2026.2 because of slurp | 16:25 |
| gmaan | I do not think it is good idea to target near Milestone-1 and finish during end of rlease | 16:25 |
| fungi | so i think it's mostly academic whether 2026.2 is officially tested on ubuntu-resolute images or only encoraged | 16:26 |
| sean-k-mooney | for py 3.14 testing i would just use uvx tox --python 3.14 or install it as an addtional python im sure its packaged on debian 13 or ubuntu 24.04 | 16:26 |
| gmaan | agree | 16:26 |
| gmaan | 3.14 testing should not be issue | 16:26 |
| sean-k-mooney | s/uvx tox --python 3.14/uvx --python 3.14 tox/ | 16:27 |
| fungi | i disagree, if python 3.14 testing is added because it's the default python on ubuntu 26.04 lts then we should try to test it on ubuntu-resolute nodes as soon as we have them available | 16:27 |
| sean-k-mooney | that not why we woudl be adding it | 16:27 |
| gmaan | yeah | 16:27 |
| sean-k-mooney | we woudl be addign it becuase its the most recent python release aviabel at the sart of the cycle | 16:28 |
| sean-k-mooney | new pythons come out once ayear now | 16:28 |
| gmaan | if anyone want to test they can do as non voting but if we are not including ubuntu 26.04 then py3.14 should not be mandatory | 16:28 |
| sean-k-mooney | and are supproted for 5 years in october | 16:28 |
| sean-k-mooney | but the fact it will align to 26.04 is also nice beasue we know we will have to support that eventually | 16:29 |
| gmaan | and usually we start testing the next python version after a cycle we test that as non voting and we did not do that for python 3.14 ywet | 16:29 |
| fungi | i don't see it spelled out clearly in the existing policy documentation whether we add optional newer python version testing to test newer python or because it's the default python for an upcoming distro we'll be testing | 16:29 |
| sean-k-mooney | well https://github.com/openstack/governance/blob/master/reference/runtimes/2026.1.rst we encurged testing it for 2026.1 | 16:29 |
| sean-k-mooney | but we didnt have tempest jobs | 16:30 |
| fungi | but we knew it would be the default python for ubuntu 26.04 lts | 16:30 |
| gmaan | yeah we did not add testing for that, it is just in runtime | 16:30 |
| gmaan | my concern is if we add 26.04 lts in next cycle which is released around M-1 is not safe and risk to achieve the goal. It also break our past practice/policy where we denied any unlreased distro to be part of official testing runtime | 16:32 |
| fungi | so if we prioritize adding it (still optional) for openstack 2026.2/hibiscus, will that be because it's the latest python version or because people may want to install on ubuntu 26.04 lts where it's the default python version? | 16:32 |
| fungi | we ran into this problem with python 3.13 testing in openstack 2026.1/gazpacho, where switcing jobs from on-the-fly compiled to running with the default python on debian-trixie images (ostensibly official testing per the pti) lagged considerably and disrupted development work somewhat because it wasn't prioritized sooner | 16:33 |
| sean-k-mooney | proably both | 16:34 |
| sean-k-mooney | ubuntu 26.04 will have 2026.1 and 2026.2 packaged | 16:34 |
| sean-k-mooney | so at least canonical customer will want to deploy it to production | 16:34 |
| sean-k-mooney | im using debian 13 for most of my devstack envs parlty to test with the laste python we supprot but ill proably start usign some 26.04 vms for dev along withthe other ones at some point during the next 3-6 months | 16:36 |
| fungi | basically, i think that switching from pyenv on an old platform to default on a new platform needs to happen at the earliest opportunity, both because it shouldn't disrupt official testing (due to being optional in that cycle) and because it shaves a lot of time off every single job | 16:36 |
| * gouthamr is in a meeting, will catch up on scrollback in a bit | 16:36 | |
| sean-k-mooney | fungi: right but im effectivly suggesting we add 26.04 to the advance/unstable testing sectoin | 16:37 |
| sean-k-mooney | and we can enabel ci to use it when its aviable for tox and or devstack based jobs | 16:38 |
| gmaan | agree with sean-k-mooney. 'advance/unstable testing sectoin' is mainly added for the advance testing only | 16:38 |
| fungi | keep in mind that pyenv takes several minutes to recompile cpython from source at the start of the build, and as a compromise doesn't build optimized binaries (which take many times longer due to profiling and multiple cc passes), so jobs using it also run slower from lack of optimization | 16:38 |
| sean-k-mooney | taht atully why i rasied uvx as an option for tox. i kint of wnat to expernet with uv and devstack evnetually but not right now | 16:39 |
| fungi | what i'm trying to say is, as soon as we have ubuntu-resolute nodes available then any optional py314 jobs should move to that instead of pyenv on an older platform. if we have ubuntu-resolute nodes available before optional py314 jobs are created, then we should just have them run on ubuntu-resolute from the outset | 16:40 |
| sean-k-mooney | +1 | 16:40 |
| fungi | and we shouldn't artifically delay migrating optional py314 jobs from pyenv on an older platform to available ubuntu-resolute nodes purely on the grounds that ubuntu 26.04 lts is not officially in the pti for that cycle | 16:42 |
| sean-k-mooney | yep i dont think that was ever suggested | 16:42 |
| sean-k-mooney | at least i didnt want to impy that | 16:42 |
| fungi | better to make that change while the jobs are still optional, than have the situation from the current cycle where we dragged our heels moving py313 jobs onto debian-trixie even though it was officially in the pti already | 16:43 |
| sean-k-mooney | not to dig in too much but what was the actual hold up for that | 16:44 |
| sean-k-mooney | i tought it was orgianlly the mirror space | 16:44 |
| sean-k-mooney | at least that was one of the delays on the devstack side | 16:45 |
| sean-k-mooney | is that why you rasied the point about when can we remove older release adn the slurp cadence | 16:46 |
| fungi | in part yes. there was pushback for dropping bionic mirroring because lingering pre-slurp unmaintained branches relied on it | 16:47 |
| fungi | but still, devstack had trixie support proposed as of july that didn't merge until november, there was time for people to prioritize adding package mirrors for it sooner | 16:51 |
| fungi | we had the debian-trixie nodes available for months before support landed in devstack, in theory package mirrors shouldn't have been a blocker | 16:53 |
| sean-k-mooney | for what its worth i had been using that poc patch since teh summer | 17:01 |
| sean-k-mooney | but ya once we have an image we can use ill likely start on the unbuntu 26.04 support in devstack work | 17:01 |
| sean-k-mooney | i also thing we coudl intially start without mirrors for what its worth | 17:02 |
| sean-k-mooney | or without our own mirrors just to get eh generic supprot landed early | 17:02 |
| gouthamr | thanks for sharing your thoughts on this! | 19:13 |
| gouthamr | tc-members: gentle prod on https://review.opendev.org/c/openstack/governance/+/976513 ; i suspect these repos need to be added to the release team's agenda on short notice.. it's a little unorthodox for us to add stuff this late, but, the situation with setuptools warrants it | 19:15 |
| gouthamr | that said, there are no substantial changes into these packages via git.. (nor do i know of the horizon team considering any) - the release team addition is paperwork and accounting | 19:15 |
| opendevreview | Merged openstack/governance master: Onboard additional xstatic packages https://review.opendev.org/c/openstack/governance/+/976513 | 19:53 |
| opendevreview | Merged openstack/governance master: Add a script to abandon changes on retired reposoitories https://review.opendev.org/c/openstack/governance/+/975594 | 20:05 |
| opendevreview | Goutham Pacha Ravi proposed openstack/governance master: Define testing runtime for 2026.2 release https://review.opendev.org/c/openstack/governance/+/976691 | 22:16 |
| clarkb | GitHub says they will allow us to disable pull requests: https://github.blog/open-source/maintainers/welcome-to-the-eternal-september-of-open-source-heres-what-we-plan-to-do-for-maintainers/ one less thing for the bot to do potentially | 22:32 |
| gouthamr | W00t! | 22:54 |
| gouthamr | hacktoberfest will be different this year | 22:55 |
| fungi | yay! finally! after over a decade of us asking | 23:36 |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!