18:00:13 #startmeeting tc 18:00:13 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:00:13 The meeting name has been set to 'tc' 18:00:25 #topic roll call 18:00:29 o/ 18:00:31 o/ 18:00:50 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 0/ 18:00:59 i mean, o/ 18:01:16 so, let's wait a few minutes 18:01:38 i saw dansmith around here earlier today 18:01:44 we can have meeting without quorum also its just we cannot take formal vote/agreement if no quorum 18:01:49 technically you don't have to cancel, right 18:02:03 i don't know whether i am happy or sad about that 18:02:14 :) 18:02:22 ok, we will proceed as usual and see what happens 18:02:33 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 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 o/ 18:02:53 sory 18:02:54 Today's meeting agenda can be found at https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee. 18:03:34 ok, if we have to do anything official, we can try to round up spotz[m] 18:03:49 otherwise, everyone is here, so let's get started 18:04:04 yeah 18:04:12 topic Follow up on tracked action items 18:04:15 - No action items from Jan 30 meeting. 18:04:23 so i guess that's that 18:04:34 #topic Gate health check 18:05:04 anyone have anything to say? 18:05:11 I did not notice any frequent failure 18:05:22 me neither 18:05:37 really? :) 18:05:55 granted I've been a little out of the loop this last week, 18:06:05 yeah, just a few rechecks here and there on the patches i've looked at 18:06:06 but I rechecked a glance guest kernel crash myself 18:06:30 ok, but that's kind of an act-of-god thing, isn't it? 18:06:32 nova still seems to be finding plenty of them, but we do run the widest set I think 18:06:39 eh? 18:07:02 i mean there's nothing glance is doing that crashes the kernel, i wouldn't think 18:07:09 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 act-of-kernal :) 18:07:22 oh, no I just meant glance being not-nova 18:07:41 these kernel crashes seem to be way more frequent on volume-based tests, but we have no idea why 18:09:19 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 ok, so sounds like the current situation is "mostly sunny, with scattered guest kernel crashes" 18:09:59 ok, let's end this topic on an optimistic note, for once 18:10:09 #topic Implementation of Unmaintained branch statuses 18:10:37 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 the next step is moving the pre-yoga branches to Unmaintained 18:11:13 but i don't know what the schedule for that is 18:11:17 I saw releasenotes job failing in my tacker change for stable/yoga and bcz it is now unmaintained/yoga 18:11:33 but did not debug yet. this might be case for other projects also? 18:11:40 yes, there are bot-generated patches updating that 18:11:53 nice. thanks for info 18:11:57 I will check those 18:12:11 https://review.opendev.org/q/topic:%22reno-eom-yoga%22 18:12:23 ++ 18:12:28 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 last i heard, requirements was keeping both stable/y and unmaint/y until things calm down? 18:13:40 both are needed until stable/y doesn't exist anywhere else 18:13:54 otherwise the zuul branch association behaviors associate you to master by defaul and you break 18:14:13 ok 18:14:15 we still need to move those for devstack/grenade at the end but before requirement 18:14:56 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 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 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 well, that's a bummer 18:15:32 but that is ok right? 18:15:37 but I pointed us to the default being the global group 18:15:53 yeah, i thought i was pretty clear about that in the email i sent last month 18:16:02 but, i guess not 18:16:06 definitely seems like the complex arrangement we came up with has generated confusion 18:16:15 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 "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 -unmaintained-core team, it's allowed, but you have to create it yourself." 18:16:47 are those projects proposing per project group not aware of global group? that may be interested to ask 18:16:49 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 i think they're just copying the changes they see other projects propose 18:17:13 ohk 18:17:15 it also indicates to me that we haven't solved the feeling of obligation around supporting those branches 18:17:20 i thought the "create it yourself" would be enough to discourage people 18:17:43 clarkb: well, the misunderstanding could explain that, but yeah 18:17:58 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 good idea 18:18:18 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 #action rosmaita send email about the global unmaint group being the default, and that it's open for people to join 18:18:53 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 and might be they thing it is wider work/responsibility if they become part of global group? 18:19:15 fungi: good point 18:19:23 fungi: that's a good point, and i don't know myself, other than to contact current members of that group 18:19:29 being part of openstack-unmaintained-core shouldn't require that you care about every project, i don't expect 18:19:43 fungi: yeah, we should clear that explicitly in documentation 18:20:11 otherwise many PTL might think they need to handle other projects also along with their own 18:20:50 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 yeah 18:21:24 well, that's kind of up to the openstack-unmaintained-core team (i mean, to decide what responsibilities are) 18:21:40 anyone can +1/-1 unmaintained patches 18:21:41 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 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 we can clarify all these things here #link https://docs.openstack.org/project-team-guide/stable-branches.html#unmaintained-branch-maintenance 18:23:18 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 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 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 well, the idea was that it would be a self-maintaining group 18:25:41 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 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 let's do this: 18:26:24 but its group for unmaintained branches so less risky than previous stable branch grou[ 18:26:26 group 18:26:32 1 - i will send the email telling people about the general group being the default 18:26:49 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 2 - we will encourage elodilles and tonyb to figure out something to tell people about joining 18:27:17 sounds good to me. thanks! 18:27:43 ok, i'll just say as part of #1 to watch for a followup email about #2 18:27:52 anything else? 18:27:57 not from me 18:27:57 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 good idea 18:28:25 rosmaita: and update the doc also with the expectation and how to get added 18:28:25 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 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 and that way people can make suggestions or comments 18:29:22 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 #link https://etherpad.opendev.org/p/unmaintained-global-default 18:30:08 ok, moving on 18:30:19 #topic Murano project status 18:30:21 gmann: that's you 18:30:55 yeah so murano is inactive seeing no response on email, gate fix and fungi mentioned about same in vmt also 18:31:16 no response on security issue is more critical here 18:31:48 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 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 so doc change first and then marking Murano Inactive 18:33:09 we can discuss here if any question/feedback or maybe in gerrit 18:33:20 yes, not responding to security issues is really bad 18:33:25 thanks for posting those patches 18:33:48 a related question is how the reported vulnerability for it should be handled 18:34:53 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 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 in your estimation, does it require a lot of murano knowledge to fix? 18:36:02 it requires more murano knowledge than i have (which is approximately zero), but how much more i'm unable to guess 18:37:15 also, its difficult to validate the fix also when no core around it 18:37:17 well, i guess the general VMT policy is that after 90 days or something, it becomes public ... is that right? 18:37:20 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 that's the vmt's policy for repositories we oversee, but murano isn't one of them 18:38:15 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 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 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 ok, so we have a little less than 2 months to decide 18:40:05 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 cool, by that time we will have more clarity if anyone around or new members step up to maintain it 18:40:42 thanks, i'll try to convey that to the reporter in the bug report for now 18:40:51 but ML and gate is broken for long I think first email about inactive was in jan 18:41:17 last I heard/notice PTL was in election only 18:41:57 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 (assuming murano is branched? i don't even know that much about it) 18:42:22 yes 18:42:54 everyone: please vote on https://review.opendev.org/c/openstack/governance/+/908859 18:43:06 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 and please think about strategies for dealing with the security issue 18:43:51 fungi: thanks for that info 18:44:21 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 because there is no one to opt-in to keeping it Unmaintained 18:45:13 #topic Testing runtime for 2024.2 release 18:45:16 gmann: that's you again 18:45:32 I pushed change about it and discussion also going on there 18:45:54 I will reply on python 3.12 addition comment in gerrit 18:46:28 other than that nothing specific here to discuss than request for review/feedback in gerrit ot email 18:46:57 ok, thank you 18:47:04 re python3.12 I don't know if any of the distros we have deployed make it installable 18:47:10 #link https://review.opendev.org/c/openstack/governance/+/908862 18:47:13 you can still theoretically install it from elsewhere though 18:47:32 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 yeah, just now commented in gerrit also 18:48:42 Ubuntu 24.04 will have but that is not coming soon at least not before next dev cycle start 18:49:09 ok, looks like there will be a healthy discussion on the patch in gerrit 18:49:20 #topic 2024.1 TC Tracker 18:49:20 I thin may be 2025.1, next SLURP can be target for py3.12 ? 18:49:41 #link https://etherpad.opendev.org/p/tc-2024.1-tracker 18:50:00 anyone have anything they'd like to report? 18:50:23 clarkb: maybe because it breaks so much stuff? :) 18:51:26 #topic open discussion 18:51:42 i guess we already covered the unmaintained core stuff 18:52:38 yep, sorry if that was mildly off-topic for the unmaintained transition segment 18:52:40 are there any other issues (other than guest kernel crashes) on people's minds? 18:54:00 apparently not 18:54:26 ok, give me a few minutes to write up an email draft on https://etherpad.opendev.org/p/unmaintained-global-default 18:54:37 i won't send until after 2100 utc today 18:54:43 thanks everyone! 18:54:52 #endmeeting