| *** gmann is now known as gmann_pto | 01:16 | |
| opendevreview | OpenStack Proposal Bot proposed openstack/openstack-manuals master: Imported Translations from Zanata https://review.opendev.org/c/openstack/openstack-manuals/+/947180 | 03:49 |
|---|---|---|
| *** jroll05 is now known as jroll0 | 07:09 | |
| opendevreview | Dmitriy Chubinidze proposed openstack/openstack-manuals master: Update and add roles in Glossary https://review.opendev.org/c/openstack/openstack-manuals/+/947109 | 07:18 |
| opendevreview | Dmitriy Chubinidze proposed openstack/openstack-manuals master: Update and add roles in Glossary https://review.opendev.org/c/openstack/openstack-manuals/+/947109 | 07:45 |
| opendevreview | Ivan Anfimov proposed openstack/security-doc master: WIP https://review.opendev.org/c/openstack/security-doc/+/947198 | 09:35 |
| opendevreview | Ivan Anfimov proposed openstack/security-doc master: WIP https://review.opendev.org/c/openstack/security-doc/+/947198 | 09:37 |
| opendevreview | Ivan Anfimov proposed openstack/security-doc master: WIP https://review.opendev.org/c/openstack/security-doc/+/947198 | 09:38 |
| opendevreview | Ivan Anfimov proposed openstack/security-doc master: Fix for Operator (Enginner) https://review.opendev.org/c/openstack/security-doc/+/947198 | 09:38 |
| opendevreview | Ivan Anfimov proposed openstack/openstack-manuals master: WIP https://review.opendev.org/c/openstack/openstack-manuals/+/947254 | 14:28 |
| opendevreview | Ivan Anfimov proposed openstack/openstack-manuals master: WIP https://review.opendev.org/c/openstack/openstack-manuals/+/947254 | 14:29 |
| opendevreview | Ivan Anfimov proposed openstack/openstack-manuals master: Fix mistake in Glossary https://review.opendev.org/c/openstack/openstack-manuals/+/947254 | 14:30 |
| opendevreview | Jeremy Stanley proposed openstack/openstack-manuals master: Revert "Region / Availability Zone - update Glossary" https://review.opendev.org/c/openstack/openstack-manuals/+/947256 | 14:32 |
| opendevreview | Jeremy Stanley proposed openstack/openstack-manuals master: Revert "Region / Availability Zone - update Glossary" https://review.opendev.org/c/openstack/openstack-manuals/+/947256 | 14:34 |
| fungi | docs reviewers: ^ i have a suspicion that may have been "ai generated" | 14:34 |
| fungi | if you're really comfortable with the original change, then maybe we can just revert the addition of "(Enginner)" to "Operator" references | 14:36 |
| fungi | but it's a huge change and clearly doing more than the mere "updated formatting" claimed in the commit message | 14:36 |
| fungi | oh, that may be the wrong change | 15:00 |
| fungi | never mind, it was the same one | 15:01 |
| fungi | also i'm a little worried about the author referring to "we" | 15:14 |
| fungi | it sounds like there may be multiple authors for the original change contributing under a single address? | 15:15 |
| frickler | there seems to be a lot of inconsistency between reviewers for the docs repos, too, which is why I have stopped looking at these changes | 15:21 |
| fungi | it's unclear that broad, sweeping changes like that which change formatting and add terminology in random places are appropriate for a repository with very limited reviewing capacity | 15:23 |
| fungi | i only skimmed, but the value seemed low compared to the effort required to properly review | 15:23 |
| fungi | if i were a docs core reviewer i would probably have -2'd it | 15:24 |
| fungi | text reformatting changes are like code refactoring changes. they should come completely separate from any content changes | 15:29 |
| frickler | fungi: ack, I've +2d the revert now. maybe spotz[m] and noonedeadpunk can check | 15:31 |
| noonedeadpunk | fungi: I'm pretty sure it's not | 15:31 |
| frickler | fwiw I don't think that this was necessarly ai generated. auto generated maybe/likely. | 15:32 |
| noonedeadpunk | regarding AI | 15:32 |
| noonedeadpunk | also folks are pretty much in contact as well | 15:32 |
| fungi | got it, i was basing that guess on the fact that it seems to be coming from someone with limited knowledge of openstack's software or community norms | 15:33 |
| noonedeadpunk | they are trying to look through the docs across the board and make them more "aligned" with state and look in an "enterprisish" way | 15:33 |
| fungi | and yet it was a massive change with very little substance, but also mingled widespread formatting changes with added content | 15:33 |
| noonedeadpunk | yeah | 15:33 |
| noonedeadpunk | Ithink that is valid assumption | 15:33 |
| noonedeadpunk | Though I think we must do communication better | 15:33 |
| fungi | got it, yes that sounds like it has basically no value then | 15:34 |
| noonedeadpunk | I'm not sure I agree about the value, but I agree that content/syntax should be separate patches | 15:34 |
| fungi | unless they're interested in becoming de facto maintainers of the documentation going forward, reformatting what's there to match their preferences doesn't really help with maintaining the content | 15:35 |
| noonedeadpunk | But also - I don't think that there is another way of doing formatting changes | 15:35 |
| noonedeadpunk | Frankly - I was looking at it as the first step when approving | 15:36 |
| noonedeadpunk | As starting from aligning doc format before doing content change - is fine | 15:36 |
| noonedeadpunk | and you also do catch and can mark things TBD for follow-ups? | 15:37 |
| noonedeadpunk | Anyway, our glossary is in the terrible state from what I saw... | 15:37 |
| fungi | yeah, but introducing errors into the glossary causes them to be auto-propagated to other repositories, and require changes in those repositories to support the terminology changes, so the impact reaches far beyond just the openstack-manuals repo (this is how i spotted the change in the first place) | 15:38 |
| noonedeadpunk | ok, so can we come up with a clear comment/message to these folks on what/how we want them to approach such a huge thing? | 15:39 |
| noonedeadpunk | in case https://review.opendev.org/c/openstack/openstack-manuals/+/947254 is not sufficient? | 15:40 |
| frickler | well I tried with e.g. https://review.opendev.org/c/openstack/openstack-manuals/+/946986/comment/f6ae3ee9_3b4d55fe/ but seems I didn't convince you or spotz[m] | 15:42 |
| fungi | first i think the docs reviewers need to decide whether they're okay with wide-scale formatting changes being comingled with arbitrary content/terminology changes, or require them to be separated | 15:42 |
| noonedeadpunk | yeah, I totally think they should.... | 15:42 |
| fungi | probably also need to decide whether the current review bandwidth of the project is sufficient to support large sweeping changes at all | 15:43 |
| fungi | vs smaller more strategic changes that bring a high value relative to the review effort required | 15:44 |
| noonedeadpunk | Well. I pretty much read the patch through, except I was not fully aware about potential consequences of https://review.opendev.org/c/openstack/openstack-manuals/+/947254/3/doc/common/glossary.rst | 15:44 |
| fungi | what was the rationale for changing the term "Operator" to "Operator (Enginner)"? even without the typo, it's a misleading change to the glossary term | 15:45 |
| fungi | the commit message didn't even indicate there were content changes at all, pretended to just be a reformatting change | 15:45 |
| fungi | if i were a docs reviewer i would have insisted on a better commit message first (i did in the change that was fallout from it in the security-doc repo) | 15:46 |
| noonedeadpunk | ok. so pretty much to sum up: 1. revert the change 2. propose the change in parts - first formatting patch, next content updates made | 15:46 |
| noonedeadpunk | communicate this to contributors | 15:47 |
| fungi | also maybe 3. avoid alterations to the glossary terms themselves if at all possible, since they require subsequent alterations to any text linking those terms to the glossary | 15:47 |
| noonedeadpunk | formatting changes are fine though, right? | 15:48 |
| noonedeadpunk | or they also causing issues? | 15:48 |
| frickler | I would say no, why do them? | 15:48 |
| clarkb | the issue is the anchors change right? | 15:48 |
| fungi | just keep in mind the terms become hyperlinks so changing terms changes the hyperlinks and sphinx will choke | 15:48 |
| fungi | yes, that | 15:48 |
| frickler | and I also don't see why the capitalization needs to be changed | 15:48 |
| clarkb | the definitions can change if the anchors don't change | 15:48 |
| clarkb | but changing the anchors is what creates work for everyone else | 15:48 |
| noonedeadpunk | But anchors in our case are... register dependent? | 15:49 |
| fungi | well, secondary to that is the glossary file adjustments get auto-proposed to other docs repos where copies of it reside | 15:49 |
| noonedeadpunk | frickler: I'd say that current incosistency in casing looks terrible indeed. | 15:49 |
| clarkb | fungi: aha I didn't realize there were auto updates of content too | 15:50 |
| clarkb | so both things create more work. I guess care should be taken in either case then | 15:50 |
| fungi | changing between upper/lower case ascii doesn't alter the hyperlinks, though if i were doing a massive change i'd probably stack with capitalization normalization in one change, spacing/wrapping in another change, et cetera | 15:50 |
| noonedeadpunk | ++ fair enough | 15:51 |
| noonedeadpunk | do you have an example of auto-generated patch? as I'm kinda trying to understand auto-update part now as well | 15:51 |
| noonedeadpunk | But let's proceed with action points then... | 15:53 |
| fungi | noonedeadpunk: https://review.opendev.org/947166 | 15:56 |
| fungi | and https://review.opendev.org/947198 which ended up needed to make it build | 15:56 |
| fungi | which was where my breadcrumb trail began | 15:57 |
| noonedeadpunk | aha | 15:57 |
| noonedeadpunk | I just never have used `:term:` in docs (+_+) | 15:58 |
| noonedeadpunk | I totally should had... | 15:58 |
| * gouthamr has to catch up on scrollback ... meetings ¯\_(ツ)_/¯ | 16:00 | |
| gouthamr | sorry to interrupt this, but, | 16:00 |
| fungi | yeah, i've been multi-tasking this conversation while on a conference call | 16:00 |
| gouthamr | tc-members: gentle reminder that our weekly irc meeting is here in ~59 minutes | 16:00 |
| fungi | i feel your pain ;) | 16:01 |
| fungi | and now that the tc meeting time has changed, i'll be trying to follow it while on another conference call. c'est la vie | 16:01 |
| gouthamr | ++ | 16:04 |
| gouthamr | #startmeeting tc | 17:00 |
| opendevmeet | Meeting started Tue Apr 15 17:00:18 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:00 |
| gouthamr | Today's meeting agenda can be found at https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee | 17:00 |
| gouthamr | #topic Roll Call | 17:00 |
| cardoe | o/ | 17:00 |
| frickler | \o | 17:01 |
| noonedeadpunk | o/ | 17:01 |
| gtema | o/ | 17:01 |
| gouthamr | courtesy-ping: gmann, spotz[m], mnasiadka, bauzas | 17:03 |
| gouthamr | ah crap | 17:04 |
| gouthamr | noted absence: g m a n n | 17:04 |
| frickler | iirc mnasiadka is down under | 17:04 |
| gouthamr | ah, ack | 17:04 |
| gouthamr | alright, lets get started | 17:05 |
| gouthamr | #topic Last Week's AIs | 17:05 |
| gouthamr | ^ this would be a loaded topic, i am yet to unpack all of the TC PTG notes and enumerate AIs | 17:05 |
| gouthamr | but, lets look at AIs from the week prior | 17:06 |
| gouthamr | 1) Skyline Engagement | 17:06 |
| gouthamr | we took an AI to reach out to skyline contributors about reproducibility concerns and encourage PTG participation | 17:07 |
| gouthamr | i received an email from the PTL wu_wenxiang that the PTG timings weren't feasible for the team | 17:08 |
| gouthamr | they'd prefer a conversation between 1:00 UTC to 10:00 UTC | 17:08 |
| cardoe | We didn't get a chance to talk about binary artifacts during the PTG | 17:08 |
| cardoe | I tossed on there talking about containers generally as well. | 17:09 |
| gouthamr | yes, the other request on the email was that we could share discussion topics/questions before the meeting because of fluency/communication concerns | 17:10 |
| noonedeadpunk | well. for EU based ppl 8UTC-10UTC could be doable to sync with them | 17:10 |
| fungi | we did talk about the topic some in the security sig sessions | 17:10 |
| fungi | (binary artifact challenges i mean) | 17:10 |
| noonedeadpunk | but indeed, async might be better to minimize language confusion | 17:11 |
| gouthamr | yeah, they'd be more effective with async communication | 17:11 |
| gouthamr | so lets defer to email | 17:12 |
| frickler | is there a reason to keep it off the ML, then? | 17:12 |
| cardoe | UTC 8:00 to 10:00 is 3am to 5am for me. | 17:12 |
| gouthamr | i also see that they're using different emails to respond to my original email | 17:12 |
| noonedeadpunk | (the reason I said about EU) | 17:12 |
| gouthamr | i don't know if there's some firewalling of sorts, on either end: "I guess that the emails sent from my mailbox might be blocked" | 17:13 |
| noonedeadpunk | as 8UTC is 10 am for me | 17:13 |
| gouthamr | ack, i'll try to keep the conversation on the list, but noting that, if we don't get responses, it might be because of something weird like this | 17:13 |
| gouthamr | fungi: i'll poke you later to check on some list subscriptions | 17:14 |
| gouthamr | i.e., if you could check/share if individuals on the skyline team are subscribed to openstack-discuss | 17:14 |
| frickler | gouthamr: maybe mention that it is also possible to read/respond via the web interface | 17:15 |
| gouthamr | ah true, its clunky though, but will suggest it | 17:15 |
| fungi | can do | 17:16 |
| fungi | i've got some time right after this meeting | 17:16 |
| cardoe | So I think without having to engage them at all we can have a discussion about binary artifacts. | 17:16 |
| fungi | happy to look up whatever you need | 17:16 |
| gouthamr | ack | 17:16 |
| gouthamr | thank you fungi | 17:17 |
| gouthamr | cardoe: as fungi said, we just mentioned it in the security-sig room.. our notes didn't capture it here, because the discussion wasn't too detailed | 17:17 |
| gouthamr | just a status of where we are | 17:17 |
| gouthamr | #link https://etherpad.opendev.org/p/apr2025-ptg-os-security-sig (OSSG PTG Etherpad) | 17:17 |
| gouthamr | i'll work on this AI further and share some more next week | 17:18 |
| cardoe | I saw that more as VMT discussion. | 17:18 |
| cardoe | Not on reproducibility which is what the issue with skyline was. | 17:18 |
| cardoe | Which is certainly related | 17:18 |
| fungi | we touched on the security risks and need for things like sboms with containers and packages | 17:18 |
| fungi | not necessarily vmt, just security more generally | 17:19 |
| fungi | from a vmt perspective, we just flat refuse to cover container/package-specific vulnerabilities, and focus on vulnerabilities in our source distribution only | 17:19 |
| cardoe | Anyway, I think the topic is similar to security-sig but not 100% aligned. | 17:20 |
| cardoe | We can move on. | 17:20 |
| fungi | though cases where projects are committing third-party dependencies into their repositories crosses the line into source distribution vulnerabilities | 17:20 |
| gouthamr | next couple of AIs are related to goal updates for the FIPS and privsep migration goals | 17:21 |
| gouthamr | we heard more about this during PTG week. there's some homework left to do here, i'll track these | 17:21 |
| gouthamr | and we had two other AIs, tacked to folks not present here.. | 17:22 |
| gouthamr | we've work to do wrt upgrade jobs across projects | 17:22 |
| gouthamr | and bauzas meant to reconnect with seongsoocho and ianychoi for updates on translation tool migration and SIG activities | 17:23 |
| gouthamr | the i18n SIG met last week at the PTG: | 17:23 |
| gouthamr | #link https://etherpad.opendev.org/p/apr2025-ptg-i18n (i18n PTG Etherpad) | 17:24 |
| gouthamr | there are some status updates there ^ | 17:24 |
| gouthamr | a couple of actionable items, but, we probably could use context | 17:25 |
| gouthamr | does anyone, perhaps fungi noonedeadpunk have anything urgent to bring up here? or should we chat about this next week when we've had some time to digest the AIs | 17:26 |
| fungi | i do not | 17:27 |
| cardoe | nothing urgent | 17:27 |
| fungi | stuff we need to cover, but doesn't have to be today | 17:27 |
| fungi | (wrt i18n/weblate) | 17:27 |
| gouthamr | okay, i'll add a topic to our next meeting regarding this | 17:27 |
| gouthamr | #topic OpenStack User Survey follow up | 17:29 |
| gouthamr | so the user survey for 2025 is live | 17:29 |
| gouthamr | #link https://www.openstack.org/user-survey/survey-2025 (2025 OpenStack User Survey) | 17:30 |
| gouthamr | but allison tells me we can seek edits to the questions | 17:31 |
| noonedeadpunk | \o/ | 17:31 |
| gouthamr | there were 7 questions the TC had posed in the past | 17:31 |
| gouthamr | i can put those up in an etherpad: https://etherpad.opendev.org/p/tc-2025.2-tracker | 17:33 |
| gouthamr | lets try to probably critique these questions, and see if something is irrelevant and can be removed | 17:35 |
| gouthamr | its also an opportunity to add questions | 17:35 |
| gouthamr | so if you can think of something worth asking, please feel free to add it to the etherpad | 17:36 |
| gouthamr | my next question to aprice would be to get results of the 2024 User Survey | 17:37 |
| gouthamr | so we can work on a report like these: | 17:37 |
| gouthamr | #link https://governance.openstack.org/tc/#summary-of-user-survey-questions-responses | 17:37 |
| gouthamr | any opinions/concerns to share regarding this? | 17:38 |
| frickler | sounds like a good plan to me | 17:38 |
| cardoe | yeah this all seems good | 17:38 |
| gouthamr | ty, lets move on.. | 17:39 |
| gouthamr | the next topic will be a sticky one here for a while | 17:39 |
| gouthamr | #topic PTG Follow up | 17:39 |
| gouthamr | #link https://etherpad.opendev.org/p/apr2025-ptg-os-tc | 17:39 |
| gouthamr | as i shared on the ML, the summary is a WIP, but, please do add your thoughts to the minutes you see on the pad | 17:40 |
| gouthamr | #link https://www.youtube.com/playlist?list=PLhwOhbQKWT7XYzqrx21j1uizxNxnbDf5Q (TC PTG Recordings) | 17:41 |
| gouthamr | it was a lot to unpack, but i really enjoyed the brainstorm we had over these 4 sessions, and will likely refer back to these minutes and recordings for a while | 17:42 |
| gouthamr | one thing that got sufficient airtime is this resolution that'll need next steps | 17:43 |
| gouthamr | #link https://review.opendev.org/c/openstack/governance/+/944817 ([resolution] Extend scope of VMT to cover all project teams) | 17:43 |
| gouthamr | we do need some more roll call votes here, please take a look and add your +1 or -1 and any comments | 17:44 |
| gouthamr | that's all i had for $topic today | 17:46 |
| gouthamr | does anyone have anything else to share? | 17:46 |
| gouthamr | how was the PTG? did you need a stiff drink at the end of each day? | 17:46 |
| cardoe | just lots of jumping between sessions felt like I was rude cause I had to leave | 17:46 |
| gouthamr | ah, that's well understood i think, unless you were saying something and dropped off mid-sentence | 17:47 |
| gouthamr | :D | 17:47 |
| gouthamr | but i heard your concerns regarding the scheduling | 17:48 |
| sean-k-mooney | i think the virutal ptg are worse for that. its feels like you shodul attend as much as you can but as a result you end up back to back ot back between rooms | 17:48 |
| sean-k-mooney | at least the in person event you got 5-10 mins while you walks between rooms to recharge | 17:48 |
| gouthamr | true | 17:48 |
| gouthamr | #link https://etherpad.opendev.org/p/apr2025_ptg_feedback (PTG Feedback) | 17:49 |
| gouthamr | think mandatory breaks, pre-published agendas, cross project space all are good asks, we can try to be a bit better with the next round with some changes | 17:50 |
| sean-k-mooney | some porject definlty did build in some room. if you were in multiple tracks they didnt alwasy align but i dont think it was specificly any worse this time then the past few | 17:51 |
| sean-k-mooney | but ya planing ot use 50 mins out of the 1 hour blocks and taking that break i think helps | 17:52 |
| gouthamr | ++ | 17:52 |
| * gouthamr copies this feedback into the etherpad | 17:53 | |
| gouthamr | alright, we're left with 7 minutes, and two more topics | 17:54 |
| gouthamr | lets check on these | 17:54 |
| gouthamr | #topic Gate Health | 17:54 |
| fungi | i liked seeing some "happy hour" blocks in agendas | 17:54 |
| gouthamr | fungi++ | 17:54 |
| gouthamr | we should do more of that, and try the unconference style meetups that ironic folks were telling us about | 17:55 |
| clarkb | did grenade get updated to do the new upgrade paths? I should just go look | 17:56 |
| gouthamr | have there been any failures? | 17:56 |
| frickler | iirc gmann did the right things | 17:57 |
| gouthamr | #link https://review.opendev.org/q/topic:%22qa-2025-1-release%22 | 17:57 |
| gouthamr | #link https://review.opendev.org/c/openstack/grenade/+/945244 | 17:57 |
| gouthamr | #link https://review.opendev.org/c/openstack/grenade/+/945245 | 17:57 |
| gouthamr | note to carloss: gmann suggested a manila non-voting grenade job against this repo ^ | 17:58 |
| gouthamr | clarkb: hope those links answer the question | 17:59 |
| clarkb | yup looks good | 17:59 |
| gouthamr | we've one minute left | 17:59 |
| gouthamr | (or not) | 17:59 |
| carloss | gouthamr: ack, ty :) | 18:00 |
| gouthamr | just a quick link to the TC tracker for 2025.2 | 18:00 |
| gouthamr | #link https://etherpad.opendev.org/p/tc-2025.1-tracker (Technical Committee activity tracker - 2025.1) | 18:00 |
| gouthamr | please add anything you'd like to track through these meetings here ^ | 18:00 |
| gouthamr | with that, we don't have time for Open Discussion today | 18:00 |
| gouthamr | but does anyone want to say something to record in the minutes? | 18:00 |
| gouthamr | thank you all for participating today, this meeting will return next week! | 18:01 |
| gouthamr | #endmeeting | 18:01 |
| opendevmeet | Meeting ended Tue Apr 15 18:01:39 2025 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 18:01 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/tc/2025/tc.2025-04-15-17.00.html | 18:01 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/tc/2025/tc.2025-04-15-17.00.txt | 18:01 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/tc/2025/tc.2025-04-15-17.00.log.html | 18:01 |
| spotz[m] | Well crap, I've been sitting here watching the discussion thinking it was a pre-meeting chat:) | 18:02 |
| gouthamr | hahaha :D | 18:02 |
| spotz[m] | I need to update my calendar as it says 1pm | 18:02 |
| gouthamr | hope your time off was good, spotz[m] | 18:02 |
| sean-k-mooney | so now that the meeting is over :) i was watchign the tc youtube videos | 18:03 |
| gouthamr | spotz[m]: yes, the ics file should be updated: https://meetings.opendev.org/#Technical_Committee_Meeting | 18:03 |
| gouthamr | sean-k-mooney++ | 18:03 |
| spotz[m] | It was great, I missed home though | 18:03 |
| sean-k-mooney | im kind of trouble by the idea that the TC consider it the PTL who choses the member of the core team | 18:03 |
| sean-k-mooney | form my perspecitive that has never been true | 18:04 |
| sean-k-mooney | its the member of the core team | 18:04 |
| gouthamr | the project team guide calls out that the TC makes the core reviewer changes on gerrit | 18:04 |
| gouthamr | ugh, s/TC/PTL | 18:04 |
| sean-k-mooney | can you show me where it say that in the governace repo | 18:05 |
| sean-k-mooney | because the project team guide is not a athouritive soruce in my view | 18:05 |
| gouthamr | #link https://docs.openstack.org/project-team-guide/ptl.html#core-member-maintenance | 18:05 |
| spotz[m] | Ok calendar updated from 18:00 UTC to 17:00 UTC | 18:05 |
| sean-k-mooney | so to me that has no technial standing with regards to the governace of the projects | 18:06 |
| sean-k-mooney | i agree that the ptl often does that | 18:06 |
| sean-k-mooney | but not that its solely at there discretion | 18:06 |
| gouthamr | and it was stated on the call that PTLs can be designating the core reviewer maintenance to other team members | 18:06 |
| gouthamr | the TC isn't opposed to having a non-core PTL btw | 18:07 |
| sean-k-mooney | oh i know | 18:07 |
| sean-k-mooney | i just dont agree that the core team mebership shoudl be an apportinemt solely of the ptl and that they are delegating the capablity to other core team member when the apoint is done otherwise | 18:08 |
| fungi | the tc is responsible for decisions of how projects are run, and they delegate that responsibility to the ptl for each project (or to a set of dpl liaisons). it's therefore the ptl's responsibility, but they are free to delegate that responsibility e.g. to the existing core review team | 18:08 |
| fungi | core reviewers aren't mentioned in the tc charter at all | 18:08 |
| fungi | the decision to structure a team into a set of core reviewers making choices about what changes merge is up to each team | 18:08 |
| fungi | and different teams do in fact decide on different kinds of review structures, they don't all follow the exact same pattern | 18:09 |
| fungi | for example, ironic has two tiers, some with only code review +2 permissions, others with also workflow +1 permissions | 18:10 |
| sean-k-mooney | there is a similar setup in the sdk/osc | 18:10 |
| sean-k-mooney | project teams have +2 but not +w rights | 18:10 |
| fungi | but the point is elections are the backstop for a team to be able to oust a misbehaving core review team, they do that by electing a ptl who will dissolve the current set of core reviewers and appoint new ones | 18:11 |
| sean-k-mooney | i have never seen that as the role of a PTL | 18:11 |
| sean-k-mooney | i have seen that only as the role fo the TC as the backstop | 18:11 |
| fungi | whose role is it then? the tc's directly, and they're not allowed to delegate it to an elected member of the team? | 18:12 |
| sean-k-mooney | right i think in the exteram case such as deloving a core team | 18:13 |
| fungi | the charter certainly doesn't say so | 18:13 |
| sean-k-mooney | that shoudl require a vote of the tc | 18:13 |
| fungi | it's a de facto responsibility of the tc because they are responsible how all projects are run, but the current charter doesn't prevent them from delegating that responsibility to a ptl | 18:13 |
| sean-k-mooney | but im more conferend with the idea that the https://docs.openstack.org/project-team-guide is seen as athrotive and not just a docuemantion fo best practices | 18:13 |
| sean-k-mooney | well hopefully we will never need to find out either way | 18:14 |
| fungi | i think it's fine for a ptl to delegate deciding who gets to be a core reviewer to other core reviewers, but if something goes wrong then the ptl needs to have the leeway to un-delegate that responsibility | 18:15 |
| sean-k-mooney | well i guess the TC is a check on the pwoer of etiher group | 18:16 |
| sean-k-mooney | if the PTL and core team disagree they and both escalate to the TC if they cant come to an agreement on how to proceed | 18:16 |
| fungi | sure, though the tc can also just tell the ptl to decide | 18:17 |
| fungi | or back the ptl's decision rather, since the ptl is elected by the team and the core reviewers are not | 18:18 |
| sean-k-mooney | you saying there is no way for a ptl to be stripped of there powere outside of the next election if they are abusing there delegated powers? | 18:18 |
| fungi | i did not say that at all | 18:18 |
| sean-k-mooney | oh ok, well that what i ment by if there is a disagrement. i.e. if hte ptl just added themselve to the core tema and start merging things without any disucssion i would consider that to be an abuse of there delegated powers | 18:19 |
| fungi | though i think it would require a 2/3 supermajority of the tc to vote in favor of amending the charter to add rules for removing a ptl directly | 18:20 |
| sean-k-mooney | ack, again hopefuly that will never come up | 18:20 |
| fungi | right now the charter has a process for replacing a ptl who vacates their seat before the term ends | 18:20 |
| fungi | it does not have a process for removing a sitting ptl, but it could have if the need arose, the tc would just need to vote in favor of adding that provision (and decide what the process should be) | 18:21 |
| sean-k-mooney | on a related but differnt topic, do you know when the vote on LF membership completes | 18:21 |
| fungi | gimme a sec, looking | 18:23 |
| sean-k-mooney | its fine. i found the email and the pool ink again | 18:26 |
| fungi | sean-k-mooney: looks like a ballot was sent to all foundation individual members on 2025-04-06 but it does not mention a poll closing date | 18:26 |
| sean-k-mooney | but it didnt say when it end just when it opends and form what date people were eligble | 18:26 |
| sean-k-mooney | fungi: yep | 18:26 |
| fungi | my guess is that it will close once we get sufficient quorum, so that it can be left open long enough to reach that state | 18:27 |
| sean-k-mooney | that why i was asking. i didnt recall a closing date when i cliend it and checkign again i dont see one listed | 18:27 |
| fungi | but i'll ask | 18:27 |
| sean-k-mooney | ack | 18:27 |
| sean-k-mooney | no worries | 18:27 |
| sean-k-mooney | the status is kind of tracked here https://board.openinfra.org/en/strategic-consideration | 18:27 |
| sean-k-mooney | i was just wonderign how it was progressing in general | 18:28 |
| fungi | sean-k-mooney: wes wilson says the foundation staff has the option to leave the poll open for as much as 60 days, so i suppose that means it could be closing as late as july 5 but may also close sooner | 18:31 |
| fungi | er, june 5 i mean | 18:31 |
| sean-k-mooney | fungi: ack. im more being nosy since i dont think there was any ptg topic/session covering this (not that we needed one) | 18:32 |
| fungi | regardless, i'd recommend anyone who is interested in voting on the matter do so as soon as possible in order for their opinion to be counted. if a foundation individual member didn't receive a ballot feel free to reach out to me directly and i can help get things sorted out too | 18:33 |
| gouthamr | yeah i thought we might chat about it at PTG, but there was nothing pressing to discuss.. the foundation collected feedback over multiple weeks, and hosted some AMA-style meeting calls virtually and physically | 18:35 |
| gouthamr | there were some takeaways from this for the foundation and staff to work on | 18:35 |
| gouthamr | no actionable feedback on OpenStack projects or the TC itself (besides the vote if you're a foundation member) | 18:37 |
| fungi | mark collier and jonathan bryce also clarified, since openinfra foundation is incorporated in delaware, "written consent" of these kinds of changes requires a vote of the affected membership stay open until 50% of those eligible to vote have done so or until it's been open for 60 days, whichever comes first | 18:43 |
| fungi | and i think for quorum we technically only need 10% to vote but we have to leave it open until either 50% do so or the clock runs out, but as long as we do get at least 10% voting within the 60-day window then the vote is binding | 18:44 |
| gouthamr | a reminder to look for the ballot may help | 18:45 |
| fungi | yes, they're planning to send one i think | 18:45 |
| gouthamr | ++ | 18:45 |
| fungi | oh, slight clarification, an error on my part, there is no 10% quorum requirement to be binding in this case. it's just at least 50% of eligible voters have voted or they've been given 60 days in which to do so | 18:48 |
| fungi | also it sounds like a reminder is probably going out tomorrow, in fact | 18:48 |
| sean-k-mooney | i was actully surpsied | 18:50 |
| sean-k-mooney | i asked if we would have a vote of this kind in one of the AMA sessions and at the time | 18:50 |
| sean-k-mooney | the answer was no | 18:50 |
| fungi | yeah, i think it was realized later by the legal team handling the closing that a vote would be required for dissolution of the corporation | 18:51 |
| sean-k-mooney | so i tought we would not end ups doing a ballot of the indivugal members | 18:51 |
| sean-k-mooney | right my uninformed guess was it would be | 18:51 |
| fungi | so it's technically not a vote to join the lf, but a vote to dissolve the openinfra foundation registered as a separate delaware corporation, minor difference i suppose | 18:51 |
| sean-k-mooney | but for no reason other then i flet like that might be a thing | 18:51 |
| fungi | hard to join the lf without dissolving the existing foundation, in retrospect ;) | 18:52 |
| bauzas | gouthamr: sorry for not being able to attend the meeting, I had a power outage 20 mins before and my IRC server crashed :( | 18:52 |
| gouthamr | bauzas: ack, no problem | 18:59 |
| gouthamr | bauzas: we'll discuss i18n PTG takeaways at the next TC meeting | 19:00 |
| bauzas | ack | 19:00 |
| bauzas | sure | 19:00 |
| bauzas | I'll review the VMT governance patch | 19:00 |
| gouthamr | ++ ty | 19:00 |
| * sean-k-mooney is listening to the chat tools debate | 19:05 | |
| clarkb | I don't know why that reminded me but gouthamr the notify everyone when you start a recording feature that we tried to turn on doesn't seem to work as expected after some testing. No worse than before but no better either | 19:08 |
| gouthamr | ah! | 19:09 |
| fungi | still possible we're doing something wrong though, we just haven't found time to dig into the reason it's not happening yet | 19:09 |
| gouthamr | i had hope, clarkb! thank you for checking | 19:09 |
| sean-k-mooney | as in is it ment to let you knwo wehn you join or something? | 19:09 |
| fungi | i think it's supposed to pop up a notification when someone starts a recording through jitsi-meet (even if it's using the local recording option). it's a configurable feature which defaults to off, we tried turning it on, but may have turned it on wrong | 19:10 |
| sean-k-mooney | ah | 19:10 |
| sean-k-mooney | i mean anything that web based is going to hard to enfoce tha twith | 19:10 |
| sean-k-mooney | like if i use vlc with screen chapture ectra | 19:10 |
| fungi | right, obviously it can't know if you start recording with a different mechanism than the one included in the applicaiton itself | 19:11 |
| fungi | but in cases where, say, the moderator is going to record the session, it would save them having to remember to notify/remind everyone on the call they're doing so | 19:11 |
| sean-k-mooney | so i tought it showed a recording icon when you joined | 19:12 |
| sean-k-mooney | but honestly i didnt really pay attention | 19:12 |
| sean-k-mooney | i kind of assume that while most sessions are not recorded any of them could be because i treat it as a "public space" | 19:13 |
| sean-k-mooney | so i dont expect privacy but i knwo others woudl not assume that | 19:13 |
| fungi | right, as you should of course, it's just that some jurisdictions have laws obliging you to notify other parties involved when you record a conversation | 19:14 |
| sean-k-mooney | for what its worth i like matix and irc. i hate slack (maing becuase its slow and i hate how it does thread) but ya its hard problem. | 19:16 |
| sean-k-mooney | i have defintly treathed to stop using slack downstream more hten once and condiered baning peopel that open thread in a dm to me... | 19:17 |
| sean-k-mooney | it pains me to say whoever that its not the worst option we choudl choose i woudl just personlly see it as a downgrade | 19:18 |
| sean-k-mooney | weeslack help make slack suck less but its still a daily pain point. | 19:20 |
| gouthamr | #til about weeslack | 19:20 |
| sean-k-mooney | oh you havent heard of it https://github.com/wee-slack/wee-slack | 19:21 |
| sean-k-mooney | ya if you use weechat (not the chineese site the irc client) | 19:21 |
| sean-k-mooney | you can plug in slack or matrix to it too | 19:21 |
| fungi | i've been using weeslack for years but noslack would be my preference when possible ;) | 19:22 |
| gouthamr | hahaha, i almost googled that :D i feel like i will keep installing clients and creating accounts at this rate trying to be everywhere where the conversation needs to happen | 19:23 |
| gouthamr | and then i'll dream of the matrix | 19:23 |
| fungi | yeah, hence the ;) winkie | 19:24 |
| gouthamr | broadcom could buy slack next and make licensing so complicated and expensive | 19:25 |
| clarkb | I think my least favorite one is discord | 19:25 |
| gouthamr | that CTOs could all suddenly discover the wonders of FOSS tools | 19:25 |
| sean-k-mooney | lol that might actully work to get redhat to drop it | 19:25 |
| sean-k-mooney | or discord | 19:25 |
| fungi | discord is terrible, yes | 19:25 |
| fungi | gitter is sort of annoying too | 19:26 |
| sean-k-mooney | discord is for a differnt usecase | 19:26 |
| sean-k-mooney | it was ment for gamers andb then was change to retofit into coperate and OSS workflows | 19:26 |
| fungi | but unfortunately it ends up used by more than a few open source developer communities | 19:26 |
| sean-k-mooney | right because it faster then slack, and worked better on linux intially too | 19:27 |
| fungi | the python core maintainers use it for synchronous discussion, as does the gerrit upstrem developer team | 19:27 |
| sean-k-mooney | glitter or discord | 19:27 |
| sean-k-mooney | huh discord i didnt know that | 19:28 |
| fungi | discord | 19:28 |
| clarkb | discord is just way too much imo. It has a ton of features and is expensive to run | 19:28 |
| clarkb | also the contant ads | 19:29 |
| fungi | not to be confused with the discourse forum software, which the python community also uses but for async discussion (increasingly instead of mailing lists) | 19:29 |
| sean-k-mooney | clarkb: i have not really used it since i stop playing eve online the first tiem. when i came back the secodntime they had swapped to slack which was my first intodicution to it | 19:30 |
| sean-k-mooney | when i last used discored i dont recall it having any adds | 19:30 |
| sean-k-mooney | but its been a long time | 19:31 |
| clarkb | they pop up little things asking you to upgrade to nitro | 19:31 |
| clarkb | which enables even more features I don't want to use | 19:31 |
| fungi | "features" | 19:32 |
| fungi | pay money to "boost" your favorite channels and unlock new emojis | 19:32 |
| fungi | and annoying animated graphical pop-ups | 19:32 |
| sean-k-mooney | i mean for there target market which is/was video game streamers and there audiance and large gaming comunities | 19:33 |
| sean-k-mooney | the upsell makes sense | 19:33 |
| sean-k-mooney | but discored ws never intened for buisness or OSS usage orginally | 19:33 |
| sean-k-mooney | but ya one of the advanages or connecting to slack over wee-slack/weechat is you can turn off all the anomated images and other "features" too | 19:34 |
| fungi | and threads are a little easier to manage | 19:35 |
| fungi | still terrible, but less | 19:35 |
| sean-k-mooney | do you flatten them too? | 19:35 |
| sean-k-mooney | i flatten all thread in to the main channel then if i need to reply ill pop the thread out to a sperate buffer | 19:35 |
| fungi | yes | 19:36 |
| sean-k-mooney | ya so that woudl be my main issue with useing slack upstream honestly | 19:36 |
| sean-k-mooney | there is no way to diable threading in a channel | 19:36 |
| fungi | it's the replying to threads (well, really existence of threads at all) that remains annoying | 19:36 |
| sean-k-mooney | yep exactly | 19:36 |
| fungi | similar issue with threads on matrix fwiw. it was annoying enough that they got convinced it needed that, more annoying still whe they stopped letting you disable them | 19:37 |
| sean-k-mooney | ignoring moderation entirly which is its own probelm if im a maintainer of something and someone is askign a question i dont want there quetions to die in the ether because its in a random thread that no one saw | 19:38 |
| sean-k-mooney | fungi: oh you cant disable it in matrix any more? | 19:38 |
| fungi | nope :/ | 19:38 |
| sean-k-mooney | :( | 19:39 |
| fungi | but at least element now does a better job of letting you notice, find and track threads with unseen content | 19:39 |
| fungi | i wish the weechat-matrix plugin wasn't basically abandoned, i still rely on it but it's missing a lot of functionality | 19:40 |
| sean-k-mooney | i use element on my ipad as a backup for if my irc client diconenct or if im just not at my desk. | 19:40 |
| fungi | the author decided to embark on a rewrite in rust but doesn't have it in a working state yet | 19:41 |
| sean-k-mooney | has the matrix oftc lag impoved. it used to be pretty good but at time it would fall behind | 19:41 |
| sean-k-mooney | ah | 19:41 |
| sean-k-mooney | the oxidation effect | 19:41 |
| fungi | though there are at least some available console-based matrix clients that might work better, i'll just need to run one in a different tmux window than my weechat | 19:42 |
| sean-k-mooney | i have played with rust on and off but it alwasy feel over enginerred | 19:42 |
| sean-k-mooney | weechat is a tool i kind of subleted into | 19:42 |
| sean-k-mooney | i got it working a week or two after starting to contibute to openstack on windows in cygwin | 19:43 |
| sean-k-mooney | when irsi? or hexchat didnt work | 19:43 |
| sean-k-mooney | and i basiclly never changed because it just kept working | 19:43 |
| fungi | irssi, yeah | 19:43 |
| fungi | i switched from irssi to weechat circa 2011 | 19:44 |
| sean-k-mooney | i recently got annoyed with how slow vscode has been so i have started to partime use emacs again | 19:45 |
| fungi | there is a matrix.el client for emacs ;) | 19:45 |
| clarkb | I never stopped using vim and when peopel tell me vim is too slow so they use neovim I'm confused. | 19:45 |
| clarkb | I can't type that fast | 19:45 |
| sean-k-mooney | who has ever said vim of all things is too slow | 19:46 |
| sean-k-mooney | i just cant do vim motions and th way it does model editing. i considerd giving it a try agian recently but it just does nto click with my brian | 19:48 |
| sean-k-mooney | it all comes backs back to what yoru familar with to some degree. | 19:49 |
| sean-k-mooney | anyway i shoudl proably call it a day and stop popluting the tc channel with off topic comments | 19:49 |
| sean-k-mooney | thanks for recording the tc sesssion i couldnt attend them this time so its nice to be able to review them | 19:50 |
| opendevreview | Merged openstack/openstack-manuals master: Fix mistake in Glossary https://review.opendev.org/c/openstack/openstack-manuals/+/947254 | 20:09 |
| opendevreview | OpenStack Proposal Bot proposed openstack/security-doc master: Updated from openstack-manuals https://review.opendev.org/c/openstack/security-doc/+/947166 | 20:11 |
| sean-k-mooney | by the way on the migrate to privsep goal, os-brick is the ownly reason nova has any dep on rootwrap | 20:39 |
| sean-k-mooney | we have been kind of waiting for the cinder team to port it but we might need to just go do that at some point | 20:40 |
| sean-k-mooney | i think rootwrap is also used in cinder in genral | 20:41 |
| sean-k-mooney | but ya the way privsep is used in nova and other proejct is less secure then we would like | 20:42 |
| sean-k-mooney | nova's bigest issues is we use one privsep context for everything | 20:43 |
| sean-k-mooney | we have wanted to break that up fo years | 20:43 |
| sean-k-mooney | for example we need CAP_DAC_OVERRIDE in exactly 1 place but we always have for all privsep calls so we wanted to break up context but we never got back to that cleanup | 20:46 |
| sean-k-mooney | its come up on the mailing list a few times like https://lists.openstack.org/pipermail/openstack-discuss/2021-March/021494.html | 20:47 |
| sean-k-mooney | we need to be careful that as people move to prisep the avoid the know bad patterns liek having a single privsep context or top leve <service>/prisep/* moduels | 20:47 |
| sean-k-mooney | i have no idea if smaller privsep context would help or hurt with memory usage but its one of the things we were concerned about | 20:48 |
| fungi | in theory reducing the privsep context to just the python objects which matter should help with its memory footprint, since ll the context has to be copied | 21:13 |
| fungi | s/ll/all/ | 21:13 |
| sean-k-mooney | that not the narrowing i am refering too | 21:13 |
| sean-k-mooney | https://github.com/openstack/nova/blob/master/nova/privsep/__init__.py#L21-L31 | 21:14 |
| sean-k-mooney | htat is nova's one and only privesep context | 21:14 |
| sean-k-mooney | we really shoudl have 3 1 for file 1 for network and one for cap sys admin when that is relally needed | 21:15 |
| gouthamr | interesting, tech debt perhaps because it was easier to do it this way? | 21:15 |
| sean-k-mooney | yep exactly | 21:15 |
| sean-k-mooney | which i have wanted to chagne since before it was completed | 21:15 |
| sean-k-mooney | we did start on this in aroiund 2021 | 21:16 |
| sean-k-mooney | but the person that was going to work on it changed team | 21:16 |
| sean-k-mooney | it was a short term rotaion and we were going to mentor them true doing an incremantal sepreation | 21:16 |
| fungi | i'm thrilled to cheer you on from the sidelines, but my grasp of the concepts involved falls way short of comprehending that specific situation | 21:16 |
| sean-k-mooney | fungi: simple example does copying a file need CAP_NET_ADMIN | 21:17 |
| sean-k-mooney | right now in nova it has it even if we are only runing chown | 21:18 |
| sean-k-mooney | so its not that is insecure persay its just not the least amoutn of prvialdges we coudl have | 21:18 |
| fungi | yeah, i mean, i grasp that you could have different privilege profiles and use them for appropriate calls, rather than every use sharing a common set of capabilities which is effectively the union of what they all need | 21:19 |
| sean-k-mooney | yep so i filed this downstream to eventually lock it down more https://issues.redhat.com/browse/OSPRH-15 | 21:19 |
| fungi | as far as how to address the memory footprint challenge for python object copies, i'm not sure where to start | 21:20 |
| sean-k-mooney | but ya we dotn have tiem to work on it at the moment | 21:20 |
| clarkb | the memory footprint may also be buffer bloat | 21:20 |
| sean-k-mooney | the memory thing is hard | 21:20 |
| clarkb | you run one command that emits a very large quantity of output and now your long lived process is forever using that memory | 21:20 |
| sean-k-mooney | on one hand i really dont like have a single top level privsep python module | 21:20 |
| sean-k-mooney | as that encurages writing generic functions | 21:21 |
| clarkb | if that is the ussue then using a fixed size buffer and working through the data would help | 21:21 |
| sean-k-mooney | but if we sprinkel them in the module where they are used | 21:21 |
| sean-k-mooney | we may need to import more of the service code | 21:21 |
| sean-k-mooney | the reason nova does this https://github.com/openstack/nova/blob/master/nova/privsep/__init__.py#L24 | 21:22 |
| sean-k-mooney | pypath=__name__ + '.sys_admin_pctxt', | 21:22 |
| sean-k-mooney | is to rescrit the path that can be loaded to only the code within nova.privsep | 21:22 |
| sean-k-mooney | but we do still have oslo adn some other standard libs improted into the privsep process too | 21:24 |
| sean-k-mooney | clarkb: just on the buffer bloat issues | 21:25 |
| sean-k-mooney | clarkb: i know that either glance or cidner had issues with large buffes related to images and they were able to reduce memory usage by adding some explict python gc calls | 21:26 |
| clarkb | fwiw I think cinder backup's memory problems were due to buffers growing like that too. I don't know if they ever fixed it or just removed the service from the default devstack installation | 21:26 |
| opendevreview | Ivan Anfimov proposed openstack/openstack-manuals master: install-guide: Add 2025.1 release https://review.opendev.org/c/openstack/openstack-manuals/+/947060 | 21:27 |
| sean-k-mooney | oh maybe it was swift | 21:28 |
| fungi | does swift even use privsep? | 21:29 |
| sean-k-mooney | not that i know of | 21:29 |
| opendevreview | Ivan Anfimov proposed openstack/openstack-manuals master: install-guide: Add 2025.1 (Epoxy) release https://review.opendev.org/c/openstack/openstack-manuals/+/947060 | 21:29 |
| sean-k-mooney | i just remober dicussign adding gc.collect()? calls in teh past | 21:29 |
| sean-k-mooney | to deal with memory usage growing over time | 21:30 |
| fungi | a | 21:30 |
| fungi | ah | 21:30 |
| clarkb | functools lru_cache is another common cause of leaks when used with object methods | 21:32 |
| clarkb | it creates a leak of the object if the object would otherwise be GC'd because the self argument is part of the method signature andbecomes part of the cache key | 21:33 |
| sean-k-mooney | clarkb: that is one we shoudl check nova for but my food has arrived so im gong to go eat. | 21:34 |
| sean-k-mooney | i wonder if it woudl be worth adding a gc.collect to privsep on every nth call | 21:35 |
| sean-k-mooney | could be interestign to jsut see if that makes any differnce in ci | 21:35 |
| opendevreview | Ivan Anfimov proposed openstack/openstack-manuals master: install-guide: Add 2025.1 (Epoxy) release https://review.opendev.org/c/openstack/openstack-manuals/+/947060 | 21:59 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!