Tuesday, 2025-12-09

noonedeadpunkjonathanspw: hey! we've started trying to add Alma jobs to our CI and faced one thing with OVS packaging: https://review.opendev.org/c/openstack/openstack-ansible/+/96902108:54
noonedeadpunkit seems, that you have some different packaging variants for v2, and centos-release-nfv-openvswitch package has no tag, and dnf can't find candidate when run on x86-64-v2 hardware?08:55
noonedeadpunkI am not completely sure here, but that what it looks like....08:56
noonedeadpunkmaybe I am missing some trick?08:56
opendevreviewKees Meijs proposed openstack/governance master: Alter public cloud SIG chair  https://review.opendev.org/c/openstack/governance/+/96937109:42
bauzasgouthamr: I'm on a week-long pro-trip in Brno packed with meetings all days, can't attend today's TC meeting ;(10:15
opendevreviewMerged openstack/election master: Update TC liaison for the 2026.2 election  https://review.opendev.org/c/openstack/election/+/96473310:20
clarkbnoonedeadpunk: I don't think alma is rebuilding all packages for -v2, but also centos-release-nfv-openvswitch implies the pacakge comes from centos which doesn't do v2 at all?15:03
fungiyeah, maybe alma isn't actually building ovs at all, so the request would be for them to add it (and any other important openstack dependencies)?15:04
noonedeadpunkyeah, it does not15:04
noonedeadpunkbut I could misunderstand smth as well15:05
* noonedeadpunk not running EL on production since CentOS 715:05
fungithere's a proposed change ( https://review.opendev.org/970042 ) to switch to doing only v3 testing on alma, but that would basically eliminate most of the point of us testing on alma vs rocky15:05
noonedeadpunkright15:07
noonedeadpunkBeing it able to deal with old hardware was a huge point to get it in15:08
noonedeadpunkand make Alma do most of heavy lifting...15:08
clarkbyes my personal preference at this point would be to avoid redundancy among all the EL variants people seemt o care about if we can. It results in overhead for the opendev team through the need to care and feed for more image builds, potentially more mirror content (though not currently for those iirc), more image builds (projects run 3x the number of jobs for example for very15:09
clarkbsimilar coverage). This seemed worthwhile if it gave us a platform that was more flexible on the hardware resources available to us, but if we're giving up on that approach then it would be good to articulate what the goal is now and determine what if anything we should change15:09
clarkber that second more image builds was supposed to be more ci job builds15:10
noonedeadpunkWell, they are not really the same from what I've learned :D15:17
noonedeadpunkand totally not CentOS with Rocky / Alma15:17
clarkbyes, but is the delta sufficiently valuable to triple our workload (the number can actually be higher when you start thinking about different architectures)15:17
noonedeadpunkbut indeed - it makes sense to have one distro running more jobs, while otheres maybe just reference or smth way more lightweight15:18
fungiwe already dropped openeuler, which was somewhat redundant with those15:19
clarkba semi constant battle I'm fighting is removing old test platforms. I basically get no help or assistance on that and the end result is OpenDev just rug pulls on projects because the projects aren't cleaning up after themselves15:19
clarkbbut even then each one of these additional distros represents work that historically I am personally responsible for about 95% of15:19
clarkbwe're currently going through that with bionic and its looking like we're just going to break a buncho f stuff when zuul drops support for python 3.615:20
clarkbso my request on the front end here is that we add things that we believe add intentional value. I was under the impression the intentional value Alma adds is support for older hardware15:21
clarkblooking at it from that angle couldn't you test alma with linux bridge? Then if you're using the same centos package on rocky that you would on alma isn't ovs coverage on rocky sufficient?15:26
clarkbalternatively, show up and take more of this burden off of the opendev team so that we don't have to push back out of fear that we're getting saddled with tech debt no one will care about in 2 years15:35
clarkbbionic cleanup needs to be done right now and is a great place to start15:35
noonedeadpunk> couldn't you test alma with linux bridge - linux bridge was dropped from Neutron for Epoxy15:37
noonedeadpunkso 2024.2 is the last release where linux bridge was available15:37
clarkbthat seems unfortunate if the pacakging for ovs on EL is a random centos thing. But I guess that ship has sailed15:38
noonedeadpunkwell, derrivatives may attempt to establish some SIGs to make it more compatible...15:39
noonedeadpunkBut indeed, I'm not sure we can do anything about it15:39
clarkbhttps://review.opendev.org/c/openstack/openstack-zuul-jobs/+/965402 this is where I hit a road block on bionic cleanup. Monasca is using a bunch of bionic so zuul won't let me delete things without force merging. Monasca is dead but was not cleaned up properly by openstack15:42
clarkboh cool a recheck shows maybe monasca cleanup did finally happen15:43
clarkbnow group based policy is the problem. Which isn't in openstack (anymore?). I think that is a symptom of a similar problem. We basically leave things to die on the vine and opendev has to clean up at some point in the future15:43
fungiyeah, i approved the monasca cleanup change late yesterday15:44
fungiah, no i didn't, it still needs a second review on https://review.opendev.org/97019315:45
clarkbhow topical :) I've approved it15:46
* gouthamr was late on that patch by a week, apologies15:46
clarkbgouthamr: I think my concern is less about the delay in the specific changes and the delay in deciding to evict it and clean it up15:47
clarkbthe longer we delay these actions the more the work falls on those of us working across the community rather than those directly involved in the specific item15:47
clarkbideally they would hang up the closed sign and lock the doors on their way out so that we don't have to15:47
fungiwe did, as a commnuity, give the people who kept saying they were going to work on it too many chances before giving up on hollow promises15:48
fungiit was a learning experience, hopefully15:48
clarkbto put 965402 in perspective these are jobs that were converted from zuulv215:56
clarkbyou can probably draw a direct line from their zuul config today to jjb and jenkins15:56
fungilooks like the x/group-based-policy.* repos are still using legacy jobs15:59
gouthamroh, actively maintained by the looks of this. it shouldn’t be terribly hard to port those jobs - lots of prior art to follow16:21
gouthamrbut, because it’s not in the OpenStack namespace, we’d have to reach out to the maintainers directly16:22
gouthamrtc-members: a gentle reminder that this week’s meeting will happen here in ~38 minutes16:22
gouthamrthe agenda is here: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee16:23
clarkbya at this point I'm not sure openstack is on the hook but I think group based policy was an openstack project when the zuul v2 -> v3 transition happened and could've been better about paying down the debt then16:25
mnasiadkaclarkb: Alma in my opinion should instantiate something like the CentOS NFV SIG and rebuild RHEL FDP (or CentOS NFV SIG) packages with a v2 twist16:28
mnasiadkaThe whole idea behind Alma support in OpenDev was using it for v2 nodes16:29
fungiseems like we're all on the same page. some -1 votes on https://review.opendev.org/970042 would help16:32
mnasiadkafungi: just did that16:36
mnasiadkaI’m just curious how devstack works on Alma 10 v2 - does it rebuild openvswitch?16:37
mnasiadkahttps://zuul.opendev.org/t/openstack/build/f94cc1d8952245fdab282ad071c0b2ea/log/job-output.txt#890216:40
mnasiadkaSeems it’s getting installed from RDO16:40
mnasiadkaAh, that got booted in raxflex, maybe just pure luck16:42
fungiyeah, basically it's failing in some clouds, which prompted the proposed change to eliminate the failures by scoping the nodes to only providers where that job will succeed16:44
fungiseems to me like the job is working quite well. it's identified at least one missing piece for being able to run openstack on v2 hardware with alma16:45
mnasiadkaIn devstack we can force Alma job to compile OVS and OVN from source - which should do the trick16:46
mnasiadkaBut that’s not something the deployment projects should force on people16:46
fungiright16:46
mnasiadkajonathanspw: ^^ that thread might interest you16:47
mnasiadkafungi: But I assume since Alma community has been interested to be supported by OpenStack - now it’s time to throw the ball in their court16:48
fungiexactly. with whatever help and cooperation we can muster too, of course16:48
gouthamr!17:02
gouthamr#startmeeting tc17:02
opendevmeetMeeting started Tue Dec  9 17:02:40 2025 UTC and is due to finish in 60 minutes.  The chair is gouthamr. Information about MeetBot at http://wiki.debian.org/MeetBot.17:02
opendevmeetUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.17:02
opendevmeetThe meeting name has been set to 'tc'17:02
gouthamrWelcome to the weekly meeting of the OpenStack Technical Committee. A reminder that this meeting is held under the OpenInfra Code of Conduct available at https://openinfra.dev/legal/code-of-conduct.17:03
gouthamrToday's meeting agenda can be found at https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee17:03
gouthamr#topic Roll Call17:03
gtemao/17:03
cardoeo/17:03
mnasiadkaO/17:03
frickler\o17:03
spotz[m]o/17:03
noonedeadpunko/17:03
gouthamrnoted absence: b a u z a s, t o n y b17:04
gouthamrperfect, lets get started 17:04
gouthamr#topic Last Week's AIs17:04
gouthamri had an AI regarding the FIPS goal proposal.. 17:06
gouthamri haven't gotten back to it, i was trying to reach out to folks downstream to get some attention on the change as well17:06
gouthamrand the only other AI i see is updating the Technical Vision doc - think we can discuss that some more during this meeting17:07
gouthamrbesides this, i was continuing the cleanup for monasca repos - there was some work to be done in project-config, releases, openstack-manuals etc17:08
gouthamr#link https://review.opendev.org/q/hashtag:%22monasca-retirement%22+status:open 17:09
gouthamr^ those are the patches that are left, if you have review privs, please do help with these17:09
* gouthamr needs to do similar things for "governance-sigs"17:10
gouthamr#link https://review.opendev.org/q/hashtag:%22gazpacho-sigs%22+(status:open%20OR%20status:merged)17:11
gouthamrthis one has one open patch: 17:12
gouthamr#link https://review.opendev.org/c/openstack/governance-website/+/96723917:12
gouthamrthis governance-website is managed by the TC, so could you please look and merge if it makes sense?17:12
gouthamroh wait, two open patches: this one too:17:13
gouthamr#link https://review.opendev.org/c/openstack/governance-website/+/967238/ 17:13
gouthamrthat's all the AIs i was tracking.. anything else from anyone else?17:13
gouthamrlets move to the only non-regular topic we have today:17:16
gouthamr#topic Approaches to making big changes17:16
gouthamr#link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/ZBBNBDASNXQUS74LZRCSISYNANJR7A35/17:16
gouthamrduring the discussion last week, we took a note to update the Technical Vision and specifically incorporate how it is meant to evolve; i thought i could noodle on this a bit, and review this together with clarkb and the rest of the TC - would probably be a WIP until the holidays are past us.. 17:18
gouthamrwe haven't concluded the discussion on this though.. are there any other AIs we can take besides incorporating changes to the Technical Vision?17:19
clarkbseemed like the rough idea was to update the vision document first and let that guide any other potential updates17:20
clarkb(basically to say the vision isn't the only work item but the starting point)17:20
gouthamrtrie17:20
gouthamrtrue*17:20
mnasiadkaI’m sort of afraid to ask that - but do we have a volunteer to start that first patch to the vision document? ;-)17:22
spotz[m]You!:)17:24
clarkbI mentioned last week I'd be happy to help review and possibly even draft things but I dont' think I can drive it17:24
gouthamri assigned myself as the default backup scribe - but, this should be a collective brainstorm on gerrit and elsewhere (mailing list, irc channel, meetings) 17:25
gouthamrso i can "drive" it, but, know that i will be making it _our_ problem to land :) 17:27
mnasiadkaWell, I’m with gouthamr on that - I can help driving it - but would prefer we have an etherpad with initial ideas and we collectively brainstorm on it17:28
spotz[m]That sounds like a good place to strart17:29
gouthamrsounds good mnasiadka 17:29
gouthamranything else regarding $topic?17:29
gouthamr#topic TC Tracker, PTG Follow up17:33
gouthamr#link https://etherpad.opendev.org/p/tc-2026.1-tracker (Technical Committee activity tracker - 2026.1)17:33
gouthamrthe first item on this list coincidentally has an update posted in the past day:17:34
gouthamr#link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/GTPTFUPXXBDMWNQZGZDLM2IIX4FSTT5Y/ 17:34
gouthamrildikov sent that out to the ML, and there's a lot to digest there17:35
gouthamri think we can pre-emptively schedule a follow up for this17:35
gouthamrwe're actually past the deadline jimmymcarthur shared for the user survey - Dec 1st, sigh17:37
gouthamrfor updating the user survey i think17:37
spotz[m]User Sruvey is open all the time, we might be able to still get a change in17:38
gouthamr^ yes, possibly.. i don't know if project teams reached out either17:38
gouthamri'll ask on the thread if we can push this out a couple of weeks past M-2, and have project teams and ourselves think about this17:39
gouthamri guess the risk is the amount of time it takes to assemble the questions, response types etc17:39
gouthamrdoes any other topic on this tracker need to be discussed here today?17:41
gouthamr#topic A check on gate health17:43
gouthamr#link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/N24CYAJMLVJMAJMUE4RA5U7KOL7LABOW/ 17:45
gouthamr^ elodilles shared that unmaintained branches up until yoga will be eol'ed and deleted17:45
fungii also suggested thinking hard about whether to keep zed around17:46
spotz[m]Do we specify it needs to be anywhere?17:47
fungiyoga was a "dress rehearsal" for slurp, so almost-slurp, making zed almost-not-slurp. we don't keep not-slurp branches around past end of maintenance17:47
fungiwhich makes a fairly strong case to drop zed when dropping yoga17:47
spotz[m]So I would lean towards not with you17:47
opendevreviewMerged openstack/governance-website master: Fix link to SIGs  https://review.opendev.org/c/openstack/governance-website/+/96723817:47
opendevreviewMerged openstack/governance-website master: Rework the landing page  https://review.opendev.org/c/openstack/governance-website/+/96723917:47
JayFSo folks understanding of that email is that they planned to retire Yoga as well? I thought it was up to Yoga...17:48
fungioh, maybe i misread, though my takeaway from the discussion in #openstack-release is that it's up through yoga, not up to but excluding yoga17:49
spotz[m]Sounds like we need clarification17:49
fricklerwell in general the question is still open, who volunteers to keep newer branches alive at all. afaict nobody is planning to ask that question yet or formalize the procedure for documenting it. formally when 2024.1 went eom, all older branches should have gotten retired unless someone cares for them17:50
gouthamri am under the impression that elodilles (and others at his company) care, and so the recent transition of stable/2024.1 to unmaintained/2024.1 was done opt-in17:51
gouthamror is that an incorrect assumption?17:52
fricklerwell it is an assumption, it would be good IMO if this would get documented somewhere. also which projects / repos are covered and which are not17:52
gouthamrhmm, i'll leave that question for elodilles to help with when he's around 17:53
gouthamrits a concern yes, because even if we end up deleting these old branches, there's still ETOOMANY branches with uncertain purpose17:54
gouthamrany other gate concern to note? 17:54
gouthamra minor-ish one:17:55
gouthamr#link https://review.opendev.org/c/openstack/devstack-plugin-ceph/+/965145 17:55
gouthamr^ this is a routine update on the "default" version of ceph that's being tested with devstack jobs 17:55
gouthamrceph tentacle released last month, and we tested it with a bunch of openstack repos and pulled the trigger with this.. if you see issues, please let us know17:56
gouthamrus = devstack-qa, openstack storage project teams (cinder, manila, glance) - a whole bunch of people that jointly maintain that testing17:56
noonedeadpunkso there are ubuntu/debian repos already for it?17:57
* noonedeadpunk needs to test it as well17:57
gouthamrwe don't use distro packages to setup ceph with devstack (except for components like nfs-ganesha) 17:57
fungiand worth a quick mention, there's also the discussion in #openstack-tc earlier today about devstack jobs failing on alma nodes if they run in clouds without v3 processors, due to reusing existing rdo/centos packages for ovs17:58
gouthamr^ ++17:58
gouthamrthe discussion headed towards seeking help from almalinux maintainers for this package? 17:59
fungiyes, that was my take17:59
gouthamrack, maybe spotz[m] can help bridge folks in case jonathanspw isn't actively watching.. ty for raising that!17:59
gouthamrwe're at the hour.. 18:00
gouthamr#topic Open Discussion18:00
gouthamrplease add anything else you'd like to note in the minutes today18:00
spotz[m]I can poke, he might be out this week.18:00
gouthamrnote that next week's meeting is at 0800 UTC18:00
gouthamrand will be chaired by mnasiadka 18:00
noonedeadpunk++18:00
gouthamrty spotz[m] 18:00
gouthamrspeaking of being out :) do folks anticipate being available on Dec 23rd and Dec 30th?18:01
mnasiadkaRegarding devstack I raised https://review.opendev.org/c/openstack/devstack/+/970281 that should help with the failing jobs, but won’t help with deployment projects AlmaLinux adoption :-)18:01
gouthamrthat would work? o.O 18:02
mnasiadkaI don’t plan to be available on 23rd and 30th Dec - so I think it’s reasonable to cancel given the rest is already asleep ;-)18:02
gouthamrhaha, okay.. any objections?18:03
noonedeadpunk++18:03
noonedeadpunkI can be around on 23rd, but 30th... eh.18:03
gouthamri'll mail you some eggnog for 23rd18:03
noonedeadpunkbut also I would not be expecting much progress or things to discuss for these...18:04
gouthamr#agreed the TC meetings on Dec 23rd and Dec 30th will be canceled, meetings will resume on Jan 6th 202618:04
mnasiadkagouthamr: It should work, devstack has code for building OVS and OVN from source18:04
mnasiadkaWell the alma job is green already18:04
gouthamrneat mnasiadka, but hopefully the distro also packages so its consumable by end users and deployment projects18:05
gouthamralright lets wrap it up here, 18:05
gouthamrremember next week's meeting is at 0800 UTC, don't upset mnasiadka :P18:05
gouthamr#endmeeting18:05
opendevmeetMeeting ended Tue Dec  9 18:05:46 2025 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)18:05
opendevmeetMinutes:        https://meetings.opendev.org/meetings/tc/2025/tc.2025-12-09-17.02.html18:05
opendevmeetMinutes (text): https://meetings.opendev.org/meetings/tc/2025/tc.2025-12-09-17.02.txt18:05
opendevmeetLog:            https://meetings.opendev.org/meetings/tc/2025/tc.2025-12-09-17.02.log.html18:05
spotz[m]I'm out after this week, I'll be pingable just not guaranteeing an immediate response18:05
gouthamrack, we're in lame-duck time of 202518:06
fungii consider it the "i can actually get things done because nobody's interrupting me" time of the year18:07
spotz[m]hehe18:08
opendevreviewIvan Anfimov proposed openstack/openstack-manuals master: wip  https://review.opendev.org/c/openstack/openstack-manuals/+/97031922:12
opendevreviewIvan Anfimov proposed openstack/openstack-manuals master: Installation Guide - Overview - add informaion supported releases  https://review.opendev.org/c/openstack/openstack-manuals/+/97031922:17
opendevreviewIvan Anfimov proposed openstack/openstack-manuals master: Installation Guide - Overview and Environment - add informaion supported releases  https://review.opendev.org/c/openstack/openstack-manuals/+/97031922:23
opendevreviewIvan Anfimov proposed openstack/openstack-manuals master: install-guide: Remove 2024.1 (Caracal) release  https://review.opendev.org/c/openstack/openstack-manuals/+/97032422:26
opendevreviewIvan Anfimov proposed openstack/openstack-manuals master: install-guide: Remove 2024.1 (Caracal) release  https://review.opendev.org/c/openstack/openstack-manuals/+/97032422:26

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