17:00:19 <gouthamr> #startmeeting tc
17:00:19 <opendevmeet> Meeting started Tue Jul 22 17:00:19 2025 UTC and is due to finish in 60 minutes.  The chair is gouthamr. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:19 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:19 <opendevmeet> The meeting name has been set to 'tc'
17:00:33 <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.
17:00:36 <gouthamr> Today's meeting agenda can be found at https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee
17:00:39 <gouthamr> #topic Roll Call
17:00:42 <noonedeadpunk> o/
17:00:50 <gtema> o/
17:02:38 <cardoe> o/
17:03:02 <gouthamr> courtesy-ping: gmaan, frickler, spotz[m], mnasiadka
17:03:11 <gmaan> o/
17:03:14 <gouthamr> noted absence: b a u z a s
17:05:19 <gouthamr> alright, looks like a small crowd today
17:05:21 <gouthamr> lets get started
17:05:28 <gouthamr> #topic Last week's AIs
17:05:53 <gouthamr> We took an AI to catch up on the eventlet timeline change proposal..
17:06:20 <gouthamr> hberaud reviewed the change, as had many of you.. so i went ahead and clicked buttons, it's now merged
17:06:25 <gouthamr> #link https://review.opendev.org/c/openstack/governance/+/952903
17:07:12 * gouthamr ah mn asiad ka is on PTO
17:07:33 <gouthamr> the next AI was to discuss the state of Monasca with its maintainers
17:07:48 <gouthamr> that's happening here:
17:07:49 <gouthamr> #link https://review.opendev.org/c/openstack/governance/+/953671
17:08:30 <gouthamr> summarizing the last few comments, the current PTL mentioned still being interested in the project, yet lacking time to maintain it
17:09:06 <gouthamr> he volunteered thuvh, who expressed interest to continue the maintenance of the project..
17:09:30 <gmaan> yeah, I saw that. it seems it is same response as last cycle but we have seen no improvement in this cycle.
17:09:32 <spotz[m]> oh here! o/
17:10:08 <gouthamr> i think we can keep the project in its "inactive" state through this release, and pose the question again next cycle
17:10:40 <gtema> and again, and again, and again, ... I am really wondering - why?
17:10:43 <gmaan> 'continue the maintenance' ? it is inactive means no maintenance till now. are they volunteering to spend some time to start maintianing it?
17:10:46 <fungi> how long has it been inactive at this point?
17:11:09 <gmaan> yeah, I am not seeing any reason of repeating the same things in this cycle and next
17:11:39 <gmaan> I remember exact response  that 'we will maintain' and then disappear
17:11:48 <gouthamr> one thing we could suggest is to take it out of the "openstack" namespace..
17:11:58 <fungi> looks like it's been missing from the coordinated release since caracal, bobcat was the last release it was included in
17:12:07 <gmaan> inactive since 2024.1
17:12:16 <gmaan> 1.5 years ?
17:12:20 <gmaan> if I counted correctly
17:12:26 <fungi> approximately, ye
17:12:28 <fungi> s
17:12:46 <gouthamr> says so on the inactive projects page:
17:12:47 <gouthamr> #link https://governance.openstack.org/tc/reference/emerging-technology-and-inactive-projects.html#current-inactive-projects
17:14:18 <gouthamr> users/operators want to continue their usage of this, but can't commit to the maintenance expected of an OpenStack (service) project team..
17:14:41 <gmaan> and it should have been asked for inactive extension like freezer asked before when noonedeadpunk needed more time
17:14:51 <gmaan> even maintainers are not doing that
17:15:22 <noonedeadpunk> should we give the very last warning to them?
17:15:37 <noonedeadpunk> and be explicit that next cycle it will go out if no changes are made?
17:15:55 <noonedeadpunk> as I'm not sure if/how we communicated last cycle
17:16:23 <noonedeadpunk> was it - we grant it to you but you must release next time, or oh, you need more time - okay
17:16:28 <noonedeadpunk> if it makes sense
17:16:36 <gouthamr> yeah, unless they were plugged into the discussions here (or the ML), i don't know if they knew what needed to be done cycle-to-cycle
17:16:58 <gouthamr> i recall sending Hasan Acar this: https://governance.openstack.org/tc/reference/emerging-technology-and-inactive-projects.html#exit-criteria
17:17:02 <fungi> sticking to current policy, the next step if not extending their inactive status again would be to retire the project
17:17:35 <fungi> then if anyone wants to continue it outside openstack they could fork it somewhere and revert the retirement change(s)
17:18:09 <gouthamr> true
17:18:14 <fungi> wouldn't even need to deprecate it since none of the releases they were included in are maintained any longer
17:18:34 <fungi> (bobcat is eol, antelope is unmaintained)
17:19:37 <fungi> so basically if anyone is still *using* monasca they're doing so on openstack versions that are no longer officially maintained upstream anyway
17:19:46 <gouthamr> okay, we can remind thuvh this, and if they don't contest the PTL election, this can head to retirement soon after?
17:19:46 <gouthamr> afaiu, we can retire the project by the end of this release too.. because of the reason fungi mentioned abobve
17:20:12 <gmaan> I do not think we should make PTL election as thing they "we are ok"
17:20:17 <noonedeadpunk> I think it's not about current usage, but returning project to protfolio if wqe find it valuable and people who stepped in are serious enough
17:20:39 <gmaan> we should have all the checks and if not become inactive by m-1 (or before) or so then it must be retired
17:20:44 <gouthamr> yes
17:20:49 <fungi> restoring the project in openstack would be as "simple" as reverting the retirement changes in-place
17:21:03 <gouthamr> i agree, i think the upcoming PTL election is just the first of those things in the checklist
17:21:10 <gmaan> if no PTL, then ayways we can retire but if PTL still we cannot trust that factor as that did not worked out in past
17:21:19 <spotz[m]> Sounds like a decent enough plan
17:21:21 <gmaan> fungi: ++
17:21:53 <spotz[m]> I agree having a PTL isn't the end, they need to do the rest of the checklist
17:21:55 <gmaan> but I really would like us to make this exception with formal vote for transparency and fairness to any other project
17:22:33 <gmaan> exception to the process of "after project inactive status timeline, project needs to be retired"
17:23:04 <fungi> maybe the inactive and emerging projects list should include information on extensions, so that the tc can formally vote on changes which add or renew an extension
17:23:18 <gmaan> I think we added that
17:23:33 <gouthamr> yeah, we didn't track this in 2025.1
17:23:40 <gouthamr> (and 2025.2)
17:23:46 <gmaan> and monasca failed to ask for extension means they are eligible for retirement
17:23:59 <fungi> #link https://governance.openstack.org/tc/reference/emerging-technology-and-inactive-projects.html#current-inactive-projects doesn't seem to list the extensions
17:25:10 <fungi> if extensions were explicitly added entries in the rst file in gvernance, then the tc members would de facto need to vote on any changes updating them
17:25:43 <gmaan> I tried to add here but we can improve doc
17:25:47 <gmaan> #link https://review.opendev.org/c/openstack/governance/+/923441/1/reference/emerging-technology-and-inactive-projects.rst
17:26:22 <fungi> aha, yes
17:26:47 <fungi> maybe instead list the retirement deadlines in the document? that way extending them each cycle would be necessary, which forces a tc vote
17:26:51 <gmaan> If we continue with monasca for another cycle, I am ok but for having same process for all other projects in future, my suggestion is to grant this exception as resolution or any ohter formal way
17:27:53 <fungi> "...will be officially retired on yyyy-mm-dd unless explicitly extended by a vote of the technical committee" (or maybe that's too wordy)
17:28:28 <spotz[m]> Could we do the date as r-? That way we don't have to constantly up date the doc
17:28:29 <gouthamr> +1 i think that's explicit, and can be used in the doc warning as well
17:28:53 <fungi> spotz[m]: the point would be to constantly update the date in the doc, because that forces a tc vote
17:29:00 <gmaan> yeah, having retirement date is good idea
17:29:25 <spotz[m]> Ahh, I read as if we have it more explicit in the doc we have to vote:)
17:29:35 <gmaan> I expect and we can document also that 'project needs to apply for extension not TC'
17:29:49 <fungi> solving the expressed problem of the tc implicitly allowing inactive state to continue without explicitly granting an extension every cycle
17:30:31 <gouthamr> > I expect and we can document also that 'project needs to apply for extension not TC'
17:30:31 <gouthamr> +1
17:30:58 <fungi> also havign a clearly stated deadline might light a fire under people interested in helping out (probably not, but you never know)
17:31:40 <gouthamr> okay sounds like a good plan, i can ask monasca folks chatting on the gerrit change to propose this..
17:32:27 <gouthamr> still hoping we can have that big beautiful warning (sorry :P) on the doc asap
17:32:52 <gouthamr> anything else on this AI?
17:33:45 <gouthamr> noonedeadpunk: you took an AI to explore a review dashboard, would you like to share any updates?
17:34:39 <noonedeadpunk> yes, I did, and unfortunatelly I did not have good progress.
17:34:51 <noonedeadpunk> But I will get it ready for the next week
17:35:00 <noonedeadpunk> or well, at least for the review/discussion
17:35:00 <gouthamr> ah.. thank you.. that's all the AIs I see, was anyone working on anything else?
17:35:11 <noonedeadpunk> sorry :(
17:35:41 <gouthamr> no problem! i suspect summer break is still underway? or we're in the thick of it.. there's no rush reall
17:36:14 <spotz[m]> As of right now the TC Forum session did not get accepted. There's a chance more slots will open but I don't remember offhand where the session was on the list
17:36:32 <gouthamr> ack ty spotz[m]
17:36:48 <gouthamr> yeah, it was tough competition..
17:37:06 <gouthamr> but, there's a session on contributor experiences that i hope the TC can participate in
17:37:45 <gouthamr> Sun, October 19, 2:45pm - 3:15pm | Alfred Sauvy
17:37:49 <gouthamr> Improving Contributor Experience in the OpenStack Community
17:37:56 <gouthamr> can;t deep link, sorry:
17:37:57 <gouthamr> #link https://summit2025.openinfra.org/a/schedule/
17:38:56 <gouthamr> lets move to the next topic
17:39:05 <gouthamr> #topic A check on gate health
17:39:11 <fungi> if memory serves, there was room in the schedule to accept ~50% of forum submissions
17:39:45 <gouthamr> ack, there were very good submissions..
17:40:51 <gmaan> nothing on gate. ceph job was broken and failing test is skipped for now
17:41:25 <gouthamr> oh, was this in a job running against nova?
17:41:42 <gmaan> yeah nova has ceph jobs and devstack seph plugin job also
17:41:49 <gmaan> ceph
17:42:12 <gmaan> sean-k-mooney is trying to run ceph job on debain but not sure how far that is. but that is good idea too
17:42:46 <fungi> opendev has fully moved everything off nodepool as of late last week. there are still a smattering of multi-node jobs that were getting split between providers when we got obscure boot failures from nova under heavy load (mainly during periodic jobs), but there's a fix merging to zuul now that should basically eliminate that behavior entirely
17:42:56 <gmaan> #link https://review.opendev.org/c/openstack/nova/+/955179
17:43:46 <gouthamr> ty for the link
17:43:47 <gouthamr> ty fungi
17:44:25 <fungi> we also dropped ubuntu-bionic-arm64 labels, but very little was using those (ancient unmaintained branches that never really worked on arm to begin with)
17:44:53 <gouthamr> i'd suggest running the parent job on devstack-plugin-ceph with debian, lest there's something in the plugin that would break things
17:45:25 <clarkb> one thing to keep in mind switching to debian from ubuntu is the support term is much shorter
17:45:47 <gouthamr> true, we struggled to keep up with fedora
17:45:48 <fungi> oh, and yeah i think the debian-trixie nodes should be usable now? just keep in mind that it's not yet fully released so could still see a little churn (but it's in freeze preparing to release in a few weeks)
17:45:49 <clarkb> I mentioned this a week or two ago but we need to be better bout proactively removing stuff that is ancient
17:46:01 <spotz[m]> Debian is shorter then Ubuntu?
17:46:18 <clarkb> spotz[m]: yes debian is ~2 years (its a bit nebulous and based on when the next release occurs) and ubuntu is 5
17:46:32 <clarkb> or maybe its ~3 years? something like that
17:46:37 <clarkb> its definitely less than 5
17:46:51 <fungi> debian and ubuntu produce releases every 2 years, but debian drops official upstream support at about the 2.5-year mark and then the debian lts team takes over to unofficially support it after that
17:47:04 <sean-k-mooney> gmaan: i got it mostly working it pass the issue with qemu-image and failed on other volume tests but i did not ahve time to debug
17:47:39 <fungi> i should say debian and ubuntu *lts* release about every 2 years
17:47:40 <gmaan> sean-k-mooney: ack
17:48:10 <fungi> (though with the advent of the debian lts team, it's arguable that they have approximately similar maintenance levels any more)
17:48:17 <spotz[m]> Yeah I just remmber running really old versions of Debian at one job so always think of it as slower moving
17:48:17 <noonedeadpunk> I would say Ubuntu also has a more settled relase schedule
17:48:26 <noonedeadpunk> so you can kinda prepare a bit in advance
17:48:39 <noonedeadpunk> and less aggressive in going forward as well...
17:48:45 <fungi> yes, debian doesn't do timed releases, debian's release criteria depend on bug counts mainly
17:48:51 <sean-k-mooney> when ever we get debain 13 avaible (trixie) it would be interesting to enable that in oen of our nova jobs although hopefully ubuntu will fix there lts ceph regression shortly
17:49:03 <clarkb> anyway this isn't an argumetn against debain ist moer of a "please don't make the current situation where we never delete anything old worse and dump more work on the opendev team when they try to remove old platforms"
17:49:08 <fungi> so how fast they release is somewhat related to how fast people fix release-critical bugs that are filed
17:49:43 <sean-k-mooney> well our os policy for debian is we supprot the latest stabel release that is release beofre the start of a cycle
17:49:48 <sean-k-mooney> simialr to ubuntu right
17:49:50 <clarkb> openstack needs to be far more proactive when branching stable branches to claer out things that aren't going to be supported for 5 years
17:50:04 <noonedeadpunk> oh, yes, suere, debian is great, just ubuntu gives a little more room to breathe when already stretched on resources, imo
17:50:06 <fungi> sean-k-mooney: https://zuul.opendev.org/t/openstack/image/debian-trixie
17:50:12 <fungi> it's there
17:50:36 <sean-k-mooney> fungi: i saw there were patches in flight but didnt see they merged thanks for the link
17:51:20 <sean-k-mooney> per our testing runtime the first release that it would be a candiate to supprot would bve 2026.1
17:51:27 <sean-k-mooney> right?
17:52:01 <fungi> trixie is scheduled to release on august 9 so, yes
17:52:02 <sean-k-mooney> that would be the release where we support debian 12 and 13 for upgrade and in 2026.2 we can stop testing with 12
17:52:33 <fungi> (a little over 2 weeks away now)
17:53:02 <fungi> we just have the images available early since it's stable enough during the final hard freeze
17:54:21 <gmaan> and frickler is working on devstck support
17:54:25 <gmaan> #link https://review.opendev.org/c/openstack/devstack/+/954653
17:55:09 <fungi> thanks frickler!
17:55:41 <gouthamr> ++
17:55:56 <gouthamr> alright, since we have ~5 mins, lets switch to Open Discussion
17:56:00 <gouthamr> #topic Open Discussion
17:56:57 <gouthamr> we had a governance proposal stuck due to the OIF->LF transition and changes to the OIF Bylaws:
17:56:57 <gouthamr> #link https://review.opendev.org/c/openstack/governance/+/949432
17:57:17 <gouthamr> i'm leaning towards gmaan's suggestion of defining what corporate affiliation means within the TC charter
17:58:08 <gouthamr> will try and propose a patch with that "charter-change".. any objections?
17:58:23 <gmaan> and it does not need to be very legal I mean what TC want about diversity and how to check should be ok
17:58:24 <sean-k-mooney> my personal take on that is effecitly are you paid to work on openstack by a specific comany or not
17:58:42 <gmaan> it is not going to be in bylaw or any legal doc. it can be in TC own defined charter
17:58:49 <sean-k-mooney> anything more complex and highly technical is off putting and hard to express
17:58:57 <gmaan> sean-k-mooney: ++ and without any min amount
17:58:57 <gouthamr> ty, i was leaning towards that as well
17:59:39 * gouthamr takes that AI
17:59:52 <gouthamr> alright, anything else to add to teh minutes this week?
17:59:58 <gmaan> and TC candidates need to mention their affiliation in election or after elected as offical doc in TC
18:00:23 <gouthamr> oh yeah, that was another thread in the same proposal
18:00:30 <gouthamr> will address it, thanks gmaan
18:01:05 <gouthamr> okay, we're at the hour.. thank you all for participating
18:01:27 <gouthamr> this meeting returns next week, but see you/tty on this channel in the meantime!
18:01:33 <gouthamr> #endmeeting