18:00:38 #startmeeting tc 18:00:38 Meeting started Tue Jan 9 18:00:38 2024 UTC and is due to finish in 60 minutes. The chair is JayF. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:38 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:00:38 The meeting name has been set to 'tc' 18:00:45 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:00:48 Today's meeting agenda can be found at https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee. 18:00:50 #topic Roll Call 18:00:52 o/ 18:00:52 o/ 18:00:57 o/ 18:01:04 o/ 18:01:20 o/ 18:01:40 #info One absence indicated in the agenda: jamespage. 18:02:03 \o 18:02:25 Going to give folks until 5 minutes past the hour to arrive before moving on to the agenda. 18:03:30 i over-dressed for work today, i thought we were having a video meeting 18:04:06 Nope, the video meeting -- first one of January -- was cancelled :) 18:04:15 haha :) 18:04:25 o/ 18:04:38 O/ 18:04:48 #topic Follow up on tracked action items 18:04:56 We had one item from over the holidays 18:05:07 #info spotz[m] to Look into updating https://docs.openstack.org/install-guide/openstack-services.html and report back to TC 18:05:51 Patch is up not sure if it's merged yet as there were some changes requested 18:06:00 it is merged 18:06:01 #link https://review.opendev.org/c/openstack/openstack-manuals/+/904293 18:06:19 Sweet 18:06:35 Awesome! Thanks for that! 18:06:43 Moving on, then. 18:06:47 #topic Gate health check 18:07:06 Has there been any gate issues to speak of since we last met? 18:07:09 I haven't really done much yet this year that interacts with the gate, so I don't have much to add 18:07:23 I saw some issues in cinder 18:07:32 I know that nova has changed their boot mode to use the split kernel (AWS style) because they think it will help with panics, but I'm skeptical 18:07:35 from what I can say, gates are running pretty fine recently 18:07:46 frickler: thanks for fixing the s3 job for cinder 18:08:00 fix is merged i think 18:08:01 skeptical that it should matter, and also concerned that it moves us further away from testing what people actually use for booting in the real world 18:08:12 however, we'll see how it goes and it'll tell us something one way or the other I guess 18:08:28 that s3 issue is fixed, but some other fixes of mine still needed multiple recheck 18:08:29 yeah, we can do those in tempest jobs if that goes well 18:08:45 cinder has a change in the gate right now that should help with the OOM issues we see a lot: https://review.opendev.org/c/openstack/cinder-tempest-plugin/+/901672 18:09:53 also lots of 3rd party CI for cinder produce just rubbish, but that's just a side note I think 18:10:48 (sorry, got caught up in a meeting that is running over) 18:11:31 So that sounds like mostly a positive gate report. 18:11:36 Going to move on if there are no other comments? 18:12:41 #topic Leaderless Projects 18:12:50 #link https://etherpad.opendev.org/p/2024.1-leaderless 18:12:59 This has to be coming to a close as C-2 is coming up soon, yes? 18:13:17 one project left to handle, openstack-chef which I am going to start the retirement which is what agreed in discussion/eterpad 18:13:31 Yeah, I see no further open PTL appointments. 18:13:38 rest all other 11 projects are handled either with PTL appointment or marking them Inactive 18:13:48 no open PTL appointment 18:14:04 speaking about inactive projects 18:14:08 Monasca and senlin are PTL-less and inactive so they can go to next step as per inactive process 18:14:22 can I ask question about Monasca now or better at the end of the meeting? 18:14:29 I appreciate that we've taken more time this cycle to evaluate activity and make noise about how some of these projects are inactive; it seems like we've dredged up some users who might be interested on the mailing list (even if in some cases it may not be in OpenStack governance) 18:14:43 slaweq: go for it 18:14:49 thx 18:14:50 yeah it is related, I saw ML discusison over that 18:15:11 as You maybe noticed, on the ML there is new volunteer who wants to help with Monasca potentially 18:15:27 but IIUC he is willing to do it in free time only 18:15:34 and isn't really active contributor yet 18:15:49 Monasca is already marked as inactive project this cycle 18:16:16 so my question is: should we help ramp up this guy quickly and make Monasca part of the release in this cycle 18:16:26 I am of the opinion it would be a mistake for the TC to vote to consider a project "active" based on a single contributor's commitment. 18:16:33 or should we help to move it to x/ namespace and let it be unofficial project? 18:16:35 after fujistu change their directioh, Monasca is very less active since than 18:16:45 and that such a decision would likely end up with us revisiting this topic in months 18:17:00 slaweq: I think for move to unofficial we don't even change the namespace anymore, but IMBW 18:17:07 JayF: I do not think single controbutor base but how active project is and can be 18:17:24 yeah, I think slaweq proposal to them to continue development in X/ namespace make sense to me too 18:17:40 I think of it not in terms of "how active" but in terms of "how likely are we to keep a 18 month maintenance promise" 18:17:48 for unofficial, the repo in the openstack/ namespace is retired and interested parties create a new fork in a different namespace 18:17:48 and it's hard for a single person to make that kinda promise in any context 18:17:54 JayF: we need to change namespace. we had resolution in past saying only official projects stay in openstack/ name space 18:17:58 ack 18:18:42 other way is we can try for one more cycle if that contributor is able to keep up project as per openstack requirement 18:18:45 (ideally not x/ since that was the dumping ground for evicted projects whose maintainers didn't respond during the namespace migration) 18:19:01 and if not then take decision to move to x/ or retire completly in next cycle 18:19:04 ok, so I can continue work with this volunteer to move project to x/ namespace and retire it in openstack/ name space 18:19:34 slaweq: i did not hear from them in email but do you know they agree with x/ namespace proposal or they only wanted to maintain it in openstack/ 18:19:41 I am +1 to slaweq's plan; but it is mutually exclusive with Monasca being in the release. 18:19:43 well IIUC moving would mean retiring and creating a fork, like fungi said 18:19:52 gmann I didn't hear from them neighter 18:19:58 well, start a fork of it elsewhere, which could be another (new) namespace in opendev if that's where the new maintainers want 18:20:13 yeah, let's check with them first as moving to x/namespace and retirement is too separate thing 18:20:21 or could be on gitlab.com or sourcehut or wherever 18:20:29 and if they say they only wanted to maintain in openstack then we can give them a cycle to se ehow it goes 18:20:37 JayF yes, it would mean that it will not be part of OpenStack official release, but new team/volunteer can make release when they want to 18:21:01 ok, so I will try to reach out to them to discuss that 18:21:09 Yeah, I'm just making the point that there is a decision point for TC: retire monasca to enable it to exist outside, or re-active it so this contributor is freed up to put it in the next release. 18:21:17 The worst thing we can do is no-action which leaves that person in limbo. 18:21:19 hopefully I will have some info before our next meeting 18:21:25 for senlin there has also been someone ( eandersson ) interested in keeping it alive, but not enough to go for PTL 18:21:47 JayF: slaweq and give them a chance means they have to make projct active and change status to active otherwise it can be retired in next cycle 18:22:20 I do not trust a new, not-yet-active contributor to a project to be able to commit to support a release of Monasca for 18 months. 18:22:26 so we can appoint them PTL or give core power to merge thing and make it active and see how they progress but do not change inactive status just because there is volunteer instead based on porject activites 18:22:30 Even if I am extremely appreciative of their willingness to. 18:23:47 frickler: re senlin: yeah i had discussion with him and if DPL model make sense and he agree on that. but did not see any proposal from him. maybe they can get prevous PTL helping something there in future 18:23:50 gmann yes, we can but the thing is that this seems a bit scary for me to give someone totally new +2 power in official repo just like that. Maybe I'm wrong but doing that in unofficial project seems better for me :) 18:24:30 slaweq: we have done that in past for mistral or other project based on their volunteer in ML 18:24:31 from the other hand, I totally understand that moving it back and forth between namespaces isn't good solution at all so we may want to try for one more cycle if needed to see how it will go 18:24:45 on the other hand, how much harm can they do given monasca's current state> 18:24:59 slaweq: for unofficial, we have to retire monasca which I am totally ok but I would like to know if new volunteer is ok for that or not 18:25:08 fungi: yeah 18:25:13 fungi: a lot, really. They'd have a keystone token to the rest of the cloud. 18:25:25 gmann as I said, I will try to reach out to them this week 18:25:32 slaweq: ++ thanks 18:25:51 fungi: If we put "OpenStack" on something; I want it to mean more than just "someone showed up and we gave them the keys with minimal oversight" 18:26:03 slaweq: if they are ok with unofficial, i am all ok with that. 18:26:12 and that includes not "flapping" projects between active/inactive 18:26:47 yes, i do think that project removal from openstack should come without any significant hope that the project can re-enter 18:27:11 well we can keep the project just inactive for a cycle or more, can we? or is retirement mandatory for inactive projects? 18:27:21 frickler: part of the problem is inactivity is a sort of limbo 18:27:39 frickler: retirement is requirement in next cycle of project went into inactive state 18:27:44 frickler: this interested party can't really contribute without a PTL or active core team; we can't release an inactive project, but without retiring it it can't be created outside of openstack 18:27:58 so we have this cycle to keep project inactive and ask new volunteer to make it active 18:28:00 it's an interesting downside to "inactivity" status I'm not sure we've encountered until now 18:28:13 well we could make the volunteer core without them being PTL 18:28:25 and if they are not able to make active then we retire in next cycle and they can fork it outside openstack 18:28:38 yes, that is possible 18:28:49 Is someone on the TC, or in the community, going to volunteer to monitor submissions and act as an ... auditor (for lack of a better word)? 18:29:22 we have done this in past for a few projects where project has zero active maintainers and new maintainers got core power as fresh and maintained project 18:29:23 There are two prongs to concern here: technical, which is minimal (CI will validate this), and trust -- which is only built through time/reputation. I think slaweq and I are both expressing concern about the trust side 18:29:45 yeap 18:29:54 I am confused on that trust thing :) 18:30:10 concern on new contributors or they had some bad history? 18:30:23 we've had a lot of lengthy debates in the past that our community is unwilling to extend trust to newcomers, and that has been blamed (rightfully or no) for some of the decline in renewal of our contributor base 18:30:36 gmann new contributors which are not known at all in community 18:30:42 Most projects with >1 contributor have a built-in auditing process; additional contributors who are watching reviews, contributions coming in, etc 18:30:54 but there are always new contributors in project right 18:31:03 In the case of a project with no activity and a single contributor, it does put us at risk for an "inside attack" style security risk, that's all I'm concerned about. 18:31:12 mistral was one good example in same situation 18:31:14 I also share the concern with regards to trust. In active projects, contributors aren't +2 until the current cohort of cores trusts their knowledge and contributions. In an inactive project there is no such continuity of trust and we as the TC don't have enough information on an individual to vet them. 18:31:20 gmann yes, but usually such new contributor is not the only contributor 18:31:25 seems to me the concern in this case is that the volunteer has nobody to shepherd them 18:31:28 knikolla++ you said that much more eloquently than I did 18:32:05 this seems not good if we do not want to trust new contributors instead we can mentor them if we are in doubt on their policy follow or so 18:32:10 fungi: ++ yes, combined with the concern that a single contributor may not represent any real continuity of maintenance for monasca (e.g. we'll have a version of this conversation again when this person moves on) 18:32:52 I am ok to retire monsaca based on project activities but not based on because volunteer is new and we do not trust them 18:33:13 my suggestion is to give them a chance for this cycle and see how it goes 18:33:33 gmann: If this contributor was interested in a repository I had knowledge and ability to mentor in, I'd be taking that route/stance instead. I don't have that knowledge for the monasca case so I don't know what other options there are. I cannot volunteer another person (does someone with this knowledge even exist in the community still?) to do this work. 18:33:42 we can always retire it anytime if we see any dubious activties or no activity at all 18:33:54 so if essentially we're saying new contributors aren't given a chance to make a project active again, we can stop looking for them 18:34:10 yeah, that is going to be the msg 18:34:38 In know it is rather extremal example but it happened already in the past for other opensource project that someone put there some malicious code even if there were existing reviewers who approved it. In this case, we are givin completly unknown person possibility to merge things without any control. And if this would be still official project, some existing user may simply upgrade Monasca and expect it is fine as it's "signed" by the 18:34:38 OpenStack community still 18:34:52 slaweq++ 18:34:53 Can we move in and out of the x namespace? 18:35:13 that concern would be mitigated by a trusted openstack community member volunteering to mentor or take a monitoring role on Monasca while trust is being built 18:35:24 If we see dubious activity implies the TC will be monitoring every patch to that repo. If one of the TC members is willing to mentor this individual than sure, we can take the proposed path. 18:35:37 spotz[m]: it's extremely labor-intensive for the infra team, that is not a good situation 18:35:55 I will say if we are moving it out of openstack based on situation 'new contributors and only one to maintain so we cannot trust them' then we should make a policy about it first and consistent 18:36:04 moving to x|other is much effort, in addition monasca contains quite a number of repos 18:36:07 spotz[m]: also not really, because there will still be a retired copy in the openstack/ namespace too 18:36:09 Ok just a thought 18:36:25 the problems with moving things back and forth are that you either need to rename projects (something that gerrit doesn't actually support that we hack around) or you need to force push contents between two different locations to catch one side or the other up again 18:36:49 So to be clear; I personally have two concerns: 1) Trust building. As discussed this can be worked around by having a trusted community member in a monitoring/mentoring role. 2) Long term support -- is it wise for us, in general, to reactivate a project based on a committment from a single person. 18:36:50 yeah, it is lot of work to just move x/ namespace. that is why I am saying let's try them in openstack/ only 18:36:55 The ideal solution here would be the creation of a set of individuals (whether from the TC or vetted from the TC) that can take on situations like this one and bootstrap and mentor the new contributor. 18:37:15 knikolla++ 18:37:36 ...which is also "much work" 18:37:40 ++ 18:38:35 I think moving to X sounds like it's the best option here, 18:38:42 It's work that aims to break down the barriers between project teams, but yes, it's a lot of work. 18:38:58 Is there value in taking a quick straw pole with the vote feature? See how close we are to consensus? 18:39:02 *poll 18:39:02 and if in two years these projects have resurrected themselves significantly, then we could consider a change, but 99% chance that will not happen, so moving is probably a safe bet 18:39:07 I think simple is 1. keep it inactive 2. give volunteer +2 (not PTL) power to maintain it in openstack/ 3. in next cycle we monitor the activies and move to next step either retire or make it active 18:39:52 I just picked "two years" as a random "somewhere way down the line" point, fwiw 18:40:11 dansmith: yeah, similarly why I've been using the "18 months" support window in my comments; it's just a nice point in the future to think about 18:40:32 consider it as two actions: 1. retire the existing openstack/ namespace repos. 2. *if* (and only if) the volunteer is really interested, then create new repositories with copies of the original pre-retirement code in a new namespace in opendev (if that's where they want to work on it) 18:40:39 gmann: if we go with 3, monitoring implies a level of work that would be better invested while mentoring in real time rather than retroactively. 18:41:19 knikolla: monitor the activities is less work as we are doing here and ofcourse anyone can colunteer to mentor there is not restriction in that anytime 18:41:32 *volunteer 18:41:55 fungi: to summarize, your idea is we retire the project from openstack, and the interested contributor can ask to have it re-created elsewhere if they are really interested in maintaining it 18:42:22 let's do that as slaweq going to confirm with volunteer if they are ok with x/ namespace , if yes then it is easy for us otherwise we can see how we can move on this 18:42:26 rosmaita: yes, instead of retiring it in openstack and automatically creating new repositories that they may simply let sit and rot 18:42:38 fungi: that sounds good to me 18:42:44 So with slaweq's permission I suggest we have two specific actions: 18:42:52 also, just to repeat again, please not the x/ namespace, encourage them to pick a new namespace for their repos 18:42:56 if we retire it now, we make the learning curve needed by a new contributor even steeper 18:43:01 1 - slaweq takes an action to reach out privately to the contributor and ask about official openstack vs "fork" 18:43:21 yes 18:43:23 2 - I take an action to summarize this discussion to the mailing list, with a link to this chat log, and see if there's a larger community consensus around the trust/activity issues. 18:43:43 And that'll give us a week to think about it, digest that feedback, and take this up as a dedicated agenda item with more context in a week. 18:43:54 frickler: i wasn't suggesting necessarily retiring now, just saying don't think of it as "moving" to a new namespace, think of it as retiring if that's what's going to happen, don't automatically create more repos on the assumption they'll actually get used 18:44:06 otherwise we're just wasting more resources in our infrastructure 18:44:11 fungi: ++ 18:44:17 fungi: ok, I agree to that 18:44:49 frickler: I agree, and I think it unfortunately is unavoidable for it to be steep. Managing an open source project requires work. We've lowered the bar so much that I don't think it can go any further while we still provide 'official' releases that have any meaning in their officiality. 18:45:12 the natural follow-on to retiring is that interested parties *can* fork the code (in opendev or somewhere else), just don't assume that will happen and prematurely do it for them 18:45:28 fungi: and ask them to do new namespace or so just to make sure they are serious on that instead of setting up for them and then wait if they show up 18:45:35 frickler: I'd also say the 'learning curve' for an abandoned OpenStack project is not comparable to the learning curve for an active one. I hope people are able to see that, as well. 18:45:49 knikolla: well being inactive, we will not release monasca this cycle anyhow 18:46:24 since JayF will be linking to this conversation, i want to go on record as opposing giving a completely new contributor +2 on an openstack code repository 18:46:26 Monasca only gets a release this cycle if we make it active in the next 2 days, which I think is not possible based on our bylaws and how long resolutions have to hold over. 18:46:43 IMO, it is little dangerous to community 'welcome new contributors' effort and may need wider discussion/policy chnages if we want to do that 18:46:44 We have other agenda items, I'm going to timebox any remaining in this discussion to :50 18:47:30 rosmaita: but we did that in past and many time. gave +2 power to new contributors and they successfully maitained the projects/repo 18:47:42 I'm fine with the two proposed ais 18:48:30 spotz: i would love to hear your thoughts with regards to how this might impact perception towards new contributors. 18:48:35 so we have to be careful on both side 1. trust new contributors blindly or 2. do not trust them at all 18:48:47 that is why my suggestion is to give them chance, monitor and then take action 18:48:54 #action slaweq to contact interested Monasca contributor privately to discuss options of OpenStack official vs unofficial governance 18:49:21 #action JayF to raise the larger issues of new contributor trust and project activity, along with this debate chat log, to the mailing list and larger community. 18:49:26 i think the best way to monitor is to let them continue development in the 'x' namespace and show that they have things under control 18:49:36 #action JayF to ensure Monasca has a dedicated agenda item for Jan 16 2024 meeting 18:50:12 for senlin, I will take action to contact eandersson on moving to next step 18:50:13 We have reached the timebox for this topic, and have several additional topics we need to plow through. 18:50:26 #action gmann will contact eandersson privately on next steps for Senlin 18:50:36 #topic Implementation of Unmaintained Branch Statuses 18:50:48 I believe patches are up, and we are in the waiting period now. 18:50:52 Is there any action to take now? 18:51:16 nothing at the moment 18:51:29 #topic TC Charter Updates & OIF Bylaw Changes 18:51:44 These were merged, thank you all for getting your votes placed in a timely fashion. 18:51:57 and thanks to gmann for whipping votes while I was on vacation :) 18:52:09 I don't think there's anything further to discuss here? 18:52:24 yeal, all done from TC side on this. once individual members vote on bylaw changes (during ongoing election) then foundation staff will take next step accordingly. 18:52:37 #topic 2024.1 TC Tracker 18:52:42 thanks everyone on voting/feedback on those and finishing on time 18:52:43 #link https://etherpad.opendev.org/p/tc-2024.1-tracker 18:52:45 Wqqit should be announced as official on Friday 18:52:57 yeah 18:53:14 That's aweomse, thanks :) Sorry for chopping your topic off, trying to get like 5 topics in 10 remaining minutes :D 18:53:31 If there's any update for TC Tracker items, please note them in the etherpad. 18:53:43 #topic TripleO next steps 18:53:50 fungi added this topic 18:53:54 real quick, the release team needs to know how to handle tripleo deliverables for 2024.1 18:53:57 it seems like there are still some repos here in limbo 18:54:03 the tripleo release liaisons aren't responding 18:54:13 and tripleo still has release managed deliverables 18:55:05 if tripleo deliverables won't participate in the 2024.1 release, then the release team needs to know that for sure since we're coming up on the "membership deadline" where they determine which deliverables will be included in the coordinated release 18:55:05 oh, i thought only stable/wallaby they want to keep and rest all derpecated means no release needed 18:55:18 is nuking them off the face of the earth an option? 18:55:21 https://opendev.org/openstack/governance/src/branch/master/reference/projects.yaml#L2784 18:55:21 not all of tripleo's deliverables are stable branch repos 18:55:26 some are master branch only 18:55:32 I see one here with release-management as something other than deprecated 18:55:41 er, a couple, with none 18:55:56 ohk so master repo are needed for stable/wallaby right? 18:56:08 and the tripleo maintainers asked to keep master-branch-only deliverables unretired while they continued relying on them for stable/wallaby support upstream 18:56:19 Even stable/wallaby is retired by that team now 18:56:22 I think their test repo tempest test skip repo or so 18:56:29 per their reply when I asked about unmaintained branch changes 18:56:46 So I think anything remaining is likely retirable, but I'm nervous saying that without seeing a full list. 18:56:49 the consensus from the tc late last year was that with stable/wallaby reaching unmaintained/eol state, the master branch repos could in theory also be retired, yes? 18:57:23 ++, if stable/wallaby going then we can just have no release for master repo and start retirement soon 18:57:25 That's my belief; can we get the full repo list into a change or to a mailing list post just so we can make sure we're approving a specific thing and not just everyone nodding and then someone's CI blows up because we got rid of something we were unaware of? 18:57:32 anyway, the lowest-effort solution for now would be to tell the release managers that they can drop release management of any remaining tripleo deliverables 18:57:48 maybe we can move stable/wallaby status first 18:58:06 so that is will be clear direction on tripleO as complete project 18:58:11 rather than continuing to try to get a response from the tripleo release liaisons who are presumably no longer around or paying attention 18:58:45 fungi: I am +1 to dropping release management from those deliverables, and likely +1 to retiring them as well, but without seeing the specific list it's hard to be 100% certain :D 18:58:49 fungi: is it ok for them to add release-management: None in governance and TC can do retirement or so in own pace 18:58:57 ++ 18:59:13 related, the vmt still sees private reports of suspected security vulnerabilities come in for those tripleo repos (though it's less of a concern since we expressly don't coordinate reports for tripleo and never have) 18:59:22 I can do governance change for release-management for those 18:59:26 so there are people out there who aren't aware that tripleo is dead 18:59:43 gmann: yes, that's what i mean by dropping release management for those 19:00:06 thanks! 19:00:07 cool, I will propose those today and we can reivew 19:00:09 I'm sorry, we've reached time. 19:00:15 Open Discussion will not be happening today. 19:00:17 #endmeeting