18:00:47 <gouthamr> #startmeeting tc
18:00:47 <opendevmeet> Meeting started Tue Oct 29 18:00:47 2024 UTC and is due to finish in 60 minutes.  The chair is gouthamr. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:47 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:00:47 <opendevmeet> The meeting name has been set to 'tc'
18:01:01 <gouthamr> Welcome 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
18:01:05 <gouthamr> Today's meeting agenda can be found at https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee
18:01:09 <gouthamr> #topic Roll Call
18:01:10 <noonedeadpunk> o/
18:01:11 <gmann> o/
18:01:13 <bauzas> \o
18:01:25 <gtema> O/
18:01:30 <frickler> \o
18:02:03 <slaweq> o/
18:02:10 <spotz[m]> o/
18:02:49 <gouthamr> courtesy-ping: cardoe
18:04:51 <gouthamr> let's get started..
18:05:05 <gouthamr> #topic Past Weeks' AIs
18:05:06 <cardoe> sorry I'm on.
18:05:14 <gouthamr> hey there, cardoe
18:05:39 <gouthamr> Debug quota test failures in the requirements patch and continue work on the grenade-related issues (gmann):
18:06:04 <gouthamr> gmann: seemed like separate issues that you brought up here in the past weeks
18:06:08 <gmann> greande job is fixed now and some project failing it also have fix up
18:06:31 <gmann> quota test failures is in sdk job not in requirement.
18:06:44 <gmann> I still did not get time to debug those, I will look into that this week
18:07:01 <gouthamr> #link https://review.opendev.org/q/topic:%22grenade-venv%22 (Grenade job changes)
18:07:57 <gouthamr> gmann: ty, any gerrit links we should track for that second item?
18:08:07 <gmann> yeah
18:08:11 <gmann> #link https://review.opendev.org/c/openstack/python-openstackclient/+/931858
18:08:13 <gmann> this one ^^
18:08:39 <gouthamr> thank you! we'll follow up with this next week
18:08:53 <gouthamr> next up, Lead the tracker related to translations (bauzas)
18:09:04 <bauzas> hmmm, sure
18:09:06 <gouthamr> ^ this was sorta actioned during the PTG week
18:09:22 <gouthamr> and probably a work item to track through the release/
18:09:25 <bauzas> nothing really important to discuss as an AI
18:09:44 <gouthamr> bauzas: ack; worth tracking with the TC tracker?
18:09:45 <gouthamr> #link https://etherpad.opendev.org/p/tc-2025.1-tracker (Technical Committee activity tracker - 2025.1)
18:09:53 <bauzas> we started to discuss with ian and seangsoo about how to work on the AI translation
18:10:35 <bauzas> https://etherpad.opendev.org/p/oct2024-ptg-i18n#L47
18:10:40 <frickler> maybe worth noting that translation updates from zanata are completely broken now
18:11:01 <bauzas> there was just a concern about legal issues
18:11:12 <frickler> since reqs dropped py3.8 pins and thus installing projects on bionic no longer works
18:12:02 <fungi> and the (abandoned) zanata cli tools need a jdk old enough that it was last available on bionic
18:12:08 <bauzas> we said that maybe just a documentation top paragrath would say "it's an automatically translated"
18:12:36 <clarkb> I was thinking about that and maybe a container image for the zanata client would be an "easy" thing to solve that problem
18:12:44 <clarkb> then you can have java 8 + zanata client wherever you are
18:12:52 <cardoe> that would make sense clarkb
18:13:25 <fungi> though also sounds like a good bit of work when people could be spending time finishing the weblate transition instead
18:13:49 <clarkb> ya thats the other thing to keep in mind I guess. zanata is still very dead end and we should move away from it
18:13:52 <gouthamr> is this the job? https://zuul.opendev.org/t/openstack/builds?job_name=propose-translation-update
18:14:06 <bauzas> honestly I don't know
18:14:11 <frickler> gouthamr: yes
18:14:31 <bauzas> that's a different question
18:14:52 <bauzas> (I just discussed with ian for the automatically translations for the service docs)
18:16:04 <gouthamr> it is a different question
18:16:17 <gouthamr> bauzas: can we deal with the legal question as a topic?
18:16:55 <bauzas> gouthamr: maybe we should ask the Foundation for that
18:16:56 <gouthamr> regarding the job failure, I think the i18n team needs some infra help - they mentioned that they lacked the zuul expertise to maintain these translation jobs.. if zanata doesn't work on anything other than bionic, i think we've hit the first schism
18:18:24 <fungi> in that case, it would be good to know what questions they have about automation
18:18:33 <gouthamr> "For the issue, I18n SIG is asking help to upgrade propose-translation-update job with ubuntu-bionic to newer version of Python"
18:18:55 <gouthamr> L44 of the etherpad bauzas linked
18:19:16 <frickler> so that would be the container solution that clarkb suggested. but I don't think the infra team has much time to help with that
18:19:24 <fungi> ah, yes, the counter-suggestion is to finish up the weblate migration instead
18:19:37 <bauzas> I wasn't there when they discussed this
18:19:37 <gouthamr> ^ my hope as well
18:19:38 <clarkb> and I don't think it needs much zuul expertise to switch the jobs
18:19:46 <clarkb> its copy paste and change out the tools inside the jobs
18:20:06 <fungi> since zanata is exactly the reason the jobs are breaking when moving to newer python/platform
18:20:13 <clarkb> I tried to stress this in the calls we had before that it really should be straightforward someone just needs to decide they are doing it and spend a little time understanding the jobs enough to replace the tools in copies of them
18:20:35 <gouthamr> i think, we can live without translations (for hopefully a short time) until the weblate infra is fixed up, and there are new jobs to propose translation updates from weblate
18:20:36 <gmann> yeah, this is not just job migration
18:21:05 <fungi> don't necessarily even need new jobs, just replace the zanata cli commands with weblate cli commands
18:22:16 <gmann> weblate is also licensed, hope we are all good on their subscription payment this year also? Last time it was paid by the foundation but not sure if that was for more than a year and need to renew or not ?
18:22:40 <fungi> i think it was set up to renew anually
18:22:51 <gmann> ok, thanks
18:23:04 <fungi> have the i18n folks indicated that weblate stopped working?
18:23:30 <bauzas> I don't know
18:23:33 <gouthamr> they discussed "Weblate with openinfraid authentication issue" - which they note is now resolved
18:23:36 <gmann> no, I have not heard that but just want to check if that part is ok or not
18:24:45 <gouthamr> don't want to spend the whole hour discussing this; i've alerted ianychoi and seongsoo to peek into this channel.. its possible they could start a ML discussion as well to follow up..
18:25:02 <gmann> ML is better due to TZ
18:25:10 <gouthamr> +1
18:25:15 <bauzas> +1
18:25:21 <gmann> last time we synced on all these issue in ML and brian from TC leading the discussion
18:25:29 <gmann> that was productive and fast
18:25:51 <fungi> i follow the i18n ml as well as the i18n topic on openstack-discuss and haven't seen these issues brought up
18:26:21 <gouthamr> ++ bauzas volunteered or was voluntold to play the TC liaison role here, i cannot tell, but, its very much appreciated
18:26:32 <gmann> bauzas: ++ thanks
18:26:45 <gouthamr> lets move on to the next AI:
18:26:45 <gouthamr> Leaderless projects, next steps
18:27:07 <gouthamr> we have a couple of pending changes on the governance repository that still need eyes
18:27:37 <gouthamr> #link https://review.opendev.org/c/openstack/governance/+/927962 (Adding Axel Vanzaghi as PTL for Mistral)
18:27:57 <gouthamr> #link https://review.opendev.org/c/openstack/governance/+/933018 (Add watcher DPL for Epoxy)
18:28:17 <gouthamr> thanks for adding your RC votes and comments, but if you haven't done so yet, please do
18:28:43 <gouthamr> i'd like to land both these changes this week since they have spent sufficient time on review
18:29:13 <gmann> ++, done
18:29:25 <gouthamr> these do complete our "leaderless" tracking post the 2025.1 election
18:29:33 <gouthamr> #link https://etherpad.opendev.org/p/2025.1-leaderless (2025.1 Leaderless projects)
18:29:34 <slaweq> I just added my RC +1
18:30:22 <gouthamr> thank you
18:30:37 <gouthamr> alright that's all the AIs I was tracking
18:30:55 <gouthamr> did any of you have any other items that you were working on that were actions from past meetings?
18:30:59 <bauzas> I think we can merge those, we have quorum right?
18:31:13 <bauzas> (when looking at r-c label)
18:31:25 <bauzas> (r-*v*)
18:31:26 <gouthamr> bauzas: yes, but we wait until 7 days after the last change..
18:31:40 <bauzas> ack thanks for explaining
18:32:08 <gouthamr> bauzas: as a minimum :) i've learned to wait longer in case something needs more eyes, as JayF gmann and others used to..
18:32:51 <gouthamr> we discussed dropping past TC chairs from the tech-committee-chair group (sad panda emoji)
18:33:00 <gmann> I think bauzas should know about our magic script which tell us about minimum (just minimum) requirements to merge the changes.
18:33:13 <gouthamr> soooo - the side effect is that i can tag the tc in changes taht need attention :)
18:33:24 * gouthamr please don't ignore these mass reviewer tags
18:33:35 <bauzas> gmann: I did read the TC docs but I forgot about when merging :)
18:33:37 <gmann> bauzas: https://github.com/openstack/governance/blob/master/tools/check_review_status.py
18:33:41 <gmann> cool
18:34:02 <gmann> ++ on tech-committee-chair cleanup
18:34:10 <gouthamr> sounds like no further AIs to catch up on..
18:34:11 <gouthamr> lets move on
18:34:12 <bauzas> gmann: thanks for helping ;)
18:34:15 <gouthamr> #topic Goal Progress: Migration to noble
18:34:47 <gmann> not much update but I started working on this, created the plan and sent on ML
18:34:51 <gmann> #link https://etherpad.opendev.org/p/migrate-to-noble
18:35:06 <gouthamr> i have a minor-ish concern regarding these changes
18:35:15 <gmann> #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/message/JOMDY26TCW7OX3NXRGOYQCIDXNNJ4E25/
18:35:30 <gmann> sure
18:35:34 <gouthamr> i really don't like keeping a test job variant on Jammy
18:35:40 <gouthamr> gmann explained the reasoning here:
18:35:43 <gouthamr> #link #link https://review.opendev.org/c/openstack/manila-tempest-plugin/+/932956
18:36:16 <gouthamr> but i believe that we'd like to keep some testing on Jammy for trunk/main branches because it would allow python3.9 integration testing to continue
18:36:22 <gmann> just to note, this is requirement of this section in testing runtime
18:36:24 <gmann> #link https://governance.openstack.org/tc/reference/runtimes/2025.1.html#additional-testing-for-a-smooth-upgrade
18:37:10 <bauzas> yeah we need to continue to support Jammy until next release at least
18:37:22 <gmann> yeah, at least till next release
18:37:24 <bauzas> because $slurp
18:37:37 <gouthamr> until?
18:37:42 <gmann> what I need to update is to run jammy job with python 3.9
18:38:02 <bauzas> until when we change the PTI values for F, G or some other cycle :)
18:38:04 <spotz[m]> So upgrade 3.8 to 3.9 but stay on Jammy?
18:38:08 <gmann> gouthamr: in next cycle, we can drop. this will help to have slurp 2024.1 -> 2025.1 migration
18:38:42 <gmann> gouthamr: I updated in nova change where we can run jammy on py3.9 so that we do not need to keep up the things for py3.8
18:38:44 <gouthamr> gmann: wouldn't this mean the py39/jammy job will continue to run on stable/2025.1 until we sunset that branch?
18:38:48 <clarkb> I wrote down the migration path for centos 9 to centos 10 in an mailing list response and I think ti is similar for jammy to noble
18:39:10 <gmann> gouthamr: yes, even in stable/2025.1 also but in 2025.2, we do not need to run, we will keep only noble jobs
18:39:22 <gmann> clarkb: yes
18:39:33 <gmann> we did same in past also when we moved from bionic to jammy
18:39:47 <bauzas> https://devguide.python.org/versions/ says that 3.9 will be EOL next year
18:39:58 <gmann> #link https://governance.openstack.org/tc/reference/runtimes/2023.1.html#additional-testing-for-smooth-upgrade
18:40:19 <gmann> bauzas: yeah, hopefully we will be good to move to py3.10 as min by then
18:40:47 <noonedeadpunk> isn't jammy 3,10 by default?
18:40:53 <bauzas> I just wanted to say we have ~ 1 cycle (ie. G as the last one) for 3.9
18:41:09 <noonedeadpunk> and it's el9 that's shipped with 3.9 iirc
18:41:11 <bauzas> but if we can drop it for F, that's cool
18:41:20 <gouthamr> #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/FJO4GPM25C4UKHDBOQBEIG7YVWTOWL4H/#FJO4GPM25C4UKHDBOQBEIG7YVWTOWL4H (suggested upgrade path for centos/rhel/rocky/alma by clarkb)
18:41:59 <noonedeadpunk> have someone looked into devstack for el10 already?
18:42:02 <gmann> noonedeadpunk: ah right. it is python 3.10. I was wrong on py3.8 things.
18:42:12 <noonedeadpunk> as I can imagine modular libvirt could be slightly different
18:42:23 <gmann> so we can run jappmy on either py3.10 or onb py3.9 which is our min python version
18:42:29 <gmann> jammy
18:42:53 <frickler> one can also update and use newer python on el9. kolla does this due to ansible reqs
18:43:11 <frickler> so not 100% necessary to wait for el10
18:43:36 <noonedeadpunk> well, there's difference of ansible host and rest
18:43:52 <bauzas> I don't know what the el9 plan post 3.9 EOL
18:44:01 <noonedeadpunk> not sure what specifically kolla does, in osa we use 3.11 python for EL only as "deploy" host version
18:44:29 <frickler> I think we use it for services, too, but I need to doublecheck
18:44:38 <noonedeadpunk> the problem with non-default version, is that there're no python bindings for things, like ceph, libvirt, selinux, etc
18:44:53 <noonedeadpunk> so kinda makes things tricky
18:45:03 <gouthamr> i think my initial question was well answered through this discussion, thanks everyone.. i do wish we highlighted our upgrade path somewhere
18:45:05 <frickler> hmm, then maybe I misunderstood
18:45:17 <gmann> gouthamr: is your concern about Jammy job resolved? This is implementation of what we have defined in 2025.1 testing runtime.
18:45:26 <clarkb> gouthamr: yes I called that out with the relese team after sending that email I think
18:45:52 <gouthamr> would a "Reasoning" section under the tested run times help?
18:45:55 <clarkb> I also updated a diagram explaining slurp in release docs. If even we are confused about it then we're not documenting it properly and I suspect part of the issue is that text is not sufficient for communicating these ideas clearly
18:45:59 <clarkb> need more illustrations
18:46:29 <gmann> gouthamr: also I tried to described it in this section https://governance.openstack.org/tc/reference/project-testing-interface.html#upgrade-testing
18:46:31 <gouthamr> #link https://releases.openstack.org/#releases-with-skip-level-upgrade-release-process-slurp (Release upgrade illustration)
18:46:31 <gmann> #link https://governance.openstack.org/tc/reference/project-testing-interface.html#upgrade-testing
18:46:41 <gmann> if anything missing there, feel free to update
18:47:19 <gmann> this subsection
18:47:21 <gmann> #link https://governance.openstack.org/tc/reference/project-testing-interface.html#extending-support-and-testing-for-release-with-the-newer-disto-version
18:47:21 <gouthamr> ++ thank you; i'll read it
18:47:51 <gmann> that is where we started building those doc when SLURP things came and when we bump the distro version
18:48:17 <gmann> for smooth upgrade, testing the old distro one job for a one more cycle is migration path we can provide
18:48:31 <clarkb> as a side note the container based deployments actually care about this a lot less
18:48:43 <gouthamr> containers need OS too :D
18:48:44 <clarkb> because you can update 2024.1 to 2025.1 containers running the latest python version for each
18:48:49 <clarkb> gouthamr: yes but you don't need overlap
18:49:03 <clarkb> because you can replace 2024.1 python3.9 with 2025.1 python3.12 in the same step
18:49:16 <gouthamr> yes
18:49:25 <noonedeadpunk> clarkb: you do if you don't use containers
18:49:34 <clarkb> noonedeadpunk: correct I'm explaining the difference
18:49:41 <noonedeadpunk> or we're saying that openstack outside of docker images is unsupported?
18:49:45 <clarkb> you need overlap if not using containers. If using containers then you don't
18:49:54 <clarkb> no one is saying that I'm trying to respond to the discussion about osa and kolla above
18:50:00 <noonedeadpunk> ++
18:50:01 <clarkb> they are actually orthogonal since they don't have the problem
18:50:44 <gouthamr> alright; anything else on $topic? we've 10 mins
18:50:58 <gouthamr> there're only regularly scheduled topics next
18:51:27 <noonedeadpunk> I'd say overlap is potentially always good to have
18:51:44 <noonedeadpunk> just to give a breather for ones who are not risky changing multiple things at the same time
18:51:47 <gmann> ++
18:52:07 <gouthamr> these next topics (Gate Health and TC Tracker) will probably be expanded if we spend some time next week..
18:52:09 <gmann> that was one of the key reason of our testing runtime and take care of such overlap when needed
18:52:19 <gouthamr> any objections moving to Open Discussion for these ~8 mins?
18:52:27 <gmann> one thing for gate
18:52:34 <gouthamr> #topic Gate Health
18:52:37 <gouthamr> go for it gmann
18:52:41 <gmann> Tempest broke for py3.8 drop and it is fixed now
18:52:43 <gmann> #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/FOWV4UQZTH4DPDA67QDEROAESYU5Z3LE/
18:52:56 <gouthamr> ah \o/ thanks; you're encouraging pins for unmaintained branches
18:53:00 <gmann> but this fix where tempest master is used for testing means stable/2023.1 to master
18:53:36 <gmann> yes, for unmaintained branches, maintainers need to pin Tempest. which should have been done as soon branches move to unmaintained status
18:53:49 <gmann> like we did for EM branch status change in past
18:53:50 <cardoe> I'm ++ on that.
18:54:13 <gouthamr> ^ ah good place for a reminder that release folks will transition stable/2023.1 to unmaintained/2023.1 in the next couple of weeks likely
18:54:20 <gouthamr> (their target was end of Oct)
18:54:37 <frickler> yes, elod is on pto this week, will happen next week
18:54:46 <gmann> ++
18:54:47 <gmann> that is all on gate thing
18:54:54 <gouthamr> thanks gmann
18:54:58 <gouthamr> #topic Open Discussion
18:55:02 <frickler> still need to decide how to handle existing unmaintained branches
18:55:03 <bauzas> thanks gmann
18:55:21 <gmann> frickler: I will say if no one fix then it is good signal for EOL
18:55:24 <frickler> IMHO they are in a bad state and should be eoled mostly
18:55:25 <gouthamr> #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/message/UDQAC7SR5JAQJE5WBAG54A2MTBVBTJ44/ ([PTL][release][stable] 2023.1 Antelope transition to Unmaintained)
18:55:33 <gmann> frickler: ++
18:55:36 <gouthamr> frickler++ yes
18:56:08 <gouthamr> totally in support of pruning the long list we've accrued - and we can't do it selectively no matter what we tell ourselves :(
18:56:23 <gouthamr> selectively = one project at a time, at the request of the project team
18:56:50 <noonedeadpunk> I have 1 thing to raise with releases team about that actually
18:56:57 <fungi> note that unmaintained branches are supposed to be eol'ed by default if nobody volunteers as a caretaker
18:57:06 <noonedeadpunk> As I'd really love to have trailing projects to be also trailing for moving to unmaintained
18:57:20 <gmann> Tempest pin can be one good check here if we have anyone maintaining them or not
18:58:01 <fungi> well, even if tempest jobs are working on them, if nobody volunteers to take care of them they're supposed to go to eol anyway
18:58:02 <noonedeadpunk> There're multiple issues otherwise. First, I need anyway to wait for rest to move to unmaintained to reffer their tags for EM tag of osa, for instance
18:58:37 <noonedeadpunk> then, trailing projects have not released 2024.2 yet, and instead of focusing on release have to focus on unmaintained
18:58:48 <frickler> fungi: yes, but how is this volunteering to be happening, who tracks it, who proposes the actual eol patches?
18:58:51 <fungi> and the volunteers are supposed to renew their intent every 6 months
18:59:25 <gmann> noonedeadpunk:  I see your point here, make sense.
18:59:43 <gmann> noonedeadpunk: just wondering how it was when we had EM thing?
19:00:05 <fungi> "By default, only the latest eligible Unmaintained branch is kept. When a new branch is eligible, the Unmaintained branch liaison must opt-in to keep all previous branches active."
19:00:15 <fungi> #link https://governance.openstack.org/tc/resolutions/20230724-unmaintained-branches.html#unmaintained-branches
19:00:28 <noonedeadpunk> I was always ... annoyed that it was not having trailing policy for EM as well :)
19:00:46 <bauzas> time check nope ?
19:00:49 <gmann> in that case, we should do the same trailing policy
19:00:54 <frickler> fungi: well technically the first sentence is wrong ... by default, nothing changes
19:01:01 <gouthamr> a few minor updates from me:
19:01:01 <gouthamr> - the TC PTG summary is still being written; so, please, in case you've any more thoughts to share on the discussions, go for it without any further delay :)
19:01:01 <gouthamr> - there's an "unofficial" official OpenStack website page for the TC: https://www.openstack.org/community/tech-committee ; the content seems to be broken, please fix your foundation profiles.. but also, rest assured, this page will die soon.. because the OpenStack website is getting overhauled
19:01:01 <gouthamr> - next week's meeting will be our Video Meeting! VMWare Working Group folks will be joining us to present their findings, and seeking opinions for organizing work items wrt the large number of new users coming over from VMWare now, and in the near future
19:01:03 <noonedeadpunk> and if you check history - osa was the latest for quite a while to produce em/eom tags
19:01:05 <fungi> frickler: so if there is no unmaintained branch liaison, there is nobody to opt into keeping the branches open, and they should go to eol
19:01:10 <gouthamr> that said, we're a minute over..
19:01:20 <gouthamr> we can keep chatting.. but i'll end this meeting
19:01:21 <gmann> noonedeadpunk: I mean, good to have trailing policy for unmaintined
19:01:25 <gouthamr> thank you all for attending
19:01:27 <noonedeadpunk> ++
19:01:29 <gouthamr> #endmeeting