18:00:13 <rosmaita> #startmeeting tc
18:00:13 <opendevmeet> Meeting started Tue Feb 13 18:00:13 2024 UTC and is due to finish in 60 minutes.  The chair is rosmaita. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:13 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:00:13 <opendevmeet> The meeting name has been set to 'tc'
18:00:25 <rosmaita> #topic roll call
18:00:29 <gmann> o/
18:00:31 <knikolla> o/
18:00:50 <rosmaita> we have 4 excused absences, so we will need all 5 unexcused people to show up or we have to cancel the meeting
18:00:53 <rosmaita> 0/
18:00:59 <rosmaita> i mean, o/
18:01:16 <rosmaita> so, let's wait a few minutes
18:01:38 <rosmaita> i saw dansmith around here earlier today
18:01:44 <gmann> we can have meeting without quorum also its just we cannot take formal vote/agreement if no quorum
18:01:49 <fungi> technically you don't have to cancel, right
18:02:03 <rosmaita> i don't know whether i am happy or sad about that
18:02:14 <gmann> :)
18:02:22 <rosmaita> ok, we will proceed as usual and see what happens
18:02:33 <rosmaita> 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:02:35 <fungi> since the tc doesn't often make decisions in these meetings, whether the meeting is quorate is mostly only important for satisfying the minimum number of meetings claimed in the charter
18:02:52 <dansmith> o/
18:02:53 <dansmith> sory
18:02:54 <rosmaita> Today's meeting agenda can be found at https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee.
18:03:34 <rosmaita> ok, if we have to do anything official, we can try to round up spotz[m]
18:03:49 <rosmaita> otherwise, everyone is here, so let's get started
18:04:04 <gmann> yeah
18:04:12 <rosmaita> topic Follow up on tracked action items
18:04:15 <rosmaita> - No action items from Jan 30 meeting.
18:04:23 <rosmaita> so i guess that's that
18:04:34 <rosmaita> #topic Gate health check
18:05:04 <rosmaita> anyone have anything to say?
18:05:11 <gmann> I did not notice any frequent failure
18:05:22 <rosmaita> me neither
18:05:37 <dansmith> really? :)
18:05:55 <dansmith> granted I've been a little out of the loop this last week,
18:06:05 <rosmaita> yeah, just a few rechecks here and there on the patches i've looked at
18:06:06 <dansmith> but I rechecked a glance guest kernel crash myself
18:06:30 <rosmaita> ok, but that's kind of an act-of-god thing, isn't it?
18:06:32 <dansmith> nova still seems to be finding plenty of them, but we do run the widest set I think
18:06:39 <dansmith> eh?
18:07:02 <rosmaita> i mean there's nothing glance is doing that crashes the kernel, i wouldn't think
18:07:09 <dansmith> guest kernel crashes have been frequent and getting worse for, what, over a year now.. we've been trying to loop in kernel teams to figure out what's going on but to no avail
18:07:18 <gmann> act-of-kernal :)
18:07:22 <dansmith> oh, no I just meant glance being not-nova
18:07:41 <dansmith> these kernel crashes seem to be way more frequent on volume-based tests, but we have no idea why
18:09:19 <dansmith> anyway, I was just surprised to hear people thinking things are better, but I don't have much other than that to add :)
18:09:20 <rosmaita> ok, so sounds like the current situation is "mostly sunny, with scattered guest kernel crashes"
18:09:59 <rosmaita> ok, let's end this topic on an optimistic note, for once
18:10:09 <rosmaita> #topic Implementation of Unmaintained branch statuses
18:10:37 <rosmaita> i don't know that there's anything new here ... saw some discussion in the channel earlier, but maybe that's better for open discussion
18:10:59 <rosmaita> the next step is moving the pre-yoga branches to Unmaintained
18:11:13 <rosmaita> but i don't know what the schedule for that is
18:11:17 <gmann> I saw releasenotes job failing in my tacker change for stable/yoga and bcz it is now unmaintained/yoga
18:11:33 <gmann> but did not debug yet. this might be case for other projects also?
18:11:40 <rosmaita> yes, there are bot-generated patches updating that
18:11:53 <gmann> nice. thanks for info
18:11:57 <gmann> I will check those
18:12:11 <rosmaita> https://review.opendev.org/q/topic:%22reno-eom-yoga%22
18:12:23 <gmann> ++
18:12:28 <fungi> a concern was raised that the redirect on the releases site was still going to stable-named branches in requirements rather than unmaintained, but tonyb has a change up to fix that
18:13:20 <rosmaita> last i heard, requirements was keeping both stable/y and unmaint/y until things calm down?
18:13:40 <clarkb> both are needed until stable/y doesn't exist anywhere else
18:13:54 <clarkb> otherwise the zuul branch association behaviors associate you to master by defaul and you break
18:14:13 <rosmaita> ok
18:14:15 <gmann> we still need to move those for devstack/grenade at the end but before requirement
18:14:56 <fungi> i also brought up that we're seeing an increasing number of projects proposing their individual foo-unmaintained-core groups while excluding openstack-unmaintained-core, and i'm concerned that the rationale for having an open central group where anyone can join and help review/approve changes for the unmaintained branches/projects they care about hasn't been clearly communicated to the
18:14:58 <fungi> wider community, so it's been falling on the project-config reviewers to reiterate that to each team as they propose an acl update
18:15:27 <dansmith> yeah it came up in the nova meeting an hour ago, and it seemed like the default suggestion was for a per-project group,
18:15:28 <rosmaita> well, that's a bummer
18:15:32 <gmann> but that is ok right?
18:15:37 <dansmith> but I pointed us to the default being the global group
18:15:53 <rosmaita> yeah, i thought i was pretty clear about that in the email i sent last month
18:16:02 <rosmaita> but, i guess not
18:16:06 <dansmith> definitely seems like the complex arrangement we came up with has generated confusion
18:16:15 <gmann> but if any project want to create project-wise group it is still fine we just need to tell them we have global group also if that is enough for them
18:16:46 <rosmaita> "The global openstack-unmaintained-core team will, by default, handle  maintenance of unmaintained/yoga branches (both CI and merging patches).    If your project wants to have its own <project>-unmaintained-core  team, it's allowed, but you have to create it yourself."
18:16:47 <gmann> are those projects proposing per project group not aware of global group? that may be interested to ask
18:16:49 <fungi> i suppose it's okay for individual projects to want exclusive control over those branches, but the number of them who have been proposing those changes and their responses to our review comments make it seem like some are under the mistaken impression it's expected of them
18:17:13 <fungi> i think they're just copying the changes they see other projects propose
18:17:13 <gmann> ohk
18:17:15 <clarkb> it also indicates to me that we haven't solved the feeling of obligation around supporting those branches
18:17:20 <rosmaita> i thought the "create it yourself" would be enough to discourage people
18:17:43 <dansmith> clarkb: well, the misunderstanding could explain that, but yeah
18:17:58 <gmann> maybe rosmaita can send it explicitly in ML which you already sent in your original email but might have been not read due to large text or so
18:18:11 <rosmaita> good idea
18:18:18 <fungi> at least one ptl said they proposed a group for their team because nobody on the central team had approved the bot-proposed changes for their unmaintained branches yet, and seemed not to realize they could just become part of that central team
18:18:47 <rosmaita> #action rosmaita send email about the global unmaint group being the default, and that it's open for people to join
18:18:53 <fungi> it was also brought up that there's no clear explanation for how someone gets to be part of openstack-unmaintained-core or what the process is for applying
18:18:54 <gmann> and might be they thing it is wider work/responsibility if they become part of global group?
18:19:15 <gmann> fungi: good point
18:19:23 <rosmaita> fungi: that's a good point, and i don't know myself, other than to contact current members of that group
18:19:29 <fungi> being part of openstack-unmaintained-core shouldn't require that you care about every project, i don't expect
18:19:43 <gmann> fungi: yeah, we should clear that explicitly in documentation
18:20:11 <gmann> otherwise many PTL might think they need to handle other projects also along with their own
18:20:50 <fungi> yes, saying clearly that it's okay to only review unmaintained changes for one project might help, that you're not obligated to review everything
18:20:59 <gmann> yeah
18:21:24 <rosmaita> well, that's kind of up to the openstack-unmaintained-core team (i mean, to decide what responsibilities are)
18:21:40 <rosmaita> anyone can +1/-1 unmaintained patches
18:21:41 <fungi> also some policy like anyone who's a current or former core reviewer for an openstack deliverable can be immediately added to openstack-unmaintained-core on request might help to bootstrap it beyond the current two members
18:22:49 <fungi> i agree it's for the members of openstack-unmaintained-core to decide how the group is managed, but projects are now seeking information on how it's managed and that hasn't been communicated
18:23:15 <gmann> we can clarify all these things here #link https://docs.openstack.org/project-team-guide/stable-branches.html#unmaintained-branch-maintenance
18:23:18 <fungi> and it at least seems like it has become a blocker to some contributors who want to approve patches on those branches
18:23:52 <gmann> rosmaita: let me know if you want to do otherwise I can push the doc change and we can see if we cover all these in doc
18:24:45 * rosmaita is thinking
18:24:53 <fungi> and having too much process/bureaucracy around adding people to the group will inevitably lead to the situation we had with the central stable-maint team
18:25:19 <rosmaita> well, the idea was that it would be a self-maintaining group
18:25:41 <rosmaita> so i guess what we need is to ask the current members to add a meeting or something so that people know how to contact them
18:25:47 <fungi> where current members are afraid to add interested participants either because they set the requirements and responsibilities too high, so the individual teams just created their own stable review groups instead
18:26:08 <rosmaita> let's do this:
18:26:24 <gmann> but its group for unmaintained branches so less risky than previous stable branch grou[
18:26:26 <gmann> group
18:26:32 <rosmaita> 1 - i will send the email telling people about the general group being the default
18:26:49 <fungi> yes, which is why i hope they'll just make it open to anyone who's interested and has at least some minimal involvement in openstack
18:26:54 <rosmaita> 2 - we will encourage elodilles and tonyb to figure out something to tell people about joining
18:27:17 <fungi> sounds good to me. thanks!
18:27:43 <rosmaita> ok, i'll just say as part of #1 to watch for a followup email about #2
18:27:52 <rosmaita> anything else?
18:27:57 <fungi> not from me
18:27:57 <dansmith> rosmaita: maybe also say "you should only opt into a separate group if you want to maintain the unmaintained branches yourself and don't want the larger group to do it for you, otherwise you have no such obligation"
18:28:23 <rosmaita> good idea
18:28:25 <gmann> rosmaita: and update the doc also with the expectation and how to get added
18:28:25 <fungi> don't want the larger group to do it for you and don't want to be part of that larger group yourself
18:28:57 <rosmaita> tell you what, after the meeting, i will draft my email in an etherpad and won't send it until 2100 utc today
18:29:08 <rosmaita> and that way people can make suggestions or comments
18:29:22 <dansmith> fungi: I think that's implied in the "don't want the larger group to be *able* to do it" but yeah.. maybe also reiterate the "just join the larger group if you want to approve things, no need for a separate group"
18:29:42 <rosmaita> #link https://etherpad.opendev.org/p/unmaintained-global-default
18:30:08 <rosmaita> ok, moving on
18:30:19 <rosmaita> #topic Murano project status
18:30:21 <rosmaita> gmann: that's you
18:30:55 <gmann> yeah so murano is inactive seeing no response on email, gate fix and fungi mentioned about same in vmt also
18:31:16 <gmann> no response on security issue is more critical here
18:31:48 <gmann> and we had discussion in IRC I think yesterday about it and I propose it to mark it Inactive #link https://review.opendev.org/c/openstack/governance/+/908859/3
18:32:24 <gmann> and because our current process doc did not explicitly cover about marking project Inactive after milestone-2 which is release tema deadline to do so, I am updating the doc also #link https://review.opendev.org/c/openstack/governance/+/908880/2
18:32:35 <gmann> so doc change first and then marking Murano Inactive
18:33:09 <gmann> we can discuss here if any question/feedback or maybe in gerrit
18:33:20 <rosmaita> yes, not responding to security issues is really bad
18:33:25 <rosmaita> thanks for posting those patches
18:33:48 <fungi> a related question is how the reported vulnerability for it should be handled
18:34:53 <fungi> right now it's private, with only the vmt coordinator and original reporter posting on it. odds it will be fixed in private are slim, based on the unresponsiveness of the ptl who seems to be the only recently-active member of murano-drivers (they don't have a separate murano-coresec team)
18:35:24 <fungi> the vmt is technically not even overseeing reports of vulnerabilities in murano, it just happened to get reported directly to us by e-mail
18:35:37 <rosmaita> in your estimation, does it require a lot of murano knowledge to fix?
18:36:02 <fungi> it requires more murano knowledge than i have (which is approximately zero), but how much more i'm unable to guess
18:37:15 <gmann> also, its difficult to validate the fix also when no core around it
18:37:17 <rosmaita> well, i guess the general VMT policy is that after 90 days or something, it becomes public ... is that right?
18:37:20 <fungi> i'd be okay with an outcome of switching the report to public, but since the team hasn't delegated that responsibility to the vmt i'd look to the tc to decide if that's an appropriate course of action
18:37:44 <fungi> that's the vmt's policy for repositories we oversee, but murano isn't one of them
18:38:15 <rosmaita> i'd say what we could do is (a) make it public, and (b) merge a sentence to the README to all stable branches with a reference to the bug
18:38:31 <gmann> If project move to Inactive and no response from PTL in coming month or so then I think making it public is good
18:38:56 <fungi> yeah, also the bug report is only a little over a month old, i'm mainly asking because the original reporter is asking me why there has been no response yet
18:39:44 <rosmaita> ok, so we have a little less than 2 months to decide
18:40:05 <fungi> one other thing to keep in mind: while the project has been apparently inactive for a long time, this discussion is coming up in the middle of lunar new year and the current ptl (and only ostensible contributor remaining) may not be near a computer
18:40:23 <gmann> cool, by that time we will have more clarity if anyone around or new members step up to maintain it
18:40:42 <fungi> thanks, i'll try to convey that to the reporter in the bug report for now
18:40:51 <gmann> but ML and gate is broken for long I think first email about inactive was in jan
18:41:17 <gmann> last I heard/notice PTL was in election only
18:41:57 <rosmaita> it sounds like we need to plan for munano becoming inactive AND we must make a decision about how to handle the security bug on the stable branches
18:42:11 <rosmaita> (assuming murano is branched? i don't even know that much about it)
18:42:22 <gmann> yes
18:42:54 <rosmaita> everyone: please vote on https://review.opendev.org/c/openstack/governance/+/908859
18:43:06 <fungi> it is branched, with stable branches all the way back to train, and no transition to unmaintained, presumably because of having nobody to ack changes for that or eol
18:43:08 <rosmaita> and please think about strategies for dealing with the security issue
18:43:51 <rosmaita> fungi: thanks for that info
18:44:21 <rosmaita> sounds like we should consult with the openstack-unmaintained-core team, but i think we should directly EOL train through yoga for murano
18:44:52 <rosmaita> because there is no one to opt-in to keeping it Unmaintained
18:45:13 <rosmaita> #topic Testing runtime for 2024.2 release
18:45:16 <rosmaita> gmann: that's you again
18:45:32 <gmann> I pushed change about it and discussion also going on there
18:45:54 <gmann> I will reply on python 3.12 addition comment in gerrit
18:46:28 <gmann> other than that nothing specific here to discuss than request for review/feedback in gerrit ot email
18:46:57 <rosmaita> ok, thank you
18:47:04 <clarkb> re python3.12 I don't know if any of the distros we have deployed make it installable
18:47:10 <rosmaita> #link https://review.opendev.org/c/openstack/governance/+/908862
18:47:13 <clarkb> you can still theoretically install it from elsewhere though
18:47:32 <clarkb> historically ubuntu has pushed packages for newer python on the existing LTS but I don't think that has happend yet for 3.12
18:48:26 <gmann> yeah, just now commented in gerrit also
18:48:42 <gmann> Ubuntu 24.04 will have but that is not coming soon at least not before next dev cycle start
18:49:09 <rosmaita> ok, looks like there will be a healthy discussion on the patch in gerrit
18:49:20 <rosmaita> #topic 2024.1 TC Tracker
18:49:20 <gmann> I thin may be 2025.1, next SLURP can be target for py3.12 ?
18:49:41 <rosmaita> #link https://etherpad.opendev.org/p/tc-2024.1-tracker
18:50:00 <rosmaita> anyone have anything they'd like to report?
18:50:23 <dansmith> clarkb: maybe because it breaks so much stuff? :)
18:51:26 <rosmaita> #topic open discussion
18:51:42 <rosmaita> i guess we already covered the unmaintained core stuff
18:52:38 <fungi> yep, sorry if that was mildly off-topic for the unmaintained transition segment
18:52:40 <rosmaita> are there any other issues (other than guest kernel crashes) on people's minds?
18:54:00 <rosmaita> apparently not
18:54:26 <rosmaita> ok, give me a few minutes to write up an email draft on https://etherpad.opendev.org/p/unmaintained-global-default
18:54:37 <rosmaita> i won't send until after 2100 utc today
18:54:43 <rosmaita> thanks everyone!
18:54:52 <rosmaita> #endmeeting