17:00:50 <gouthamr> #startmeeting tc 17:00:50 <opendevmeet> Meeting started Tue Aug 26 17:00:50 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:50 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:00:50 <opendevmeet> The meeting name has been set to 'tc' 17:01:10 <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:01:14 <gouthamr> Today's meeting agenda can be found at https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee 17:01:33 <gouthamr> ^ apologies for the gaffe, i am wrapping up a different meeting, with my brain parked there 17:01:42 <gouthamr> #topic Roll Call 17:01:55 <frickler> \o 17:01:58 <gtema> O/ 17:02:07 <jbernard> o/ 17:02:27 <noonedeadpunk> o/ 17:02:47 <mnasiadka> o/ 17:03:41 <gouthamr> courtesy-ping: spotz[m], cardoe, bauzas 17:03:48 <bauzas> o/ 17:03:50 <gouthamr> gmaan will come in late, he told us 17:05:37 <gouthamr> thank you for joining, let's get started.. 17:05:37 <gouthamr> #topic Last Week's AIs 17:05:49 <gouthamr> 1) Follow up on migrating from WSGI scripts to module paths 17:05:55 <gouthamr> #link https://governance.openstack.org/tc/goals/proposed/migrate-from-wsgi-scripts-to-module-paths.html 17:06:48 <gouthamr> i spoke with stephenfin, and he thinks that this is complete without it being a "selected" goal and driving it across the community - "our hand was forced" to get this done during this release 17:07:07 <spotz[m]> \o/ 17:07:10 <cardoe> apologies went long with my boss 17:07:23 <gouthamr> there are some follow up cleanup patches that may be pending, but we don't need to track that here.. i am wondering if we can close it as completed 17:07:38 <gouthamr> any objections to this? 17:07:51 <cardoe> +1 17:07:53 <frickler> +1 to close 17:08:04 <spotz[m]> +1 17:09:02 <gouthamr> perfect, ty, i'll post a patch and get this moved out 17:09:10 <gouthamr> 2) Runtime update 17:09:24 <gouthamr> #link https://review.opendev.org/c/openstack/governance/+/957199 17:09:31 <gouthamr> this was merged, ty for the reviews 17:09:51 <gouthamr> there was a review comment that i'd like to discuss as a separate topic today 17:10:16 <gouthamr> 3) Sync with elodiles on Monasca repository retirement process 17:10:47 <gouthamr> this was partially done, some more discussion happened on the governance patch, and here 17:10:48 <gouthamr> #link https://review.opendev.org/c/openstack/governance/+/953671 17:11:06 <frickler> just one question for the runtime, did someone take the task of amending job templates? 17:11:51 <gouthamr> ah yes, could use a volunteer 17:13:41 <gouthamr> #link https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/941245 17:13:41 <gouthamr> ^ this was from the last one 17:15:06 <gouthamr> i am unfamiliar with the tactic here, we create this patch, but wait until RC1 has passed to merge it? 17:16:17 <frickler> possibly even only when all projects have branched 2025.2, not sure either. probably gmaan knows better 17:16:47 <gouthamr> ty, lets discuss it after the meeting 17:17:06 <gouthamr> #action: follow up on job template changes for the 2026.1 runtime 17:17:18 <frickler> for monasca, there seems to be a tie between people wanting to proceed with the retirement and people wanting to give the new contributor yet another chance to actually get something done. how do we resolve this? 17:17:52 <gmaan> frickler: gouthamr I can propose template today 17:18:02 <gouthamr> ty gmaan 17:18:03 <gtema> declare that those willing to give a chance oblige to take over when this does not work and make a vote 17:19:14 <frickler> gtema: so you want TC members to stand up as fallback maintainers? 17:19:29 <gmaan> that is not fair :) 17:19:39 <gmaan> frickler: gouthamr gtema one more thing to note, as we are in transition to the new TC members, I will suggest to wait for new TC to seat and take decision with new members? 17:19:50 <gtema> i mean those who say they want to give a yet another chance 17:19:56 <gouthamr> we started on the retirement patches, if we abandon them, we can find and re-open them in case the situation doesn't improve.. it's a lot of work, but, the extension of the project's inactive status does not change the existing situation 17:20:02 * bauzas was distracted elsewhere, back here 17:20:03 <gouthamr> i.e., no work for the release team 17:20:05 <gtema> otherwise we are cycling over and over without and end 17:20:06 <gmaan> of course old TC members or any community member can give feedback there in gerrit 17:20:45 <gouthamr> except we have a "perception" problem - i.e., users/operators don't know if the project is well maintained 17:21:10 <gouthamr> besides the page that we have a note regarding the project: 17:21:10 <gouthamr> #link https://governance.openstack.org/tc/reference/emerging-technology-and-inactive-projects.html 17:21:15 <gmaan> seeing no rlelease for many cycle I think it is clear to everyone that it is not maintaioned 17:21:27 <spotz[m]> Why don't we encourage the TC candidates to participate in this? 17:21:36 <gmaan> even they might have not seen the TC doc for inactive projects 17:21:42 <gmaan> spotz[m]: ++ 17:21:49 <gtema> why????? why are we so stubborn to kill off the thing that does not work 17:22:04 <gouthamr> would love it if we could add a doc banner at least as we discussed saying that this project lacks maintainers, and we'd love for folks to join and keep it alive 17:22:08 <gtema> we are so pessimistic to accept new things and 17:22:22 <gtema> we keep died things live as zombies forever 17:22:33 <mnasiadka> gouthamr: I know I forgot to work on something (re: banner) ;-) 17:22:50 <spotz[m]> I think the reluctance to keep things if they at least work is someone might be using it but I'm all for a good scream test:) 17:23:12 <gmaan> not forever but only point of my vote against retirement is we have someone saying I can maintain 17:23:31 <gtema> and then saying - ok, make sense to drop it then 17:23:40 <gouthamr> mnasiadka: ack, that would still be awesome, time permitting 17:23:42 <gmaan> and denying them need some solid reason except it was not maintained by someone else and they also asked the same 17:23:54 <frickler> just noting that that someone is from the same company that didn't make anything except promises over the last years already 17:23:58 <mnasiadka> Well, I'd say we retire - if we new contributor is persistent enough - he'll get a 2026.1 release - and that's the ultimate test of a community around Monasca 17:24:03 <gmaan> if same person asking again and again then it make sense to deny them like we did to prevoius PTL 17:24:45 <gmaan> mnasiadka: exactly. and if we see no activity for this cycle then it is very clear situation for us 17:24:57 <frickler> s/company/organisation/ maybe, not sure about that 17:25:00 <bauzas> I can add my vote in gerrit too 17:25:47 <frickler> mnasiadka: if we retire, there can be no 2026.1 release, not sure what you exactly want 17:25:57 <gmaan> I am not against of retirement but saying let's give more time for a new contribbutor and if no progress we can retire. 17:26:17 <gmaan> there is no harm/time spend on delaying the retirement as project is already inactive so no work for release team or so 17:26:25 <frickler> gmaan: and what if in 6 months the next person with no history in openstack shows up? 17:26:47 <gtema> there is harm - we are wasting our time now and every week talking about that and issues like that 17:26:48 <gmaan> that trend will be rare but if that happens we will see 17:26:51 <frickler> we did say the same thing a year ago already 17:27:04 <bauzas> I don't know why we can't just say 'fork it if you wish and go back to us once this is back in a good shape" ? 17:27:08 <gmaan> that was existing maintainer wanted to maintain 17:27:26 <gtema> still same - fork and do whatever you want 17:27:43 <gmaan> if we consider ' no history in openstack ' then it can apply to any contributor in existing project also, do we deny them alsoi? 17:28:42 <gouthamr> its not unusual to find an operator try to keep a project alive because they use it - they could have contributed to the project in non-tangible ways (reporting bugs, brainstorming features, supporting developers etc) 17:28:50 <clarkb> I don't know what the situatiion is here but it is possible that some people volunteer simply because they think it valuable to us rather than to themselves 17:28:59 <clarkb> which leads to the perpetual problem of no maintenance occurring 17:29:00 <mnasiadka> frickler: it's 2025.1, I'm pretty sure the new contributors (if persistent enough) can reintroduce Monasca? 17:29:11 <mnasiadka> s/2025.1/2025.2 now/ 17:29:13 <clarkb> in situations like that having everyone accept ti isn't a priority anymore is maybe the most productive option 17:29:33 <bauzas> what's the benefits of keeping the monasca repos if we don't run CI jobs on them already ? 17:29:41 <noonedeadpunk> Well, forking somewhere is unrealistic goal tbh 17:29:41 <spotz[m]> I'm for one moer cycle if someone is willing to come in and keep it alive but maybe we put some requirements of finding at least 1(2 would be better) more person to help? 17:29:48 <frickler> if the project is retired, getting it back into openstack governance is a much bigger step then just moving from inactive back to active 17:29:54 <noonedeadpunk> As I can hardly imagine doing the pipeline and CI outside 17:30:05 <noonedeadpunk> which then could be moved back flawlessly 17:30:09 <gmaan> I just want if TC denying volunteer to maintain the inactive projects then we should have a solid reason and follow in consistent way 17:30:10 <bauzas> review.opendev.org/c/openstack/project-config/+/957063/5/zuul.d/projects.yaml 17:30:30 <noonedeadpunk> As you can spend couple of weeks just to re-establish some level of CI with github actions 17:30:39 <bauzas> there are very little number of jobs, right ? 17:30:41 <noonedeadpunk> or it can be even impossible in some cases 17:30:52 <clarkb> noonedeadpunk: they can still use opendev 17:30:52 <gmaan> maybe documenting some process/practice for the same can help otherwise we can be projected as fair/unfair in different cases 17:30:53 <noonedeadpunk> but then you'd need to move things back 17:31:02 <clarkb> noonedeadpunk: I think that is a non issue 17:31:04 <bauzas> noonedeadpunk: surely, a fork can be painful, but again, look at what's currently tested 17:31:05 <gouthamr> bauzas: ^ that can be reverted, this latest discussion is a hydraulic brake pulling on the ongoing retirement 17:31:54 <noonedeadpunk> clarkb: you mean `x`? or get their org? 17:32:05 <clarkb> noonedeadpunk: a new org probably 17:32:11 * gouthamr s/hydraulic brake/jake brake 17:32:24 * noonedeadpunk needs to read what it takes to get org onto opendev 17:32:34 <clarkb> we're trying t oavoid using x/. It was a catch all for people who weren't engaged in the renaming process but if someone is actively forking an openstack project then they should use something that makse sense for that effort 17:32:40 <mnasiadka> Well, if we want to give them (or him) another chance - we should surely do the "inactive banner on top of inactive project docs page" thing - but I have a feeling if the project is inactive since 2024.1, then it's a huge amount of work to get that project up and running again 17:32:51 <bauzas> again, tell me which jobs monasca is currently running, except publishing to pypi, which can eastly be done with a GH Action 17:33:09 <mnasiadka> And if the volunteer disappears soon - then we'll be discussing the same thing again 17:33:32 <gmaan> we can easly know that after 1-2 month from now 17:33:41 <noonedeadpunk> mnasiadka: since 2024.1 is not that long.... 17:34:00 <gmaan> that is why my point is to give chnace to them but wiht timeline and see progress activly 17:34:21 <noonedeadpunk> bauzas: I'm not sure about specifics, but more about general approach we are suggesting and a precedent 17:34:43 <noonedeadpunk> I'd be expecting some tempest/devstack jobs being there, but I have not checked if they're actually there 17:34:57 <bauzas> nope, there aren't 17:35:04 <mnasiadka> noonedeadpunk: last release was 2023.2, so if anybody is using it, they need to be on EOL or unmaintained version of OpenStack, I'm pretty sure it's more than weeks worth of work 17:35:27 <gmaan> we have tempest jobs but not sure about their status 17:35:33 <gmaan> #link no history in openstack 17:35:40 <gmaan> #link https://github.com/openstack/monasca-api/blob/master/.zuul.yaml 17:35:49 <noonedeadpunk> bauzas: there's horizon integration thing for instance: https://opendev.org/openstack/monasca-ui/src/branch/master/.zuul.yaml#L4-L5 17:35:58 <bauzas> clarkb: would that be easier for a project to come back to the namespace if it were having a new name or is it the same ? 17:36:43 <noonedeadpunk> there're tempest jobs: https://opendev.org/openstack/monasca-api/src/branch/master/.zuul.yaml#L209-L210 17:36:55 <bauzas> I don't see those run in check or gatre 17:36:55 <clarkb> bauzas: I think the openstack rules aer openstack/monasca gets retired then you can fork into say foo/monasca. If you go back to openstack/monasca its probably a force push to update the git tree without reviewing every change 17:37:21 <clarkb> I don't think the name chosen impacts that. Its an artifact of keeping the openstack/monasca repo around in a retired state 17:37:38 <bauzas> there are jobs definitions indeed, but nothing runs them AFAICS 17:38:02 <bauzas> clarkb: I see, thanks 17:38:04 <noonedeadpunk> tempest is obviously in gates.... another question is that it did not have any patches, so it was likely not triggered in a while 17:39:39 <gouthamr> we don't have a ton of time, we've spent quite a bit arguing this 17:40:02 <noonedeadpunk> hm... and what is that? https://docs.opendev.org/opendev/system-config/latest/unofficial_project_hosting.html 17:40:54 <noonedeadpunk> so.. .can we just mark monasca as unofficial project? 17:41:09 <spotz[m]> Interesting thought 17:41:22 <gouthamr> i do think there are merits to both sides of the argument - so democratizing this on gerrit is probably the way to go.. at this point, unless there are a lot of +1s, we'd not abandon the governance change.. we don't lose anything delaying this by a few weeks to allow that discussion/consensus to happen 17:42:05 <mnasiadka> noonedeadpunk: but then it needs to go into it's own namespace, from what I understand 17:42:23 <gouthamr> an unofficial project would just be "monasca/<repo-name>" -- except there's a concern taht no maintenance would happen there too.. it'd just silently fall off our radar 17:42:32 <bauzas> noonedeadpunk: my bad indeed, there are a couple of tempests tests that can be triggered, so there is a value indeed to keep it run by Zuul 17:43:00 <gmaan> yes what mnasiadka mentioned, it cannot stay in openstack/ namespace 17:43:06 <bauzas> but yeah, then, let's not say 'fork it to GH', just say "put it into your own namespace" 17:43:14 <gouthamr> sorry, lets discuss further on the governance change please, or in a dedicated topic next week 17:43:39 <gouthamr> we had another AI on finding out the impact of OIF membership renewal on the electorate 17:43:51 <noonedeadpunk> gmaan: why it can't as unofficial project? 17:44:09 <gouthamr> noonedeadpunk: lets move on.. 17:44:13 <noonedeadpunk> ++ 17:44:31 <gouthamr> i caught some discussion on irc wrt this 17:44:55 <gouthamr> i don't know if we're willing to share this yet, or we're still trying to address OIF website/API concerns 17:45:13 <gmaan> noonedeadpunk: no, in openstack/ namespace only official project can stay. that is one of the TC resolution in past 17:45:35 <gmaan> #link https://governance.openstack.org/tc/resolutions/20190322-namespace-unofficial-projects.html 17:45:56 <frickler> gouthamr: iiuc the OIF database issues should be fixed since some hours ago 17:46:02 <gouthamr> ah! 17:46:35 <gouthamr> okay, is there anything to discuss here then? or we can catch up with slaweq/ianychoi - we have ~1 day before polling begins 17:46:45 <frickler> but the question how many potential electors are blocked but not being renewed OIF member is difficult still iiuc 17:46:52 <frickler> s/but/by/ 17:46:56 <noonedeadpunk> gmaan: then we should update the doc. But also - was this namespace created? 17:47:12 <gouthamr> yeah, it feels like a massive unintended disenfranchisement :( 17:47:18 <noonedeadpunk> as seems it was never executed completely 17:47:37 <spotz[m]> I know there's governance about the 180 days for board governance but does TC/PTL electionshave that lead time? 17:47:46 <gouthamr> we didn't.. 17:47:51 <frickler> spotz[m]: not as implemented 17:48:19 <spotz[m]> So we could maybe put out all the messages to try to get folks to renew in the next few days? 17:48:28 <frickler> noonedeadpunk: x/ was created for those repos that were moved at the time. it is no longer open for moves today 17:48:58 <spotz[m]> I know we can't fix the fact folks don't read the messages, but maybe they didn't care about the board elections but do TC/PTL and didn't realize 17:49:09 <frickler> spotz[m]: iiuc the rolls were created today, you'd need to talk with ianychoi and slaweq whether they still want to update 17:49:29 <frickler> and if the elections are to start tomorrow, not much time to react anyway 17:49:44 <spotz[m]> yeah 17:49:45 <gouthamr> we could attempt to do something, my proposal is that we email blast existing members reminding them to renew their memberships, and we pull the diff in 15 days and re-send ballots 17:49:45 <gouthamr> this will be extraordinary, but, i hate the aspect that we'd not let folks a chance to fix this 17:50:03 <gouthamr> we had one or two emails about this, and probably buried in peoples' mailboxes/forgotten 17:50:17 <frickler> changing the electorate while the election is in progress sounds very questionable to me 17:50:34 <gouthamr> you mean we'll pick up new members? 17:51:19 <frickler> well the current state is that "existing" members are only ones that renewed their membership. only those are included in the electorate rolls 17:51:40 <gouthamr> we don't have their original date of joining the erstwhile foundation? 17:52:21 <frickler> I don't think that that is exposed via the API, so "we" as TC or election officials don't, afaict 17:52:28 <gouthamr> ah 17:53:05 <frickler> maybe clarkb or fungi know better? 17:53:22 <gouthamr> sigh, so i'd like us to all be aware of the situation.. i'll ask that slaweq/ianychoi share the current electorate statistics here or in the ML 17:53:31 <clarkb> I'm not sure I undersatnd the question. Whether they joined the old foundation is no longer relevant is it? 17:53:46 <clarkb> I'm not a bylaws expert so may be mistaken on that front 17:53:52 <frickler> they did in the election channel: 171 for TC and 21 for horizon 17:54:07 <gouthamr> ack, the comparison? 17:54:34 <frickler> clarkb: the question is how many more contributors would be in the electorate if they had pressed the "renew" button 17:54:36 <spotz[m]> 171 for TC!!!! EEEp 17:55:27 <frickler> that's up from 160 after the database issues 17:55:57 <clarkb> frickler: I think to answer that we'd need a list of all the contributors for the cycles that make you an elector then we'd have to ask the foundation membership folks if they are able to cross check against an old back up of the db (or maybe the current db contains sufficient info to check I don't know) 17:56:10 <clarkb> but you should know how many electors you had in previous elections 17:56:31 <frickler> last TC election (2-3 cycles ago iirc) had about 250 17:56:32 <spotz[m]> The rolls should be around somewhere 17:56:36 <clarkb> comparing to those elector sets won't tell you a complete picture as it won't include new contributors but should give you a sense of the scale of the problem 17:57:14 <clarkb> but importantly I'm not sure what the answer to these questions changes 17:57:18 <clarkb> would you suspend elections? 17:57:39 <clarkb> if you aren't going to change the election process then does it matter beyond doing what we're already doing encouraging people to rejoin etc 17:57:40 <frickler> likely it is too late for that anyway, yes 17:57:41 <gouthamr> no - the proposal was to remind people to "renew" and send them ballots 17:57:50 <clarkb> gouthamr: right and you can do that regardless I think 17:58:16 <gouthamr> we freeze our electorate a couple days before the polling though 17:58:22 <frickler> IMHO it is too late for that now, too, yes 17:58:48 <gouthamr> time-check: 2 minutes 17:58:48 <gouthamr> it feels like we had a ton to discuss today, and we'll have to unfortunately slide some topics to next week.. 17:58:48 <gouthamr> jbernard : how time critical is the phone-home topic? 17:59:00 <gouthamr> clarkb: https://governance.openstack.org/election/#id6 17:59:09 <jbernard> for cinder, fairly high 17:59:15 <jbernard> but i can be quick if we have only a minute or two 17:59:36 <gouthamr> ^ any objections to continue that discussion beyond this meeting? 17:59:49 <spotz[m]> Go for it 18:00:00 <jbernard> Summary: 18:00:02 <jbernard> * IBM would like to merge a phone-home patch, enabled by default 18:00:04 <jbernard> * I am willing to allow it to merge, but /not/ enabled by default 18:00:06 <jbernard> * IBM/Vivek state that it is critical for the flamingo release in its current state 18:00:08 <jbernard> * As PTL I'm willing to be the tie breaker, but I'm not certain that we actually have a tie at the moment. 18:00:12 <jbernard> URLs for context: 18:00:14 <jbernard> * the patch: 18:00:16 <jbernard> #link https://review.opendev.org/c/openstack/cinder/+/951829 18:00:18 <jbernard> * my and brian's response: #link 18:00:20 <jbernard> https://review.opendev.org/c/openstack/cinder/+/951829/18..29/cinder/volume/drivers/ibm/storwize_svc/storwize_svc_common.py#b3708 18:00:22 <jbernard> * the resulting ml thread: #link 18:00:24 <jbernard> https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/TB36DJJVKJ2YC3MVLBYI5MDBDMYNELAD/#46ER3KCYB4V3POETAEUYZHER4LUTCYNY 18:00:26 <jbernard> * the last discussion in cinder's meeting last week: #link 18:00:28 <jbernard> https://meetings.opendev.org/meetings/cinder/2025/cinder.2025-08-20-14.06.log.html#l-69 18:00:43 <jbernard> My request: I would like to have a consensus position from the TC on this issue, if possible. 18:01:15 <frickler> +1 to "/not/ enabled by default" if only for publicity reasons. but we'll likely need a resolution to make a formal TC statement? 18:01:46 <spotz[m]> Without having to read everything in the sake of time. Why can't it be disabled and then doc turning it on to not break everyone? 18:01:57 <spotz[m]> docs... 18:02:05 <jbernard> i have suggested that 18:02:10 <jbernard> and that is what I would recommend 18:02:11 <gouthamr> my view is that, the phone home itself isn't happening from OpenStack.. The driver is collecting information from OpenStack and giving it to an external storage system which handles phoning home.. 18:02:11 <gouthamr> i think i wouldn't want any on-by-default phone home logic in OpenStack 18:02:36 <jbernard> yes, that is technically true 18:03:02 <gouthamr> but, operators need to ensure their storage system isn't phoning home by default, or have a way to turn it off 18:03:46 <jbernard> the issue for me, once data leaves our codebase we can't ever undo that, i dont like that it happens by default 18:03:53 <gouthamr> its sketchy, but, collecting environment issue for triage/data collection doesn't seem to be harmful to me.. 18:04:06 <jbernard> regardless of exactly where it's temporarily stored 18:04:11 <gouthamr> sketchy = the part that this is explicitly called "phone home" in openstack 18:04:22 <frickler> giving data to an external system is kind of like "phone home" already 18:04:35 <mnasiadka> Well, the os version they'll get might be not useful at all, in most cases it's going to come from a container image 18:04:42 <gouthamr> yes, and that happens all over the place - whether we call it phone home or not 18:05:02 <bauzas> not sure I'm getting the whole context correctly 18:05:32 * frickler needs to leave for now 18:05:46 <gouthamr> yeah, let me wrap up the meeting.. please don't let that stop the discussion 18:05:57 <bauzas> but I think I understand the security concern 18:06:02 <gouthamr> i will compile the conversation so we can have an informed decision, jbernard 18:06:06 <mnasiadka> But I agree that should be optional 18:06:09 <gouthamr> thank you all for attending 18:06:14 <gouthamr> #endmeeting