| cardoe | We've spoken before about seperate service accounts per service. Do we have a spec around that and achieving that? | 02:05 |
|---|---|---|
| frickler | cardoe: the best I have is this spec-in-code I guess https://review.opendev.org/c/openstack/devstack/+/923944/4/lib/keystone | 08:07 |
| opendevreview | Ivan Anfimov proposed openstack/openstack-manuals master: install-guide: 2023.2 Bobcat to End of Life https://review.opendev.org/c/openstack/openstack-manuals/+/948425 | 11:49 |
| opendevreview | Ivan Anfimov proposed openstack/openstack-manuals master: install-guide: 2023.2 Bobcat to End of Life https://review.opendev.org/c/openstack/openstack-manuals/+/948425 | 11:50 |
| opendevreview | Ivan Anfimov proposed openstack/openstack-manuals master: OpenStack packages for RHEL and CentOS - Maintained Releases https://review.opendev.org/c/openstack/openstack-manuals/+/948426 | 11:53 |
| opendevreview | Ivan Anfimov proposed openstack/openstack-manuals master: OpenStack packages for RHEL and CentOS - Maintained Releases https://review.opendev.org/c/openstack/openstack-manuals/+/948426 | 11:57 |
| opendevreview | Ivan Anfimov proposed openstack/openstack-manuals master: OpenStack packages for RHEL and CentOS - Maintained Releases https://review.opendev.org/c/openstack/openstack-manuals/+/948426 | 12:09 |
| opendevreview | Ivan Anfimov proposed openstack/openstack-manuals master: OpenStack packages for RHEL and CentOS - Maintained Releases https://review.opendev.org/c/openstack/openstack-manuals/+/948426 | 12:09 |
| opendevreview | Francesco Di Nucci proposed openstack/openstack-manuals master: docs: rewrite CentOS guide for Stream 9 https://review.opendev.org/c/openstack/openstack-manuals/+/928128 | 12:43 |
| cardoe | frickler: the reason I ask is cause I'm talking to the OpenStack Helm PTL about service accounts and credentials. Today they make an "ironic", "neutron", "nova" service accounts. Then configure ironic to use the "nova" one when talking to nova and the "neutron" when talking to neutron and the "ironic" when doing its own thing. Those "nova" and "neutron" ones are the SAME accounts that the nova and neutron service use. | 14:17 |
| cardoe | I'm trying to explain at the very least what should be done is that each service has its own service account and uses that same service account for all of its operations | 14:18 |
| cardoe | Cause this cross dependency matrix isn't good. | 14:18 |
| cardoe | He's asking me for a spec that promotes this. | 14:18 |
| cardoe | He's linked me to a few neutron and nova docs where they talk about using each other's credentials for access. e.g. in nova when it talks to neutron that you use the neutron account. | 14:19 |
| frickler | cardoe: well to me this is just common sense on how to reduce the attack surface/blast radius of possible compromises. I also don't know where such a spec would get hosted, maybe in the security guide? | 14:21 |
| fungi | we did have cross-project specifications, once upon a time, but those were later replaced by the goals framework | 14:50 |
| fungi | so i suppose we still have them, but we call them "goals" instead of "specs" now | 14:50 |
| fungi | writing a goal about projects using their own accounts and not getting credentials for the accounts belonging to other services sounds worthy of being a stated goal | 14:51 |
| fungi | er, i butchered that sentence, but you get my drift | 14:51 |
| frickler | well except afaict this is not about what projects themselves require (at least I very much hope so), but only about what deployment projects and install guides (suggest to) implement. can still be a goal, but with pretty restricted scope | 15:20 |
| fungi | yeah, deployment project specific, maybe with related guidance for other deployers in the opnstack security guide | 15:21 |
| gouthamr | tc-members: gentle reminder that we have the weekly IRC meeting here in ~58 mins | 16:02 |
| mnasiadka | cardoe: I’m pretty sure all deployment projects are in the same boat - we do what is required - would be nice to get a list which projects support a service persona and include deployment projects work in RBAC goal tracking | 16:11 |
| noonedeadpunk | ++ to that ^ | 16:52 |
| noonedeadpunk | we also add service role along with admin role for a while now. We can drop admin anytime whenever there is a clarity which service can live with only service role | 16:53 |
| frickler | the latter sounds orthogonal to the question which service (config) should have credentials for which account(s) | 16:57 |
| frickler | so maybe some document would be helpful already to just make sure people are all talking about the same thing? | 16:58 |
| gouthamr | ~~ lets get into the meeting ~~~ | 17:00 |
| gouthamr | #startmeeting tc | 17:00 |
| opendevmeet | Meeting started Tue Apr 29 17:00:32 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 |
| frickler | \o | 17:01 |
| spotz[m] | \o/ | 17:01 |
| gmaan | o/ | 17:01 |
| gouthamr | noted absence: g t e m a | 17:01 |
| gouthamr | courtesy ping: bauzas cardoe noonedeadpunk mnasiadka | 17:03 |
| bauzas | here | 17:03 |
| mnasiadka | o/ | 17:04 |
| gouthamr | thank you all for joining, lets get started | 17:05 |
| gouthamr | #topic Last week's AIs | 17:05 |
| gouthamr | 1) Skyline build reproducibility | 17:05 |
| gouthamr | the progress here has been s l o w | 17:06 |
| gouthamr | fungi and wu_wenixang__ confirmed that the core reviewers were on the ML and we stated that we'd prefer discussing the SBOM issue on the original ML post.. i'll bump it up this week | 17:07 |
| gouthamr | 2) Grenade test job update/progress | 17:07 |
| gouthamr | gmaan: was there anything new that happened this week? | 17:07 |
| cardoe | o/ | 17:08 |
| frickler | shouldn't that topic be finished for this cycle? | 17:08 |
| cardoe | Guess I should have come in quietly in the back. | 17:08 |
| fungi | yeah, i'm on a conference call right now but happy to talk about sbom stuff async later | 17:08 |
| frickler | cardoe: just sit down now ;) | 17:09 |
| * gouthamr hands cardoe the tardy slip :D | 17:09 | |
| gmaan | sorry, for late response | 17:09 |
| gmaan | nothing news from me on grenade things | 17:09 |
| spotz[m] | Hey I've forgotten until the last 10 minutes so...:) | 17:09 |
| gmaan | but I think all grenade jobs are setup correctly. I will check heat/ironic/manila one today if anything needed | 17:09 |
| cardoe | So skyline is a bit similar IMHO to some of the other container bits I've wanted to bring up. | 17:09 |
| gouthamr | gmaan: ack, to recap: we made branch changes on grenade itself, and the test jobs we setup should automatically start testing E-->F, and SLURP jobs needn't run on master, temporarily | 17:10 |
| gouthamr | is that correct? | 17:11 |
| gmaan | gouthamr: yes, SLUPR can be run as voting or non voting but up to projects. by default i added to run as voting and project can opt it out if needed | 17:11 |
| gouthamr | ++ thank you.. | 17:12 |
| gmaan | continue running SLURP (N-2 -> N) upgrade helps to avoid or at least know what all breaking things coming up for next SLURP | 17:12 |
| gouthamr | ack | 17:12 |
| gouthamr | 3) VMT resolution | 17:13 |
| gouthamr | #link https://review.opendev.org/c/openstack/governance/+/944817 | 17:13 |
| gouthamr | last call for reviews on this one, there was a change posted last week which pushed out the merge timeline for it | 17:13 |
| gouthamr | so if you had a RC +1 prior, please do check the latest patchset.. if you've already done that, thank you :) | 17:14 |
| fungi | JayF: is the other regularly active vmt member who hasn't +1'd the latest patchset | 17:14 |
| gouthamr | ty, next AI is to begin working on the changes suggested.. starting with TC liaisons | 17:15 |
| gouthamr | bauzas indicated that he'd like to be a TC liaison, i can be one too.. in my copious free time :) | 17:15 |
| gouthamr | is there any other TC member that wants to be a liaison instead? | 17:16 |
| JayF | +1 in spirit 😄 | 17:16 |
| spotz[m] | hehe | 17:17 |
| bauzas | bear with me ;-) | 17:17 |
| fungi | note that it should be sufficient to just document it somewhere (could even be in the liaisons wiki) so that vmt members know who to reach out to if we're having trouble getting anything from the project leaders | 17:17 |
| gouthamr | yeah, that's where i was thinking | 17:18 |
| fungi | doesn't need to be super formal, just need to know where we should look | 17:18 |
| gouthamr | okay, ty bauzas++ you're it, i'll update the wiki once the resolution merges.. we can chat about the rest of the changes here or in #openstack-security | 17:20 |
| gouthamr | 4) Move PTG AIs to tracker | 17:20 |
| noonedeadpunk | o/ | 17:20 |
| gouthamr | i'm a slacker here, some of them are there.. others, including unassigned ones don't figure here | 17:21 |
| gouthamr | will move them and bug folks appropriately.. | 17:21 |
| gouthamr | 5) Chat with ianychoi/seongsoo to clarify i18n team’s requests and concerns, chat with rosmaita about the openstack.weblate.cloud 's context/history | 17:22 |
| gouthamr | ^ this is ongoing in private, unfortunately, because some payments etc are being discussed | 17:22 |
| gouthamr | but i can give you a summary: we identified the limits in the hosted weblate, and are exploring what options exist | 17:23 |
| gouthamr | do we pay more as we complete the migration, if yes, how much? (we = openinfra foundation) | 17:24 |
| gouthamr | who do we work with to get any unadvertised offers to reduce said payment | 17:24 |
| gouthamr | in parallel, i18n SIG members are looking to reduce "source strings" that count towards this limit - on how/why, we'll need to pick their brains on the subject | 17:26 |
| noonedeadpunk | that would be really nice to figure out sooner then later | 17:26 |
| noonedeadpunk | as we are already doing transition for a while and it feels that we're running out of time overall | 17:26 |
| spotz[m] | Speaking of translation, docs has an issue to add tags in. I've been holding off on it as I know there have been concerns with the team not being able to keep up. And I don't mean that in a bad way but can't think of better wording for more tags then translations | 17:27 |
| gouthamr | true, i can press on this need.. from what i know, the SIG lacks members, so if you are willing to help, or know anyone that is, it might help spread the load! | 17:27 |
| noonedeadpunk | (not saying that some things would be nice to add for translation, but we don;t to reduce amount of things to migrate) | 17:27 |
| gouthamr | spotz[m]: oh, what tags? | 17:27 |
| spotz[m] | Let me look I was trying to keep those as unread | 17:28 |
| gouthamr | ty | 17:28 |
| gouthamr | alright, that's all the AIs i was tracking | 17:29 |
| gouthamr | does anyone else have any? | 17:29 |
| spotz[m] | This might be it https://review.opendev.org/c/openstack/openstack-manuals/+/947059?usp=email | 17:29 |
| spotz[m] | No I thought it was .po files this is .py | 17:30 |
| spotz[m] | Still looking | 17:30 |
| gouthamr | okay.. | 17:30 |
| gouthamr | #topic Affiliation changes | 17:30 |
| gouthamr | gmaan: i'll put you on the spot for an announcement | 17:30 |
| gmaan | yeah | 17:31 |
| gmaan | I would like to share about my affiliation change. I joined Redhat yeaterday. | 17:31 |
| spotz[m] | Maybe I imagined it:) | 17:31 |
| frickler | spotz[m]: were you referring to https://review.opendev.org/c/openstack/openstack-manuals/+/947180 vs. https://review.opendev.org/c/openstack/openstack-manuals/+/947256 ? | 17:32 |
| frickler | gmaan: congrats | 17:32 |
| gmaan | as we have org diversity requirement, I would like gouthamr to check those and let me know next step if any change needed for my term | 17:32 |
| spotz[m] | frickler: you rock, yes! | 17:33 |
| gouthamr | gmaan: congratulations and welcome to Red Hat, you broke the internet with the nick and email changes at the same time :D | 17:33 |
| gmaan | frickler: thanks | 17:33 |
| fungi | i want to say as of the last tc election there could have been one more rh employee without exceeding 50%, but good to double-check that | 17:33 |
| gouthamr | fortunately, no.. we are still in compliance with the TC's diversity requirement | 17:33 |
| gmaan | yeah, as I changed my email id so though of changing the irc nick etc. but sorry for breaking the scripts. I thought changing primary email in gerrit will work fine | 17:34 |
| spotz[m] | Welcome gmaan | 17:34 |
| gmaan | spotz[m]: thanks | 17:34 |
| gmaan | hope all fixed now. | 17:34 |
| gmaan | oh no, this still not merged | 17:34 |
| gmaan | #link https://review.opendev.org/c/openstack/governance/+/948354 | 17:34 |
| gmaan | after this release tooling will be fine | 17:35 |
| gouthamr | bauzas, spotz[m], gmaan and myself are affiliated with Red Hat; and that's 44.4% of the TC | 17:35 |
| frickler | gmaan: you still need to switch to a new .com domain ;) | 17:36 |
| gouthamr | or maybe .ai | 17:36 |
| spotz[m] | I thought .ai was going away? | 17:36 |
| gmaan | frickler: I just subscribed to old one 1 week before so I will continue that for a year and see if I can get new one :) | 17:37 |
| gouthamr | :P jokes aside | 17:37 |
| gmaan | do not want to waste my $40 :P | 17:37 |
| gouthamr | a gentle reminder to everyone to please keep their affiliation data on OIF Foundation profiles up to date | 17:38 |
| gouthamr | you'd probably also update x/stackalytics if you care to.. | 17:39 |
| gouthamr | that's all there was to $topic | 17:39 |
| fungi | affiliation changes in the openinfra foundation profiles should get picked up automatically by openstack.biterg.io (though it's down at the moment due to an intersection of scheduled maintenance and mass power outages in spain) | 17:40 |
| gouthamr | #topic Activity of SIG groups | 17:40 |
| gouthamr | ack fungi | 17:40 |
| gouthamr | noonedeadpunk: you added this topic, and seeded a couple of questions to the meeting: | 17:40 |
| gouthamr | 1) How do we track if SIG is active or not | 17:41 |
| gouthamr | 2) How we can enable interested people to get into SIG to continue maintenance if SIG is inactive | 17:41 |
| gouthamr | was this motivated by any examples? | 17:41 |
| gouthamr | #link https://governance.openstack.org/sigs/ | 17:41 |
| noonedeadpunk | ah, yes, I did last week | 17:41 |
| frickler | iiuc the ansible sig? | 17:41 |
| noonedeadpunk | So eventually the folk came to osa channel seeking for help with ansible-collections-openstack sig | 17:42 |
| noonedeadpunk | yes | 17:42 |
| gouthamr | ah, you were trying to reach sshnaidm | 17:42 |
| noonedeadpunk | well, not specifically | 17:42 |
| noonedeadpunk | so the thing is that there quite some contributions coming to the repo | 17:42 |
| noonedeadpunk | but really no review activity | 17:42 |
| fungi | i've gotten recent questions about whether the scientific sig is still active too | 17:42 |
| noonedeadpunk | with that - there's no really established proicess of adding new members to the sig | 17:43 |
| gouthamr | very much, i think :) were you able to direct the enquiries, fungi? | 17:43 |
| gouthamr | noonedeadpunk: yes | 17:43 |
| fungi | i pointed folks to the list of chairs for the sig, but i think they're all (or almost all) gone from the community now | 17:43 |
| noonedeadpunk | so even if there're interested parties to step in with maintenance - they don't have much chance | 17:43 |
| fungi | yeah, that's the problem with sigs going inactive is the chairs are the only points of contact in many cases, and once they're gone it's unclear how newcomers can get involvd | 17:44 |
| gouthamr | fungi: i pleasantly discovered that the scientific SIG was celebrating its 10th anniversary and is quite active, except they're not like an openstack project team and don't talk a ton on OFTC | 17:44 |
| noonedeadpunk | yeah, right | 17:44 |
| gouthamr | fungi: here's their Slack: https://join.slack.com/t/os-scientific-sig/shared_invite/zt-34akzhxia-J4DDSoGY0wLnh9aoNxqqlA | 17:44 |
| fungi | oh cool, thanks! | 17:45 |
| bauzas | ya the main issue is that they don't use IRC | 17:45 |
| fungi | i'll pass that along | 17:45 |
| bauzas | again a slack issue | 17:45 |
| opendevreview | Merged openstack/governance master: Updating Ghanshyam email/irc name https://review.opendev.org/c/openstack/governance/+/948354 | 17:45 |
| fungi | there was also discussion about whether we can get the scientific sig and large-scale sig connected to one another, since there seems to be some overlap in interests for the hpc space in particular | 17:45 |
| * gouthamr imagines that headshake | 17:45 | |
| fungi | (hpc now being considered synonymous with ai) | 17:46 |
| noonedeadpunk | but I wonder if ansible sig is a little bit more unique in terms of having a deliverable | 17:46 |
| fungi | the tact sig has a lot of git repos, the security sig has some too | 17:47 |
| noonedeadpunk | ok, yes, right | 17:47 |
| spotz[m] | They were one of the groups Julia refered to from conversations at OpenInfra Days NA | 17:47 |
| gmaan | in past, we used to check SIG meeting happening or not but that should not be the criteria to consider them as inactive | 17:47 |
| fungi | the packaging sig did" i don't know whether they still do though | 17:47 |
| gouthamr | fungi: sometimes, foundation staff - like yourself/ttx/helena/aprice/diablo_rojo/jimmymcarthur seem to know how to find people.. but, its an unsustainable way to connect with people, i agree | 17:47 |
| noonedeadpunk | I think the main pain point - if how to get new members onboarded if chair is not active more or less | 17:48 |
| gouthamr | noonedeadpunk: we have a list: https://governance.openstack.org/tc/reference/sig-repos.html | 17:48 |
| gmaan | I see 'k8s' 'Hardware Vendor' 'First contact' 'cloud research' 'automation' and maybe few more have no activities? | 17:48 |
| fungi | yeah, people were asking other foundation staff members about the scientific sig, and they asked me | 17:48 |
| noonedeadpunk | https://opendev.org/openstack/ansible-plugin-container-connection this looks completely abandoned | 17:49 |
| noonedeadpunk | but also it looks like osa related under ansible sig.... | 17:49 |
| spotz[m] | I'll also say we're about to announce RDO Epoxy, but we desperately need packagers if there is going to be a Flamingo | 17:49 |
| spotz[m] | Or I should say RPMs | 17:50 |
| gmaan | I think we should initiate the separate email about each SIG which we do not find activity or no response from listed chairs. | 17:50 |
| mnasiadka | Well, Scientific SIG is alive - if there’s any need for relaying information - I can help. But I agree we should have some process in place for having a responsive chair or current contact details. | 17:50 |
| gmaan | that at least can refresh the chair list if SIG still needed or to more moved to 'advisory' or 'completed' status | 17:51 |
| fungi | spotz[m]: i thought rdo had said they were moving to just slurp releases? | 17:51 |
| spotz[m] | The 2 engineers who were packaging moved to new roles:( We've talked about it in meetings but no one but us went to them | 17:52 |
| gouthamr | so teh questions remain, i think it'd be useful if there was a proposal | 17:52 |
| noonedeadpunk | I can recall Neil saying smth about help, but not sure | 17:52 |
| spotz[m] | He came to one meeting | 17:53 |
| gouthamr | noonedeadpunk: have you had any thoughts around changing the situation and answering the two questions you posed? | 17:53 |
| noonedeadpunk | no, not really. Pretty much the reason I raised as I had lack of good ideas | 17:53 |
| noonedeadpunk | And I'd say I was trying to think about these for some time now | 17:53 |
| mnasiadka | Kolla basically uses only a couple of packages from RDO build deps - I can check which ones… if RDO is going to disappear… | 17:54 |
| noonedeadpunk | osa uses a whole distro path based on rdo fwiw | 17:54 |
| gouthamr | okay, that looks like a tangent that we shouldn't go into.. | 17:54 |
| gouthamr | i mean, please discuss RDO challenges as a separate topic for next week if you'd like | 17:55 |
| noonedeadpunk | ++ | 17:55 |
| fungi | though osa and kolla also support other distros, if sticking with a particular deployment tool is more important to users than sticking with a particular distro | 17:55 |
| spotz[m] | We can talk afte | 17:55 |
| noonedeadpunk | so I guess I wanted to raise that and gather opinions on possible solutions | 17:55 |
| noonedeadpunk | I can do a writing part and combine thoughts together | 17:55 |
| gouthamr | we could try to update stale info, to begin with | 17:55 |
| noonedeadpunk | but I struggle to find solution on myself, so was hoping on some collaborative effort :) | 17:56 |
| gouthamr | and probably add links if they're missing on "how do i join this SIG" | 17:56 |
| gouthamr | its a big problem that we can chip away in small pieces | 17:56 |
| spotz[m] | Could do quarterly updates, or updates when we have elections? | 17:57 |
| noonedeadpunk | what is more tricky, is that not each sig are equal somehow | 17:57 |
| noonedeadpunk | as one do have deliverables, while others do not | 17:58 |
| gouthamr | spotz[m]: yes, and probably an initial push now to fix stale info.. if it helps, we can have folks join TC meetings with short updates: "Meet SIG X, and know their updates" | 17:58 |
| gmaan | yeah but having active and up to dated list of chairs is helpful | 17:58 |
| noonedeadpunk | indeed | 17:58 |
| bauzas | agreed | 17:58 |
| noonedeadpunk | but how chairs are assigned? | 17:58 |
| gouthamr | ++ lets work on that part first; ty for bringing this concern, noonedeadpunk | 17:58 |
| noonedeadpunk | as they are not taking part in elections? | 17:58 |
| noonedeadpunk | so maybe we need to add SIG chair to elections? | 17:59 |
| gmaan | who ever volunteer is added in that list | 17:59 |
| noonedeadpunk | which would highlight a) activity b) if it's relevant? | 17:59 |
| gouthamr | no, https://governance.openstack.org/tc/reference/comparison-of-official-group-structures.html | 17:59 |
| fungi | at least in the sigs i'm involved in, anyone who wants to volunteer to be a chair can. i'm the sole chair of two sigs right now and have repeatedly stated for years that i's appreciate volunteers to help or relieve me entirely | 17:59 |
| gmaan | it is more of up to SIG members to agree on the chair | 17:59 |
| spotz[m] | No but we ask the SiGs and WG for ATC suggestions, admitedly we've been bad on that for years | 17:59 |
| spotz[m] | We used to send thm to TOm if that answers how bad we've been:) | 18:00 |
| gmaan | like we do for DPL, having a reset and checks for up to dated list is no harm | 18:00 |
| gouthamr | i wouldn't put the process of elections on short/long term groups like this | 18:00 |
| gmaan | yeah. election are not needed as such | 18:00 |
| noonedeadpunk | `which are not directly responsible for producing components of the “OpenStack” software release` -> does ansible SIG really goes under this criteria specifically? | 18:00 |
| gouthamr | "SIGs can own git repositories and produce software, but that software will be considered add-on software to the main “OpenStack” software releases. " | 18:01 |
| gmaan | and 'reset' can be just check them via email, irc etc | 18:01 |
| bauzas | time check, I need to leave | 18:01 |
| gouthamr | yes | 18:01 |
| gouthamr | we're a bit over, apologies | 18:01 |
| gouthamr | let's end this meeting here | 18:01 |
| fungi | are the repositories that the ansible sig manages official deliverables of openstack? shouldn't be possible governance wise | 18:01 |
| noonedeadpunk | yeah, right, sorry :) | 18:01 |
| gouthamr | sorry, but some topics will be pushed to next week | 18:02 |
| gouthamr | which is a Video+IRC meeting | 18:02 |
| gouthamr | i'll share details as usual | 18:02 |
| gouthamr | anything else to add to the minutes today? | 18:02 |
| noonedeadpunk | fungi: it's where things get nasty | 18:02 |
| noonedeadpunk | I'll add after the end:) | 18:02 |
| gouthamr | thanks everyone | 18:03 |
| gouthamr | #endmeeting | 18:03 |
| opendevmeet | Meeting ended Tue Apr 29 18:03:24 2025 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 18:03 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/tc/2025/tc.2025-04-29-17.00.html | 18:03 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/tc/2025/tc.2025-04-29-17.00.txt | 18:03 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/tc/2025/tc.2025-04-29-17.00.log.html | 18:03 |
| gouthamr | noonedeadpunk: continue please :) | 18:03 |
| fungi | i won't be around for next week's meeting (work travel), but can try to catch up in irc if there are questions for me | 18:03 |
| noonedeadpunk | fungi: so it was made as a sig to avod licensing issues | 18:03 |
| gouthamr | fungi: ack | 18:03 |
| fungi | https://opendev.org/openstack/governance/src/branch/master/reference/sigs-repos.yaml#L3-L5 lists two repos | 18:04 |
| noonedeadpunk | as there were concerns that importing GPL3 code into modules, which is required to produce ansible module, requires to be licensed with GPL as well | 18:04 |
| fungi | in theory those are openstack community managed resources, not official openstack deliverables | 18:04 |
| noonedeadpunk | so it was made aside just to not cause any troubles with that | 18:04 |
| noonedeadpunk | openstack/ansible-plugin-container-connection - we should drop this one, imo | 18:04 |
| noonedeadpunk | I have very little idea how it happened to be there... | 18:05 |
| clarkb | and the other is part of ansible + openstack integration which isn't part of the opensdtack release as far as i Know | 18:05 |
| noonedeadpunk | it's not part of the release | 18:05 |
| noonedeadpunk | but it's very related to the versions of sdk | 18:06 |
| fungi | yeah, it's client tooling essentially, for people who want to manage openstack resources with ansible playbooks | 18:06 |
| noonedeadpunk | and very dependant on them | 18:06 |
| noonedeadpunk | but so is CLI and SDK? | 18:06 |
| clarkb | sure but thats no different than opesntack being dependent on python | 18:06 |
| clarkb | you can depend on things and not be part of their release | 18:06 |
| noonedeadpunk | as openstack are APIs and CLI is a convenience | 18:06 |
| fungi | cli and sdk are openstack deliverables maintained by an official project team | 18:07 |
| noonedeadpunk | I know. and that is pretty much the point, that in their core - they are kinda alike | 18:07 |
| fungi | anyone can write software that talks to openstack and host it wherever they like. in this case it's done in the context of an openstack sig, but it could just as well be some random maintainer(s) on github | 18:07 |
| fungi | not all software that interacts with openstack needs to be officially governed by an openstack project team and participate in the coordinated release | 18:08 |
| noonedeadpunk | um, but should not be this a protected trademark? https://galaxy.ansible.com/ui/namespaces/openstack/ | 18:08 |
| noonedeadpunk | as it's owned by ex sig chair | 18:09 |
| noonedeadpunk | afaik | 18:09 |
| clarkb | I'm not an IP lawyer but my understanding is you can use non stylized names to accurately refer to things | 18:09 |
| fungi | https://www.openstack.org/brand/ | 18:09 |
| fungi | the "Community Organizers & Non-Commercial Use" section is probably relevant | 18:09 |
| clarkb | if you provide tooling to communicate to or integrate with openstack using the term openstack is probably fine in that content. But you can't use the logo or stylized version of the name. But also ^ there are guidelines and I'm not a lawyer | 18:10 |
| noonedeadpunk | ok, so basically your solution for non-active sig or absent reviews is to fork the repo? | 18:10 |
| fungi | the tc (formerly the meta-sig which was comprised of tc+uc members before the uc was folded into the tc) governs all sigs, and can reassign access to any of those resources | 18:11 |
| noonedeadpunk | yes, right, so pretty much I wanted to see if it's possible to establish some process which seems to be missing now | 18:11 |
| gouthamr | yeah, my preference would be to re-staff the said SIG if there's interest | 18:12 |
| fungi | if someone wanted to take over maintenance of the openstack/ansible-collections-openstack repo and the tc decided that it was basically abandoned or mismanaged, then they could choose to amend or replace the list of maintainers with new volunteers | 18:12 |
| spotz[m] | Staff the meta-sig? | 18:12 |
| fungi | staff the ansible sig, i think | 18:12 |
| spotz[m] | Ahh | 18:12 |
| noonedeadpunk | to asses and be able to have some sort of criteria when a flag needs to be raised | 18:13 |
| fungi | sounds like a great idea to me | 18:13 |
| noonedeadpunk | But also, IMO TF, CLI, SDK, Ansible modules are having huge value for OpenStack | 18:13 |
| noonedeadpunk | As that tends to be a good selling point, on the contrary to developing in-house or forked solution | 18:14 |
| fungi | what is tf? | 18:14 |
| noonedeadpunk | that you will loose all that amazing compatability and community tools | 18:14 |
| noonedeadpunk | openbao :) | 18:14 |
| noonedeadpunk | brrrr | 18:14 |
| gouthamr | ah famously abbreviated as "TF" :D | 18:15 |
| noonedeadpunk | opentofu | 18:15 |
| noonedeadpunk | yes, it is :D | 18:15 |
| clarkb | sure, but there are two common issues there: 1) is people who want to write plugins for that are often more aligned to those tools than to the thing they are writing a plugin for and 2) licensing | 18:15 |
| clarkb | I don't think we should demand it either way and do what works best for the particular ecosystem | 18:15 |
| fungi | openbao seems to be a fork of hashicorp vault | 18:15 |
| clarkb | fungi: teraform is tf which got forked to opentofu | 18:15 |
| noonedeadpunk | fungi: yeah, sorry, I was just dealing with it so mixed things up, meant opentofu | 18:16 |
| fungi | aha, opentofu==terraform | 18:16 |
| fungi | okay, so you're saying some community management of a blessed set of terraform/opentofu modules would be helpful to have? | 18:17 |
| noonedeadpunk | if I'm not mistaken, gtema was involved in that at some point | 18:17 |
| fungi | and yeah, it seems like in general we've seen that people who want to do e.g. terraform support for openstack would rather manage those resources in the communities and infrastructure that the terraform community uses rather than within the openstack community governance and development infrastructure | 18:18 |
| noonedeadpunk | I guess what I meant that it's in project best interest to do everything possible for such toolings to succeed | 18:18 |
| fungi | helping them succeed doesn't necessarily mean taking control of and governing them | 18:19 |
| noonedeadpunk | Well, Ansible comminity goes in different direction and tries to push responsibility for modules and plugins to projects which they are for | 18:19 |
| noonedeadpunk | and that what happened in ansible 2.10? when this sig was established, when openstack modules were dropped from core... | 18:20 |
| noonedeadpunk | anyway | 18:20 |
| clarkb | right I think its ok for ansible dev to happen within openstack if that is what people prefer and tf/opentofu def to happen with tf/opentofu if that is what they prefer | 18:21 |
| fungi | i thought there was an ansible community that hosted non-core resources collectively | 18:21 |
| clarkb | its about meeting the tools and communities where they want to be and not about openstack having one method for everything | 18:21 |
| clarkb | then additionally there may be licensing concerns | 18:22 |
| noonedeadpunk | fungi: so pretty much ansible.community is bunch of stuff that was dropped from the core and not claimed by anyone. And it's barely maintained at the moment from what I've heard | 18:22 |
| fungi | yeah, sigs seem fine for that. the people maintaining those resources can do it in a way that's affiliated with openstack and hosted in the same development systems but not governed by the rigor or limits of official project teams | 18:22 |
| clarkb | liek I personally don't think openstack should be on the hook for integration with proprietary tooling. That is typically pushed onto the proprietary system devs (and is something that I think has largely worked over time) | 18:22 |
| fungi | it sounds like the problem in this specific case is that the people who had previously been interested in managing that repository disappeared and didn't leave any succession plan to hand off maintenance to someone else | 18:24 |
| noonedeadpunk | ok, sorry, I somehow struggle to understand where this discussion is going to. As eventually a person came in and flagged that they have no point of contact and don't know what to do to get their bug fix reviewed | 18:24 |
| noonedeadpunk | fungi: exactly | 18:24 |
| noonedeadpunk | but my guess is that situation is not unique overall | 18:25 |
| fungi | the openstack tc is the point of contact of last resort, and has the authority to take or delegate control to whoever they like | 18:25 |
| clarkb | oh I thought you were saying someone started maintaining a fork (hence the trademark question) | 18:25 |
| noonedeadpunk | no, not really | 18:25 |
| clarkb | and I was trying to say I think that is ok if htat is what makes sense for that community | 18:25 |
| noonedeadpunk | it's more that this namespace is under sig, but access to used to be personalized by ex sig chair that is not active anymore | 18:26 |
| noonedeadpunk | but yes, again, tc probably has authority, but we have no clue how and more imporantly when to excersice it | 18:28 |
| noonedeadpunk | which is where I was coming from :) | 18:28 |
| fungi | makes sense, and it's up to the tc members collectively to decide the how and when | 18:29 |
| noonedeadpunk | right | 18:29 |
| noonedeadpunk | but all my ideas were too rtestricitve to be applied to sigs | 18:29 |
| JayF | gmaan: congratulations on the new role | 18:30 |
| gmaan | JayF: thanks | 18:31 |
| fungi | noonedeadpunk: could be something as basic as proposing a governance-sigs change to update the chairs to new volunteers and asking the tc to vote on that review | 18:31 |
| gouthamr | yeah | 18:32 |
| mnasiadka | Well, that’s the fastest path to get it tidied up. | 18:33 |
| fungi | one of the hallmarks of the sig model was that it was intended to be simple and low-maintenance with as little bureaucracy as possible | 18:33 |
| gouthamr | a good first step; and then follow that up with the improvment you wanted: how does one join | 18:33 |
| fungi | once the chairs are updated, i'm happy to use gerrit admin perms to add the new chairs to the corresponding groups for access | 18:34 |
| gouthamr | my thought is akin to the community goal we all did at one point to create a "So you want to contribute" page.. we could drive all SIGs to have a one pager _somewhere_ which lists info on how to join/help | 18:35 |
| clarkb | at a higher level I think we (openstack) should maybe be more explicit that the broader community intends on maintaining software as long as their is interest and inactive maintainers may be supplemented by new interest parties | 18:35 |
| gouthamr | we are | 18:35 |
| clarkb | ya I think this has been the case through action but it may not be apparent to say newer groups like skyline that if tehy stop maintaining things in six months that if someone shows up 3 months after that they are tag you're it now | 18:36 |
| gouthamr | ah, are you thinking spell it out in the TC charter? | 18:36 |
| gouthamr | or the project team guide? | 18:37 |
| clarkb | probably more the project team guide | 18:37 |
| clarkb | fundamentally we're all stewards of community assets for lack of a better term. And intend on perpetuating that situation (I'm speaking for my self here but I Think the community has acted in this way over time too) | 18:38 |
| gouthamr | agreed | 18:38 |
| gouthamr | in https://docs.openstack.org/project-team-guide/repository.html perhaps? | 18:39 |
| clarkb | https://docs.openstack.org/project-team-guide/open-development.html or here? basically call out that there are ptls and core reviewers but they are stewards? I dunno it may also be overkill | 18:41 |
| clarkb | I think in most situation this has come up people are grateful someone else is stepping in and happy for it | 18:41 |
| mnasiadka | One thing is a mention how you can step up or calm out that a project/repo lacks maintainers - second thing SIG is not really a project team (so maybe doesn’t fit in project teams guide) | 18:44 |
| mnasiadka | Err, *call out | 18:44 |
| mnasiadka | Coming back to Ansible SIG - for me it’s sort of an important deliverable (like openstacksdk) but for people using Ansible - having that namespace not under OpenStack control reminds me of that pypi projects ownership problem | 18:46 |
| JayF | It's also worth noting we do have some openstack applications -- like bifrost -- which use ansible | 18:47 |
| JayF | https://opendev.org/openstack/bifrost/src/branch/master/ansible-collections-requirements.yml | 18:48 |
| mnasiadka | Kolla-Ansible also uses this collection, OSA probably as well | 18:53 |
| fungi | mnasiadka: it's in the openstack/ git namespace on opendev, so under openstack (tc) control | 18:53 |
| fungi | it's attributed to a sig rather than being an official deliverable, and the story behind that choice seems to mainly be an attempt to satisfy https://governance.openstack.org/tc/reference/licensing.html | 18:55 |
| clarkb | fungi: I think they are referring to the namespace on ansible galaxy (but yes confusing) | 18:56 |
| fungi | oh, got it | 18:56 |
| mnasiadka | Ah right, Ansible and GPL3 requirements - https://docs.ansible.com/ansible/latest/community/collection_contributors/collection_requirements.html#collection-licensing-requirements | 18:59 |
| fungi | an alternative would be to amend the tc licensing guidelines to include an exception for client integration tooling or some such | 19:01 |
| fungi | though i think that would involve a chat with the board and/or foundation legal to confirm (it did in the past anyway) | 19:02 |
| fungi | for example, back when there was still an infrastructure team and zuul added its ansible launcher, it needed to start shipping some (non-linked, so not an apache license conflict) gpl3 modules. that's when the "Projects run as part of the OpenStack Infrastructure" exception was approved | 19:07 |
| fungi | spotz[m]: https://review.opendev.org/c/openstack/project-config/+/948033 is probably relevant to the earlier rdo discussion too | 19:36 |
| noonedeadpunk | I'm actually not 100% about original assesment of GPL3 | 20:12 |
| noonedeadpunk | As importing of GPL3 code likely does not lead consequence of licensing your code as GPL3 | 20:12 |
| noonedeadpunk | Ie ansible-lint, molecule and some other tooling in the ecosystem are distributed with MIT | 20:12 |
| noonedeadpunk | But it really needs lawyer view | 20:13 |
| noonedeadpunk | Maybe our new LF friends can help us out clarifying this thing... | 20:13 |
| noonedeadpunk | Also each time I poked Ansible community managers or product managers from RH - they were not sure in that either | 20:17 |
| opendevreview | Goutham Pacha Ravi proposed openstack/project-team-guide master: Add notes on reviving projects/deliverables https://review.opendev.org/c/openstack/project-team-guide/+/948484 | 20:18 |
| noonedeadpunk | As I think important difference, is that we do not re-distribute the original code, we import it from it's origin. But again - not a lawyer | 20:18 |
| clarkb | noonedeadpunk: MIT is not viral. GPL is | 20:36 |
| clarkb | it depends entirely on the license and in many cases interpretation as there are all sorts of exceptions | 20:37 |
| clarkb | for example mysql has an exception | 20:37 |
| fungi | well, also mit/expat and gpl3 are compatible licenses anyway. linking exceptions are generally used to remove certain privisions of a license under specific uses, for example to address license incompatibilities | 20:44 |
| fungi | the current mysql example is at https://oss.oracle.com/licenses/universal-foss-exception/ | 20:46 |
| gtema | for those still reading on the ansible-collections-openstack: I would be strongly against TC simply setting other people as cores. Historically there were no people staying with Ansible for the long term (except very few cases). Every time someone new appears and claims to have interest that interest disappears after the change (or 2) has been merged. There are way to many corner cases in the Ansible world which those pass-by people have no | 21:00 |
| gtema | idea of. This is not the way to handle the situation | 21:00 |
| fungi | so instead the tc should declare it abandoned and retire it? | 21:01 |
| JayF | gtema: you basically want to treat it like we would a project team instead of a sig, which is super reasonable given we use the libraries in the same way we would a project | 21:02 |
| fungi | sounds like you're suggesting that it's untenable and we should give up any hope of hosting it in the openstack community | 21:02 |
| JayF | it sounds like if this were held to a project team standard, it'd be "inactice"? | 21:02 |
| JayF | **inactive | 21:02 |
| gtema | it is not abandoned. When I am pinged I am trying to spend time there. It just that I have no free time (nor direct interest anymore) to keep it on the radar permanenty. | 21:03 |
| gtema | Honestly I also have an idea of redoing modules following the openapi work - generating all the modules automatically | 21:03 |
| fungi | oh, then you are a (and perhaps the only) maintainer, so it's at least somewhat maintained | 21:03 |
| fungi | noonedeadpunk made it sound like nobody with access to it was involved any more | 21:04 |
| gtema | yes, it is indeed somewhat maintained | 21:04 |
| gtema | that is not very corect | 21:04 |
| gtema | cardoe recently started pushing changes which I was reviewing so if he would be having more interest in spending some more time - welcome | 21:05 |
| cardoe | I think it'd be great if all the modules were auto generated. | 21:05 |
| fungi | maybe you'd be okay being the chair for the ansible sig, more so if it became just the ansible collections sig? | 21:05 |
| cardoe | I'm trying to fix up some keystone usage but it's honestly just a short term fix for me as we move to a Kubernetes operator. | 21:05 |
| gtema | sure, it is just that my other point was perhaps to investigate using Rust in ansible modules, since Ansible is just terribly slow | 21:06 |
| gtema | otherwise the problem with the auto-generation is that you can only generate it when your underlaying SDK is also completely auto-generated. Otherwise you do not have 100% standardized interface | 21:07 |
| fungi | ansible modules can just be thin python wrappers around compiled binaries in any language can't they? | 21:07 |
| gtema | the alternative was to get rid of openstacksdk (except of maybe config reading) and just generate it purely to use API directly | 21:07 |
| gtema | fungi - technically yes. | 21:08 |
| cardoe | well openstacksdk is a bit inconsistent as well some stuff uses the service proxies and some doesn't | 21:08 |
| gtema | but you need to have a way of ensuring the binary is installed on the target | 21:08 |
| gtema | I had a plan to more or less exactly wrap usage of rust cli by ansible - just never got time to work also on that - too many open things | 21:08 |
| gtema | cardoe - that is exactly where I stopped playing with the idea of generating ansible modules relying on openstacksdk | 21:09 |
| JayF | What do you mean 'service proxies' in this context? | 21:13 |
| gtema | for every service there is a dedicated proxy in sdk and those are not 100% following same rules (mostly because openstack services are not following same rules) - as such you have a bit mixed interface between services that is not consistent | 21:15 |
| gtema | microversion handling is another beast in the Ansible module context | 21:16 |
| JayF | Ah, okay. Implementation detail thing :) | 21:18 |
| * JayF was afraid Ironic was missing a thing | 21:18 | |
| gtema | bit more than that. cli is more or less just exiting informing the user that what he requests is not possible with the MV supported by the cloud potentially leaving ways to influence which MV to use. In Ansible (since this is a strongly non-interactive invocation) there is no way for that | 21:19 |
| gtema | microversions are evil, they should have never existed | 21:20 |
| JayF | I disagree, but I'm a grumpy operator who appreciates we don't break old stuff and not an API designer or SDK developer :) | 21:21 |
| gtema | you break, you just do not know about that. When parameter type is changed with MV it is not acceptable, but this is the reality | 21:21 |
| JayF | I would be surprised if we have anything (at least recently) in Ironic that's inconsistent in the same version. We have tried /really hard/ to enforce it even for mild changes | 21:22 |
| gtema | I was never good at ironic microversions, I am mostly talking about nova MVs | 21:23 |
| * JayF waits for the laundry list of sins to come out ;) | 21:23 | |
| gouthamr | microversions is under the statute of limitations | 21:24 |
| gtema | for sdk/cli maintainer those are insane and only make life more complex than it should be | 21:25 |
| JayF | gouthamr: the only way to fix API sins is to commit more API sins ;) | 21:26 |
| gouthamr | consistency! | 21:26 |
| opendevreview | Goutham Pacha Ravi proposed openstack/project-team-guide master: Add notes on reviving projects/deliverables https://review.opendev.org/c/openstack/project-team-guide/+/948484 | 22:07 |
| spotz[m] | <fungi> "spotz: https://review.opendev...." <- Yeah on that already | 22:26 |
| opendevreview | Ian Y. Choi proposed openstack/election master: Add configuration for 2026.1/"G" elections https://review.opendev.org/c/openstack/election/+/948494 | 22:27 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!