| opendevreview | Merged openstack/governance master: Define testing runtime for 2026.1 release https://review.opendev.org/c/openstack/governance/+/957199 | 05:43 |
|---|---|---|
| mnasiadka | frickler: has the situation in requirements improved? I'm happy to help if I'm able to | 12:02 |
| frickler | mnasiadka: well the two DPLs -1d the "drop DPL" change, but I haven't seen any other action from them, like actual reviews. I myself have stopped reviewing reqs changes or dealing with the weekly bot updates for now. feel free to talk to them on how you can help if you want to | 12:23 |
| frickler | priteau: not sure if you read backlog, can you please tell us whether you did any update to your OIF account since your PTL nomination was merged last week? | 12:49 |
| mnasiadka | frickler: ok, so we're just waiting for disaster ;-) | 12:54 |
| priteau | frickler: I don't recall having made any changes in the past few days. I did the reestablishment process for OpenInfra but that was in July. | 13:33 |
| priteau | I logged into openinfra.org yesterday I think, don't know if it could have triggered a change | 13:35 |
| fungi | priteau: it was a bug of some kind in the member database system, supposedly fixed in the past few hours | 13:47 |
| frickler | mnasiadka: same as it ever was? ;) | 14:04 |
| clarkb | priteau: yes, sounds like there was a bug in a logic check during login to openstack.org (maybe openinfra.org too? Not sure the exact locations) that would reset foundation membership. They found the bug and corrected it then were also able to inspect the db records to find individuals in this situation and corrected the db records as well | 15:05 |
| clarkb | so at this point all should be well and you don't need to do anything | 15:05 |
| clarkb | I queried the api results for you and I see what appears to be correct data now as well | 15:06 |
| gouthamr | tc-members: a gentle reminder that we'll have our weekly meeting here in ~57 minutes | 16:03 |
| gouthamr | The agenda is https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee | 16:03 |
| gmaan | gouthamr: I might be 15-20 min late in today meeting. | 16:38 |
| gouthamr | gmaan: ack, ty for letting me know | 16:44 |
| gouthamr | #startmeeting manila | 17:00 |
| opendevmeet | Meeting started Tue Aug 26 17:00:28 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 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 17:00 |
| opendevmeet | The meeting name has been set to 'manila' | 17:00 |
| noonedeadpunk | um | 17:00 |
| gouthamr | :D | 17:00 |
| frickler | gouthamr: nope ;) | 17:00 |
| gouthamr | #endmeeting | 17:00 |
| opendevmeet | Meeting ended Tue Aug 26 17:00:46 2025 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 17:00 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/manila/2025/manila.2025-08-26-17.00.html | 17:00 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/manila/2025/manila.2025-08-26-17.00.txt | 17:00 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/manila/2025/manila.2025-08-26-17.00.log.html | 17:00 |
| gouthamr | #startmeeting tc | 17:00 |
| 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 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 17:00 |
| opendevmeet | The meeting name has been set to 'tc' | 17:00 |
| 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 |
| gouthamr | Today's meeting agenda can be found at https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee | 17:01 |
| gouthamr | ^ apologies for the gaffe, i am wrapping up a different meeting, with my brain parked there | 17:01 |
| gouthamr | #topic Roll Call | 17:01 |
| frickler | \o | 17:01 |
| gtema | O/ | 17:01 |
| jbernard | o/ | 17:02 |
| noonedeadpunk | o/ | 17:02 |
| mnasiadka | o/ | 17:02 |
| gouthamr | courtesy-ping: spotz[m], cardoe, bauzas | 17:03 |
| bauzas | o/ | 17:03 |
| gouthamr | gmaan will come in late, he told us | 17:03 |
| gouthamr | thank you for joining, let's get started.. | 17:05 |
| gouthamr | #topic Last Week's AIs | 17:05 |
| gouthamr | 1) Follow up on migrating from WSGI scripts to module paths | 17:05 |
| gouthamr | #link https://governance.openstack.org/tc/goals/proposed/migrate-from-wsgi-scripts-to-module-paths.html | 17:05 |
| 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:06 |
| spotz[m] | \o/ | 17:07 |
| cardoe | apologies went long with my boss | 17:07 |
| 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 |
| gouthamr | any objections to this? | 17:07 |
| cardoe | +1 | 17:07 |
| frickler | +1 to close | 17:07 |
| spotz[m] | +1 | 17:08 |
| gouthamr | perfect, ty, i'll post a patch and get this moved out | 17:09 |
| gouthamr | 2) Runtime update | 17:09 |
| gouthamr | #link https://review.opendev.org/c/openstack/governance/+/957199 | 17:09 |
| gouthamr | this was merged, ty for the reviews | 17:09 |
| gouthamr | there was a review comment that i'd like to discuss as a separate topic today | 17:09 |
| gouthamr | 3) Sync with elodiles on Monasca repository retirement process | 17:10 |
| gouthamr | this was partially done, some more discussion happened on the governance patch, and here | 17:10 |
| gouthamr | #link https://review.opendev.org/c/openstack/governance/+/953671 | 17:10 |
| frickler | just one question for the runtime, did someone take the task of amending job templates? | 17:11 |
| gouthamr | ah yes, could use a volunteer | 17:11 |
| gouthamr | #link https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/941245 | 17:13 |
| gouthamr | ^ this was from the last one | 17:13 |
| gouthamr | i am unfamiliar with the tactic here, we create this patch, but wait until RC1 has passed to merge it? | 17:15 |
| frickler | possibly even only when all projects have branched 2025.2, not sure either. probably gmaan knows better | 17:16 |
| gouthamr | ty, lets discuss it after the meeting | 17:16 |
| gouthamr | #action: follow up on job template changes for the 2026.1 runtime | 17:17 |
| 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 |
| gmaan | frickler: gouthamr I can propose template today | 17:17 |
| gouthamr | ty gmaan | 17:18 |
| gtema | declare that those willing to give a chance oblige to take over when this does not work and make a vote | 17:18 |
| frickler | gtema: so you want TC members to stand up as fallback maintainers? | 17:19 |
| gmaan | that is not fair :) | 17:19 |
| 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 |
| gtema | i mean those who say they want to give a yet another chance | 17:19 |
| 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:19 |
| * bauzas was distracted elsewhere, back here | 17:20 | |
| gouthamr | i.e., no work for the release team | 17:20 |
| gtema | otherwise we are cycling over and over without and end | 17:20 |
| gmaan | of course old TC members or any community member can give feedback there in gerrit | 17:20 |
| gouthamr | except we have a "perception" problem - i.e., users/operators don't know if the project is well maintained | 17:20 |
| gouthamr | besides the page that we have a note regarding the project: | 17:21 |
| gouthamr | #link https://governance.openstack.org/tc/reference/emerging-technology-and-inactive-projects.html | 17:21 |
| gmaan | seeing no rlelease for many cycle I think it is clear to everyone that it is not maintaioned | 17:21 |
| spotz[m] | Why don't we encourage the TC candidates to participate in this? | 17:21 |
| gmaan | even they might have not seen the TC doc for inactive projects | 17:21 |
| gmaan | spotz[m]: ++ | 17:21 |
| gtema | why????? why are we so stubborn to kill off the thing that does not work | 17:21 |
| 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 |
| gtema | we are so pessimistic to accept new things and | 17:22 |
| gtema | we keep died things live as zombies forever | 17:22 |
| mnasiadka | gouthamr: I know I forgot to work on something (re: banner) ;-) | 17:22 |
| 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:22 |
| gmaan | not forever but only point of my vote against retirement is we have someone saying I can maintain | 17:23 |
| gtema | and then saying - ok, make sense to drop it then | 17:23 |
| gouthamr | mnasiadka: ack, that would still be awesome, time permitting | 17:23 |
| gmaan | and denying them need some solid reason except it was not maintained by someone else and they also asked the same | 17:23 |
| 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 |
| 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:23 |
| gmaan | if same person asking again and again then it make sense to deny them like we did to prevoius PTL | 17:24 |
| gmaan | mnasiadka: exactly. and if we see no activity for this cycle then it is very clear situation for us | 17:24 |
| frickler | s/company/organisation/ maybe, not sure about that | 17:24 |
| bauzas | I can add my vote in gerrit too | 17:25 |
| frickler | mnasiadka: if we retire, there can be no 2026.1 release, not sure what you exactly want | 17:25 |
| 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:25 |
| 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 |
| frickler | gmaan: and what if in 6 months the next person with no history in openstack shows up? | 17:26 |
| gtema | there is harm - we are wasting our time now and every week talking about that and issues like that | 17:26 |
| gmaan | that trend will be rare but if that happens we will see | 17:26 |
| frickler | we did say the same thing a year ago already | 17:26 |
| 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 |
| gmaan | that was existing maintainer wanted to maintain | 17:27 |
| gtema | still same - fork and do whatever you want | 17:27 |
| 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:27 |
| 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 |
| 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 |
| clarkb | which leads to the perpetual problem of no maintenance occurring | 17:28 |
| mnasiadka | frickler: it's 2025.1, I'm pretty sure the new contributors (if persistent enough) can reintroduce Monasca? | 17:29 |
| mnasiadka | s/2025.1/2025.2 now/ | 17:29 |
| clarkb | in situations like that having everyone accept ti isn't a priority anymore is maybe the most productive option | 17:29 |
| bauzas | what's the benefits of keeping the monasca repos if we don't run CI jobs on them already ? | 17:29 |
| noonedeadpunk | Well, forking somewhere is unrealistic goal tbh | 17:29 |
| 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 |
| 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 |
| noonedeadpunk | As I can hardly imagine doing the pipeline and CI outside | 17:29 |
| noonedeadpunk | which then could be moved back flawlessly | 17:30 |
| 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 |
| bauzas | review.opendev.org/c/openstack/project-config/+/957063/5/zuul.d/projects.yaml | 17:30 |
| noonedeadpunk | As you can spend couple of weeks just to re-establish some level of CI with github actions | 17:30 |
| bauzas | there are very little number of jobs, right ? | 17:30 |
| noonedeadpunk | or it can be even impossible in some cases | 17:30 |
| clarkb | noonedeadpunk: they can still use opendev | 17:30 |
| gmaan | maybe documenting some process/practice for the same can help otherwise we can be projected as fair/unfair in different cases | 17:30 |
| noonedeadpunk | but then you'd need to move things back | 17:30 |
| clarkb | noonedeadpunk: I think that is a non issue | 17:31 |
| bauzas | noonedeadpunk: surely, a fork can be painful, but again, look at what's currently tested | 17:31 |
| gouthamr | bauzas: ^ that can be reverted, this latest discussion is a hydraulic brake pulling on the ongoing retirement | 17:31 |
| noonedeadpunk | clarkb: you mean `x`? or get their org? | 17:31 |
| clarkb | noonedeadpunk: a new org probably | 17:32 |
| * gouthamr s/hydraulic brake/jake brake | 17:32 | |
| * noonedeadpunk needs to read what it takes to get org onto opendev | 17:32 | |
| 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 |
| 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 |
| bauzas | again, tell me which jobs monasca is currently running, except publishing to pypi, which can eastly be done with a GH Action | 17:32 |
| mnasiadka | And if the volunteer disappears soon - then we'll be discussing the same thing again | 17:33 |
| gmaan | we can easly know that after 1-2 month from now | 17:33 |
| noonedeadpunk | mnasiadka: since 2024.1 is not that long.... | 17:33 |
| gmaan | that is why my point is to give chnace to them but wiht timeline and see progress activly | 17:34 |
| noonedeadpunk | bauzas: I'm not sure about specifics, but more about general approach we are suggesting and a precedent | 17:34 |
| noonedeadpunk | I'd be expecting some tempest/devstack jobs being there, but I have not checked if they're actually there | 17:34 |
| bauzas | nope, there aren't | 17:34 |
| 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 |
| gmaan | we have tempest jobs but not sure about their status | 17:35 |
| gmaan | #link no history in openstack | 17:35 |
| gmaan | #link https://github.com/openstack/monasca-api/blob/master/.zuul.yaml | 17:35 |
| noonedeadpunk | bauzas: there's horizon integration thing for instance: https://opendev.org/openstack/monasca-ui/src/branch/master/.zuul.yaml#L4-L5 | 17:35 |
| 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:35 |
| noonedeadpunk | there're tempest jobs: https://opendev.org/openstack/monasca-api/src/branch/master/.zuul.yaml#L209-L210 | 17:36 |
| bauzas | I don't see those run in check or gatre | 17:36 |
| 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:36 |
| 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 |
| bauzas | there are jobs definitions indeed, but nothing runs them AFAICS | 17:37 |
| bauzas | clarkb: I see, thanks | 17:38 |
| 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:38 |
| gouthamr | we don't have a ton of time, we've spent quite a bit arguing this | 17:39 |
| noonedeadpunk | hm... and what is that? https://docs.opendev.org/opendev/system-config/latest/unofficial_project_hosting.html | 17:40 |
| noonedeadpunk | so.. .can we just mark monasca as unofficial project? | 17:40 |
| spotz[m] | Interesting thought | 17:41 |
| 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:41 |
| mnasiadka | noonedeadpunk: but then it needs to go into it's own namespace, from what I understand | 17:42 |
| 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 |
| 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:42 |
| gmaan | yes what mnasiadka mentioned, it cannot stay in openstack/ namespace | 17:43 |
| bauzas | but yeah, then, let's not say 'fork it to GH', just say "put it into your own namespace" | 17:43 |
| gouthamr | sorry, lets discuss further on the governance change please, or in a dedicated topic next week | 17:43 |
| gouthamr | we had another AI on finding out the impact of OIF membership renewal on the electorate | 17:43 |
| noonedeadpunk | gmaan: why it can't as unofficial project? | 17:43 |
| gouthamr | noonedeadpunk: lets move on.. | 17:44 |
| noonedeadpunk | ++ | 17:44 |
| gouthamr | i caught some discussion on irc wrt this | 17:44 |
| 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:44 |
| gmaan | noonedeadpunk: no, in openstack/ namespace only official project can stay. that is one of the TC resolution in past | 17:45 |
| gmaan | #link https://governance.openstack.org/tc/resolutions/20190322-namespace-unofficial-projects.html | 17:45 |
| frickler | gouthamr: iiuc the OIF database issues should be fixed since some hours ago | 17:45 |
| gouthamr | ah! | 17:46 |
| 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 |
| frickler | but the question how many potential electors are blocked but not being renewed OIF member is difficult still iiuc | 17:46 |
| frickler | s/but/by/ | 17:46 |
| noonedeadpunk | gmaan: then we should update the doc. But also - was this namespace created? | 17:46 |
| gouthamr | yeah, it feels like a massive unintended disenfranchisement :( | 17:47 |
| noonedeadpunk | as seems it was never executed completely | 17:47 |
| spotz[m] | I know there's governance about the 180 days for board governance but does TC/PTL electionshave that lead time? | 17:47 |
| gouthamr | we didn't.. | 17:47 |
| frickler | spotz[m]: not as implemented | 17:47 |
| 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 |
| frickler | noonedeadpunk: x/ was created for those repos that were moved at the time. it is no longer open for moves today | 17:48 |
| 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:48 |
| 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 |
| frickler | and if the elections are to start tomorrow, not much time to react anyway | 17:49 |
| spotz[m] | yeah | 17:49 |
| 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 |
| gouthamr | this will be extraordinary, but, i hate the aspect that we'd not let folks a chance to fix this | 17:49 |
| gouthamr | we had one or two emails about this, and probably buried in peoples' mailboxes/forgotten | 17:50 |
| frickler | changing the electorate while the election is in progress sounds very questionable to me | 17:50 |
| gouthamr | you mean we'll pick up new members? | 17:50 |
| 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 |
| gouthamr | we don't have their original date of joining the erstwhile foundation? | 17:51 |
| frickler | I don't think that that is exposed via the API, so "we" as TC or election officials don't, afaict | 17:52 |
| gouthamr | ah | 17:52 |
| frickler | maybe clarkb or fungi know better? | 17:53 |
| 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 |
| clarkb | I'm not sure I undersatnd the question. Whether they joined the old foundation is no longer relevant is it? | 17:53 |
| clarkb | I'm not a bylaws expert so may be mistaken on that front | 17:53 |
| frickler | they did in the election channel: 171 for TC and 21 for horizon | 17:53 |
| gouthamr | ack, the comparison? | 17:54 |
| frickler | clarkb: the question is how many more contributors would be in the electorate if they had pressed the "renew" button | 17:54 |
| spotz[m] | 171 for TC!!!! EEEp | 17:54 |
| frickler | that's up from 160 after the database issues | 17:55 |
| 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:55 |
| clarkb | but you should know how many electors you had in previous elections | 17:56 |
| frickler | last TC election (2-3 cycles ago iirc) had about 250 | 17:56 |
| spotz[m] | The rolls should be around somewhere | 17:56 |
| 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:56 |
| clarkb | but importantly I'm not sure what the answer to these questions changes | 17:57 |
| clarkb | would you suspend elections? | 17:57 |
| 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 |
| frickler | likely it is too late for that anyway, yes | 17:57 |
| gouthamr | no - the proposal was to remind people to "renew" and send them ballots | 17:57 |
| clarkb | gouthamr: right and you can do that regardless I think | 17:57 |
| gouthamr | we freeze our electorate a couple days before the polling though | 17:58 |
| frickler | IMHO it is too late for that now, too, yes | 17:58 |
| gouthamr | time-check: 2 minutes | 17:58 |
| 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 |
| gouthamr | jbernard : how time critical is the phone-home topic? | 17:58 |
| gouthamr | clarkb: https://governance.openstack.org/election/#id6 | 17:59 |
| jbernard | for cinder, fairly high | 17:59 |
| jbernard | but i can be quick if we have only a minute or two | 17:59 |
| gouthamr | ^ any objections to continue that discussion beyond this meeting? | 17:59 |
| spotz[m] | Go for it | 17:59 |
| jbernard | Summary: | 18:00 |
| jbernard | * IBM would like to merge a phone-home patch, enabled by default | 18:00 |
| jbernard | * I am willing to allow it to merge, but /not/ enabled by default | 18:00 |
| jbernard | * IBM/Vivek state that it is critical for the flamingo release in its current state | 18:00 |
| 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 |
| jbernard | URLs for context: | 18:00 |
| jbernard | * the patch: | 18:00 |
| jbernard | #link https://review.opendev.org/c/openstack/cinder/+/951829 | 18:00 |
| jbernard | * my and brian's response: #link | 18:00 |
| jbernard | https://review.opendev.org/c/openstack/cinder/+/951829/18..29/cinder/volume/drivers/ibm/storwize_svc/storwize_svc_common.py#b3708 | 18:00 |
| jbernard | * the resulting ml thread: #link | 18:00 |
| jbernard | https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/TB36DJJVKJ2YC3MVLBYI5MDBDMYNELAD/#46ER3KCYB4V3POETAEUYZHER4LUTCYNY | 18:00 |
| jbernard | * the last discussion in cinder's meeting last week: #link | 18:00 |
| jbernard | https://meetings.opendev.org/meetings/cinder/2025/cinder.2025-08-20-14.06.log.html#l-69 | 18:00 |
| jbernard | My request: I would like to have a consensus position from the TC on this issue, if possible. | 18:00 |
| 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 |
| 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 |
| spotz[m] | docs... | 18:01 |
| jbernard | i have suggested that | 18:02 |
| jbernard | and that is what I would recommend | 18:02 |
| 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 |
| gouthamr | i think i wouldn't want any on-by-default phone home logic in OpenStack | 18:02 |
| jbernard | yes, that is technically true | 18: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 |
| 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 |
| gouthamr | its sketchy, but, collecting environment issue for triage/data collection doesn't seem to be harmful to me.. | 18:03 |
| jbernard | regardless of exactly where it's temporarily stored | 18:04 |
| gouthamr | sketchy = the part that this is explicitly called "phone home" in openstack | 18:04 |
| frickler | giving data to an external system is kind of like "phone home" already | 18:04 |
| 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 |
| gouthamr | yes, and that happens all over the place - whether we call it phone home or not | 18:04 |
| bauzas | not sure I'm getting the whole context correctly | 18:05 |
| * frickler needs to leave for now | 18:05 | |
| gouthamr | yeah, let me wrap up the meeting.. please don't let that stop the discussion | 18:05 |
| bauzas | but I think I understand the security concern | 18:05 |
| gouthamr | i will compile the conversation so we can have an informed decision, jbernard | 18:06 |
| mnasiadka | But I agree that should be optional | 18:06 |
| gouthamr | thank you all for attending | 18:06 |
| gouthamr | #endmeeting | 18:06 |
| opendevmeet | Meeting ended Tue Aug 26 18:06:14 2025 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 18:06 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/tc/2025/tc.2025-08-26-17.00.html | 18:06 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/tc/2025/tc.2025-08-26-17.00.txt | 18:06 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/tc/2025/tc.2025-08-26-17.00.log.html | 18:06 |
| bauzas | and fwiw, nova never accepted scheduler filters or any other plugins that would call external APIsd | 18:06 |
| jbernard | thanks, im here to answer questions | 18:06 |
| bauzas | for multiple reasons, one indeed being security | 18:06 |
| gouthamr | bauzas: not sure we can draw a comparison to "external storage systems" which cinder/manila are capable of handling | 18:07 |
| bauzas | so I second your concern and I honestly think this isn't a reasonable workflow | 18:07 |
| bauzas | gouthamr: usually cinder/manila storage drivers are /providing/ information to Cinder, right? | 18:07 |
| bauzas | not the other way, correct? | 18:08 |
| gouthamr | and the other way around | 18:08 |
| gouthamr | in the imperative sense mostly, but, like rosmaita's linked - drivers can have mechanisms on hooks to do things based on non-user-initiated actions in OpenStack | 18:09 |
| gmaan | noonedeadpunk: re: namespace. main goal for TC was to move out all unofficial projects/deliverables out of openstack/ namespace. I know, I cleanedup a lot of (~100) repo during that. what new namespace they can go was out of scope for TC. | 18:09 |
| gouthamr | jbernard: is the author okay with turning it off by default | 18:09 |
| jbernard | no | 18:10 |
| jbernard | they insist that it needs to be enabled by default | 18:10 |
| gouthamr | the core team and PTL certainly have a right to seek that; the TC can only advise what you do with internal logic like this imho | 18:10 |
| jbernard | if it's up to me, im going to disallow enabled-by-default | 18:10 |
| jbernard | but i wanted to check here before I make a statement on this particular issue | 18:11 |
| gouthamr | i should ask folks that have been here longer than i have, i wasn't able to find anything like this.. but the last time we chatted, fungi recalled some discussions | 18:11 |
| gouthamr | the bottomline i recall from that was we didn't think the phone home was instrumented within OpenStack so it was not concerning for us to see them post a payload to the storage system cinder's managing with some environmental information | 18:13 |
| clarkb | the early discussions I remember ar lifeless wanting to have an openstack wide metrics gathering and reporting services similar to what ubuntu does. But even suggesting it be off by default epople didn't like the idea. Unfortunately I culdn't find records of this in old etherpad from design summits | 18:14 |
| clarkb | its possible it was all hallway track discussion to gauge interest and when it was clear no one wanted it that was the end of it | 18:14 |
| jbernard | the feedback i got from the ML was that any default-enabled phone-home, regardless of where the payload was posted, was of concern | 18:16 |
| gouthamr | ack, the list message got lost in my inbox through PTO.. i can respond with my view.. but, if you're looking for the TC's stance, we'd need to craft a resolution | 18:19 |
| gouthamr | if you're able to articulate this well, jbernard, i'd suggest creating one for this | 18:19 |
| jbernard | a resolution? | 18:19 |
| gouthamr | yes | 18:20 |
| jbernard | sure, but i am unfamiliar with the process, can you point me in a direction? | 18:20 |
| gouthamr | yes | 18:20 |
| gouthamr | i think your stance is - "any call home support should only be enabled with the user's/operator's explicit consent, reinforcing our view that it should not be a default setting for privacy concerns" | 18:20 |
| gouthamr | and not that you'd be opposed to it entirely, correct? | 18:21 |
| gouthamr | i.e., don't call home at all, vs call home only if i tell you to? | 18:21 |
| jbernard | exactly, things of that nature should be opt-in | 18:21 |
| gouthamr | perfect, https://governance.openstack.org/tc/resolutions/index.html | 18:22 |
| jbernard | ok, thanks | 18:22 |
| gouthamr | ^ you can see a ton of examples, there's no explicit format, please feel free to add context/links etc as you see fit | 18:22 |
| jbernard | will do, appreciate your time | 18:23 |
| gouthamr | thanks for bringing this here, and for your patience | 18:23 |
| * gouthamr doesn't see any other time critical discussion on the meeting agenda | 18:26 | |
| gouthamr | will push topics to next week | 18:26 |
| clarkb | can also have discussions on the mailing list between now and then | 18:27 |
| noonedeadpunk | gmaan: the thing is that we still have project guide reffering to it as it's the case | 18:28 |
| noonedeadpunk | I will update them though | 18:28 |
| noonedeadpunk | so I got confused about what is that and why we are not considering this flow | 18:29 |
| clarkb | oh and ya to reiterate fork does not mean go to github | 18:29 |
| gmaan | noonedeadpunk: ok | 18:30 |
| clarkb | opendev can host forks of projects within opendev. Ideally we avoid that situation but in some cases it probably makes sense. | 18:30 |
| clarkb | forks can also choose to go to github or wherever they like. That is the beauty of forking we're no longer responsible | 18:30 |
| noonedeadpunk | another part I kinda was hoping to find in project guide, which I didn't find, is what's the process of bringing your org to opendev? | 18:31 |
| clarkb | noonedeadpunk: you just create the repo | 18:31 |
| clarkb | there is nothing really special about it (I think this is why you think it ismissing) | 18:31 |
| noonedeadpunk | oh, okay.... | 18:32 |
| noonedeadpunk | so if I just add a repo in a different namespace - it should just work? | 18:32 |
| clarkb | yes | 18:32 |
| gmaan | yeah, project creation guide do stat that I think but yes project creation process is something they can follow | 18:32 |
| gmaan | https://docs.opendev.org/opendev/infra-manual/latest/creators.html#decide-status-and-namespace-of-your-project | 18:33 |
| gmaan | "For OpenStack and thus the openstack namespace, the policies are:" sectin | 18:33 |
| noonedeadpunk | the one which says you can make unofficial project in openstack namespace ?:) | 18:34 |
| noonedeadpunk | yeah, I saw that | 18:34 |
| gmaan | k | 18:34 |
| noonedeadpunk | I was just somehow expecting it to be more hideous process | 18:34 |
| noonedeadpunk | like approval from somewhere on adding a tenant | 18:34 |
| noonedeadpunk | foundation or smth | 18:34 |
| gmaan | clarkb: maybe you want to update this about x namespace usage- https://docs.opendev.org/opendev/infra-manual/latest/creators.html#decide-status-and-namespace-of-your-project | 18:35 |
| gmaan | "...you may create a new one, or use the catch-all x namespace if you cannot decide." | 18:35 |
| clarkb | gmaan: ++ that should be updated | 18:35 |
| clarkb | remote: https://review.opendev.org/c/opendev/infra-manual/+/958571 Drop the suggestion for using the x/ namespace | 18:37 |
| gmaan | thanks +1 | 18:41 |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!