| *** elodilles is now known as elodilles_ooo | 12:47 | |
| gouthamr | tc-members: a gentle reminder that this week's IRC meeting will be hosted here in ~40 minutes. The agenda is here: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Agenda | 16:21 |
|---|---|---|
| dansmith | gouthamr: I have a conflict and will be spotty at best | 16:22 |
| gouthamr | dansmith: ack, np.. | 16:22 |
| fungi | it's got to be the middle of the night over there right now, surprised you're awake enough! | 16:35 |
| fungi | yeah 1am meeting, oof | 16:36 |
| gouthamr | who's in shanghai? :) | 16:37 |
| fungi | oh, for some reason i thought you were | 16:37 |
| gouthamr | nah, i wish i was | 16:37 |
| gouthamr | TheJulia is, and will probably bring back the goss | 16:38 |
| gouthamr | #startmeeting tc | 17:00 |
| opendevmeet | Meeting started Tue Sep 8 17:00:56 2026 UTC and is due to finish in 60 minutes. The chair is gouthamr. Information about MeetBot at http://wiki.debian.org/MeetBot. | 17:00 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 17:00 |
| opendevmeet | The meeting name has been set to 'tc' | 17:00 |
| gouthamr | Welcome to the weekly meeting of the OpenStack Technical Committee. A reminder that this meeting is held under the OpenInfra Code of Conduct available at https://openinfra.dev/legal/code-of-conduct. | 17:01 |
| gouthamr | Today's meeting agenda can be found at https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Agenda | 17:01 |
| gouthamr | #topic Roll Call | 17:01 |
| spotz[m] | o/ | 17:01 |
| frickler | \o | 17:01 |
| gouthamr | Courtesy ping: noonedeadpunk cardoe bauzas | 17:02 |
| gouthamr | noted (somewhat) absence: m nas iadka, dan smith | 17:02 |
| cardoe | o/ | 17:02 |
| noonedeadpunk | o/ | 17:03 |
| noonedeadpunk | sorry | 17:03 |
| gouthamr | alright, thanks for joining.. let's get started. | 17:04 |
| gouthamr | #topic Last Week's Action Items | 17:05 |
| gouthamr | we had a couple that we deferred to discussing today | 17:05 |
| gouthamr | service-types-authority core team refresh | 17:06 |
| gouthamr | frickler and priteau asked this question here a couple of weeks ago, and this spawned a ML post: | 17:06 |
| gouthamr | #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/UNBVEOMWMNAWZBQ5EHCCJCSTPF256JGT/#UNBVEOMWMNAWZBQ5EHCCJCSTPF256JGT ([tc][all] service-types-authority core reviewers' list being refreshed) | 17:06 |
| gouthamr | stephenfin and gtema weighed in that the "os-service-types" (a library that consumes the data published in "service-types-authority") should include core reviewers from the openstack-sdks group | 17:07 |
| gouthamr | should continue to* | 17:07 |
| gouthamr | that's already the case: | 17:09 |
| gouthamr | #link https://review.opendev.org/admin/groups/os-service-types-core,members | 17:09 |
| frickler | well it is a sdk team deliverable, so that should just stay? | 17:09 |
| gouthamr | yes | 17:09 |
| gouthamr | #link https://review.opendev.org/admin/groups/service-types-authority-core,members | 17:09 |
| gouthamr | ^ this is the group we meant to address | 17:09 |
| gouthamr | but, both groups include folks that are no longer active, and they were past api-sig members | 17:10 |
| gouthamr | so any objections from me dropping the individuals, and retaining "tech-committee" (us)? | 17:10 |
| gouthamr | and os-service-types-core will continue to include "openstacksdk-core" (as gtema and stephenfin endorsed) | 17:11 |
| frickler | ack | 17:12 |
| gtema | o/ | 17:13 |
| gouthamr | okay, done: https://review.opendev.org/admin/groups/service-types-authority-core,members | 17:13 |
| gouthamr | i'll need help from someone else (frickler/fungi/gtema) to adjust https://review.opendev.org/admin/groups/os-service-types-core,members | 17:13 |
| gtema | I can do this | 17:14 |
| frickler | done | 17:14 |
| gouthamr | perfect, ty! | 17:14 |
| gouthamr | alright, that's a wrap on that action item | 17:14 |
| gouthamr | the release team flagged a concern with a couple of tacker team deliverables | 17:15 |
| stephenfin | please don't forget to send something to the ML about these changes, just to close the loop / for transparency | 17:15 |
| gouthamr | yes will do stephenfin | 17:15 |
| stephenfin | gouthamr++ ty 🙏 | 17:15 |
| gouthamr | ty for checking and responding! | 17:17 |
| gouthamr | on the tacker team deliverables that seemed unhealthy, was it "tosca-parser" alone? | 17:17 |
| gouthamr | #link https://review.opendev.org/c/openstack/releases/+/1003754 (Force release tosca-parser for Hibiscus) | 17:17 |
| fungi | gouthamr: there was another, hold on... | 17:17 |
| fungi | gouthamr: also python-tackerclient | 17:18 |
| gouthamr | ah! | 17:18 |
| fungi | #link https://meetings.opendev.org/meetings/releaseteam/2026/releaseteam.2026-08-28-14.00.log.html#l-40 | 17:18 |
| fungi | this was based on evaluation of "non-client libraries that did not have any change merged over the cycle" | 17:19 |
| fungi | the release team wants to know if it makes sense to switch them to independent release, or retire them completely | 17:19 |
| gouthamr | i think tosca-parser seems like a good candidate for "independent" | 17:20 |
| fungi | well, also client libs | 17:20 |
| fungi | yes, i think some of the concern is that the team didn't even merge autogenerated patches during the cycle | 17:20 |
| fungi | also yesterday when making rc1 proposals, i came across tacker-horizon which hasn't merged any changes since last cycle either | 17:21 |
| fungi | (it's cycle-with-rc obviously) | 17:21 |
| fungi | since all three of those are assigned to the same team, it rose to the level of potential health concerns | 17:22 |
| gouthamr | "tacker" itself sees meaningful activity: | 17:22 |
| gouthamr | #link https://review.opendev.org/q/project:openstack/tacker+status:merged | 17:22 |
| gouthamr | and from a VMT perspective, we've had responses from the team, although its taken quite some prodding.. | 17:22 |
| fungi | yes, it may be that they are simply ignoring other deliverables that they should consider retiring | 17:23 |
| fungi | or they're simply not aware of the list of deliverable repositories they inherited years ago | 17:24 |
| gouthamr | yasufum isn't on this channel, so i can point this discussion to them, but, probably best to get their response directly on the release changes, or, on the ML | 17:24 |
| gouthamr | > or they're simply not aware of the list of deliverable repositories they inherited years ago | 17:24 |
| gouthamr | yikes | 17:24 |
| frickler | well even tacker has problems with merging stuff like https://review.opendev.org/c/openstack/tacker/+/980672 | 17:24 |
| gouthamr | i can imagine a world where they're on maintenance mode needing no further changes in the client or a parser library | 17:25 |
| gouthamr | but, we can't be sure these deliverables are even able to build and are working? | 17:25 |
| JayF | We should be careful to keep an operator perspective active on this: it doesn't matter if some people are trying; if we aren't successfully maintaining a project we have to consider if it's actually inactive. | 17:26 |
| JayF | Having folks on a roster, even if they are responsive, doesn't guarantee we've got enough time invested in the project to clear the high bar OpenStack sets for our deliverables. | 17:26 |
| fungi | maintenance mode is one thing, i'm more concerned about even the auto-proposed per-cycle changes getting ignored | 17:27 |
| fungi | #link https://review.opendev.org/q/is:open+project:openstack/python-tackerclient+branch:master+owner:infra-root@openstack.org | 17:27 |
| JayF | Yeah, this is what I'm saying. That's pretty clear evidence that the projects are not being well maintained, even if folks are doing their best. Sometimes one person with limited time doing their best is still not good enough. | 17:27 |
| frickler | +1 | 17:28 |
| gouthamr | true, let me raise this to the ML as a project inactivity concern so operators are aware in parallel... | 17:29 |
| gouthamr | did the release team plan to do anything else beyond signalling this to the TC? | 17:29 |
| fungi | again, though, unless a team is adding and removing deliverables they probably don't have occasion to even notice the list of deliverables they're responsible for maintaining, so i wouldn't be surprised if they're simply not aware of them all | 17:29 |
| fungi | elod reached out to them | 17:31 |
| fungi | #link https://meetings.opendev.org/meetings/releaseteam/2026/releaseteam.2026-09-04-14.01.log.html#l-24 | 17:31 |
| gouthamr | ty, that's useful information | 17:31 |
| gouthamr | alright, that's all the ongoing/pending action items i was tracking | 17:32 |
| fungi | looks like he tried to get ahold of someone in tacker's irc channel | 17:32 |
| fungi | and we also subscribe ptls and release liaisons to the release requests we've auto-proposed | 17:32 |
| gouthamr | ack, that didn't help me when alerting folks about launchpad issues - they weren't watching IRC, although yasufum seems to have a bouncer | 17:33 |
| gouthamr | (that = pinging on IRC) | 17:33 |
| gouthamr | before we switch topics | 17:34 |
| gouthamr | a reminder that we've one more week to wrap up the voting phase of the TC elections | 17:34 |
| fungi | 8 days 6 hours | 17:34 |
| gouthamr | i don't know how many votes have been gathered so far, but i'll check in with election officials and maybe they'll send out a reminder | 17:35 |
| gouthamr | if you haven't voted, please do.. and remind others to! | 17:35 |
| gouthamr | were there any other action items to discuss? | 17:35 |
| * gouthamr is holding back from a few that are better to do after we've had a breather - i.e., past RC1 dates | 17:36 | |
| gouthamr | #topic Trouble getting changes in Keystone (cardoe) | 17:37 |
| gouthamr | cardoe, ty for proposing the topic.. the floor is yours | 17:37 |
| cardoe | well there was an item brought up to the foundation about it | 17:37 |
| cardoe | We've also discussed work around the forth coming keystone v4 | 17:38 |
| cardoe | I know that folks were out and a number of meetings around keystone were canceled over the summer. | 17:38 |
| cardoe | But there's a concern from folks that there's no bandwidth even from other cores for reviews to happen to land changes. | 17:38 |
| cardoe | So that's a concern for project health | 17:39 |
| gtema | lemme know once you want to hear (again) my position on that | 17:39 |
| cardoe | and I thought best to bring it to light for the TC to be aware of these concerns | 17:40 |
| cardoe | gtema: go for it. you were one of the folks that said it was difficult to land changes. | 17:40 |
| gouthamr | ack, from personal conversations, the team's been overwhelmed dealing with security vulnerabilities through this release that they haven't done much else | 17:40 |
| gtema | ok, thanks | 17:40 |
| noonedeadpunk | which is fair | 17:40 |
| cardoe | Yeah the security vulnerabilities have dominated this cycle. | 17:40 |
| gtema | right - from the vmt pov the status of the project is more than red - it's black | 17:40 |
| noonedeadpunk | linux kernel lands 2000 security patches in a single release | 17:41 |
| gtema | all of those are caused by the fact that Keystone is an exception to the standard in openstack, it does not benefit from stop-by contribution. It is being hurted | 17:41 |
| noonedeadpunk | so it's not exclusive to keystone or any other project I'd sayu | 17:41 |
| cardoe | gtema: to be clear I'm not saying anything negative against keystone. I'm just bringing awareness that there's a real risk of burn out of the existing folks. | 17:41 |
| * fungi checks how many developers are working full-time on the linux kernel vs keystone | 17:42 | |
| noonedeadpunk | my point was not in amount of working people, but that AI tools are finding a lot of things everywhere | 17:43 |
| gtema | now we have bunch of features that were introduced by people with poor design and they disappear once the feature lands. Current architecture of the code base is just a sieve. We are in the patching leaking sieve modus and VMT members see definitely we are not able to close most of vulnerabilities at all | 17:43 |
| gtema | so, we need a full revamp of Keystone, it simply cannot hold any additions anymore without a redesign | 17:43 |
| gtema | and I am personally absolutely refusing any new features untill we solve foundation issues | 17:44 |
| noonedeadpunk | I am still disagreeing with ^ | 17:44 |
| cardoe | Well I think to get there we really need to focus on improving our testing and expanding tests of uncovered areas. | 17:44 |
| cardoe | Because to ensure any revamp is compatible we need testing. | 17:44 |
| gtema | improving testing/uncovered areas you only find new vulnerabilities in a system that is not capable for being fixed (in multiple places) | 17:45 |
| noonedeadpunk | Isn't revamap being made explicitly incompatible with current state of things? But also such revamp will drive out even existing ppl that are limited? | 17:45 |
| fungi | it seems like, if there are people who want to work on a redesign and other people who want to maintain the existing keystone, then neither group should stand in the other's way. it's still unclear to me whether both of those groups exist though | 17:45 |
| noonedeadpunk | ++ ^ | 17:45 |
| mharley[m] | \o/ | 17:46 |
| mharley[m] | Agreed, fungi . | 17:46 |
| gtema | I represent a group that wants to redesign and donate the working improvement. At the same time I represent a group (with other core members) stating we can't fix it anymore | 17:47 |
| cardoe | fungi: I think they both do based on the fact that there's proposals for features and there's patches on the queue for some cleanups. | 17:47 |
| fungi | just remember that work on a redesign of keystone also means working on implementing support for that new design in projects that currently rely on keystone's api | 17:47 |
| noonedeadpunk | um, so there is obvious conflict of interest gtema | 17:47 |
| gtema | but the other group of those willing to stick to the existing keystone ignores raised concerns and is itself not really investing any time into maintaining - none of those people represent the core team | 17:48 |
| fungi | i'm saying have two core teams, if there are really enough people willing to take over the existing keystone design and take responsibility for fixing bugs in it | 17:48 |
| noonedeadpunk | could it be also because of the protectiveness state which raised due to conflict of interests? | 17:48 |
| noonedeadpunk | As it's very defenetive statements here, that nothing is going to be done in improving existing keystone | 17:49 |
| fungi | but the existing core team shouldn't simultaneously say they're not going to deprecate the existing design and refuse to let anyone else step up to maintain it | 17:49 |
| noonedeadpunk | so how anybody stands a chance? | 17:49 |
| noonedeadpunk | ++ | 17:49 |
| fungi | er, that they *are* going to deprecate | 17:49 |
| JayF | fungi: especially when the current suggested new design isn't even using an architecture currently permitted in openstack (rust) | 17:50 |
| noonedeadpunk | and has a single contributor to it... | 17:50 |
| spotz[m] | I think some thing that's similar to Horizon and Skyline isn't a bad path to take here | 17:50 |
| noonedeadpunk | ++ | 17:50 |
| noonedeadpunk | Yes, I think it's indeed good, separate project implemeting identity | 17:50 |
| * fungi saw multiple contributors to the rust-based keystone replacement last he looked | 17:50 | |
| gtema | such approach is not going to work as easy as you say - redesigning system requires aligning systems on compatibility. Just creating a replacement while the old system will continue getting new conflicting features is now the right step in my eyes | 17:50 |
| noonedeadpunk | and concept of service type vs service name is totally applicable here | 17:51 |
| JayF | gtema: that' | 17:51 |
| JayF | gtema: that's a technical problem to be solved: use a shared spec system for API changes and the like | 17:51 |
| fungi | gtema: yes, but aligning those other projects to the new api, as i said, requires buy-in from the maintainers of those projects and someone to do that work in them | 17:51 |
| spotz[m] | It gives people choice, as long as both are being maintained | 17:51 |
| noonedeadpunk | though also skyline shows how community is sparse when it comes on knowledge of nodejs | 17:52 |
| fungi | maybe rust will be different | 17:52 |
| gtema | jayf - that contradicts the point of separate teams and is simply architecturally wrong, what is applicable to one system will be not necessary or harmful for other | 17:52 |
| noonedeadpunk | despite that it's the right tech to use for service like that | 17:52 |
| JayF | IMO, the real issue that cardoe has brought up here is how we're at an impasse: it's not about deciding if we're going one way or the other moving forward, it's about unblocking folks in the community to do the right thing -- even if that means going two directions and seeing which one "wins" or where they converge | 17:52 |
| noonedeadpunk | not saying we still can't figure out and fix skyline-console release process | 17:52 |
| noonedeadpunk | ++ yes, thanks JayF for returning discussion to correct way | 17:53 |
| gtema | fungi, to complete your statement: I raised multiple times my readiness to bring the new system, work on new apis and co-existence | 17:53 |
| fungi | also if a different group of people took over maintaining the existing keystone, it would free up the keystone replacement devs from work they're not keen on to spend more time on what they're interested in | 17:54 |
| gtema | and currently there is pretty much nobody willing to really dedicate time and resources (a lot of resources) to keep current code base safe | 17:54 |
| fungi | it seems like cardoe is saying there are people interested in doing that but they're being gate-kept from doing so | 17:55 |
| cardoe | I'll do my best on the current safety of the code base. | 17:55 |
| cardoe | I currently rely on it so I have an interest in it being acceptable. | 17:55 |
| noonedeadpunk | I will be glad to try finding some time/extra resources for current codebase as also care about it | 17:55 |
| gtema | this brings me back to the statement above - keystone is unforgiving to stop-by contributions. It requires a very security skilled and dedicated people | 17:55 |
| cardoe | I'm personally interested in setting the testing, docs and quality around that improve. | 17:56 |
| noonedeadpunk | Are we actually following 4 opens during discussion in here? As the discussion seems to tend being exclusive rather then inclusive | 17:56 |
| cardoe | I'm less concerned about landing features to keystone but just defensive checks. | 17:57 |
| gtema | under dedicated I really mean dedicated and not the ones who already cover multiple projects and just want to have their features landed | 17:57 |
| fungi | there has been a pretty steady flow of (mainly llm-researched) reports of suspected vulnerabilities in keystone that is taking a lot of time for the people currently responsible for that too | 17:57 |
| gtema | fungi - correct, and most of them we are simply not able to fix unless we do structural changes | 17:58 |
| fungi | and by steady i mean i process several new ones each day lately, it seems like | 17:58 |
| gtema | correct - that is also what I mean "dedicated", it's amount of work people easily underestimate | 17:58 |
| noonedeadpunk | So the thing is actually that VMT is handled behind closed doors, which is valid and fair, but really commmunity can't step in at the same time to help with them | 17:59 |
| gouthamr | time-check, 3 minutes. Does it help if we pick up on themes here and continue the discussion on actionable items? | 17:59 |
| gouthamr | 1) keystone-core seems to be overwhelmed. we need a way to rectify this | 17:59 |
| gouthamr | 2) we need to separate the "replace/redesign" conversation from the problem of maintaining what we have | 17:59 |
| fungi | i would absolutely caution anyone volunteering not to underestimate the incoming volume there | 17:59 |
| gtema | gouthamr - while I get the point with 2 discussions, they are really intertwined | 18:00 |
| fungi | well, i think if there are members of the community stepping in to help maintain existing keystone, that will need to include staffing up its coresec team handling those private reports | 18:00 |
| spotz[m] | This is a case where a different name for the project would help some as well | 18:01 |
| fungi | which is why i'm cautioning not to underestimate what you're volunteering fior | 18:01 |
| cardoe | I more wanted to bring up the point that folks are overwhelmed today which risks folks burning out and becomes a bigger problem. | 18:01 |
| JayF | spotz[m]: well, it depends on the approach. Reimplementation of a similar API, that might cause more confusion. Either way, the disagreeing-sides (keep going vs new thing required) have to talk to get anything moving forward :( | 18:02 |
| gouthamr | gtema: i agree, and as PTL and existing cores, you can suggest gaps if you need for anyone volunteering.. but, i am assuming you want to kill the perception that this is "closed" to existing maintainers. Your concern is that you see these as drive-by contributions with no hope for sustaining the work they'll do and go | 18:02 |
| gtema | I would also ask TC not to abandon or delay discussion on Rust - we (keystone team) need a decision to be able to decide with the future strategy | 18:02 |
| gtema | correct - nothing is closed here | 18:02 |
| spotz[m] | JayF: I agree I'm just trying to think of how to be less confusing | 18:03 |
| noonedeadpunk | is there a proposal somewhere? | 18:03 |
| gouthamr | #link https://review.opendev.org/c/openstack/governance/+/998652 (Add Rust use-case analysis for Keystone) | 18:03 |
| gouthamr | ^ this is a good place to wrap this meeting up | 18:03 |
| noonedeadpunk | nice, will read through | 18:03 |
| gouthamr | i'd like the TC to review this, it's been up for a bit, so please give it some thought | 18:04 |
| cardoe | So my curiosity is that adding docs, tests or cleaning up existing small bugs... would those be considered drive-by and unwanted? | 18:04 |
| spotz[m] | Not by me | 18:04 |
| gouthamr | teh way you put it, no. but, if a bugfix is causing a re-design, i guess the core team pushes back by either rejecting or ignoring the attempt | 18:04 |
| gtema | cardoe - it depends. It distracts and is sometimes really more harmful than useful | 18:05 |
| JayF | gtema: that indicates to me a MAJOR issue with core team health if minor fixes can't be landed :| | 18:05 |
| gtema | lot of security fixes are really very bad and we should rather completely abandon the feature and get the replacement fast | 18:05 |
| noonedeadpunk | I kinda start feeling if it might be worth to fork keystone under different name under openinfra to let keystone team do what they want instead... | 18:05 |
| JayF | gtema: I wonder what the path would be to enabling someone like cardoe to take on some of that responsibility, especially if you trusted folks to know their limitations | 18:06 |
| gtema | jayf: core team currently has 4 members of which only 2 are really dedicated | 18:06 |
| gouthamr | gtema: fungi cardoe: i know this has come up in the foundation meetings too.. and spotz[m] TheJulia may be aware of folks referring to keystone issues in other contexts. i mentioned to a board member last week that the core team would like dedicated maintainers.. | 18:06 |
| gtema | of which 1 is more focused on preparing replacement while the other one is focused on closing gaps | 18:06 |
| gouthamr | there may be an in-person meeting ongoing for board members, and the topic was hinted here: | 18:06 |
| gouthamr | #link https://lists.openinfra.org/archives/list/foundation-board@lists.openinfra.org/thread/NJU7JQ5LSRIDYYIBL5SA7PZ5JTP5V7XF/ | 18:06 |
| gouthamr | while i make references to the board, be aware though, this is primarily a keystone governance problem, and in extension the TC's .. the board didn't ask me/TC members to "look into this" or anything of the sort.. its nice that much of this is public and organically discussed in multiple places with different perspectives | 18:07 |
| noonedeadpunk | In case of replacement in a different language, I think it must be a new project under new name... | 18:08 |
| gouthamr | alright, we're way past the end of the meeting.. sorry about keeping that running | 18:08 |
| gouthamr | is there anything else to add to the minutes today? | 18:08 |
| gouthamr | if not, don't stop the chatter.. ignore meetbot interrupts. | 18:09 |
| gouthamr | #endmeeting | 18:09 |
| opendevmeet | Meeting ended Tue Sep 8 18:09:54 2026 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 18:09 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/tc/2026/tc.2026-09-08-17.00.html | 18:09 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/tc/2026/tc.2026-09-08-17.00.txt | 18:09 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/tc/2026/tc.2026-09-08-17.00.log.html | 18:09 |
| JayF | noonedeadpunk++ That's generally where my mind is. Even if they are under the identity program. I'm a bit predisposed to thinkign this way I think because Rackspace had a separately implemented identity service for a while, IIRC | 18:10 |
| gouthamr | noonedeadpunk: ack, do suggest that in gerrit.. gtema has made references to keystone's rewrite there.. but, its fair to ask for the team's plan in parallel | 18:10 |
| JayF | that caused some massive client pain and I'd worry a lot about us duplicating those bad experiences upstream | 18:10 |
| gtema | name is absolutely irrelevant to the discussion. It only distracts it | 18:11 |
| fungi | JayF: rackspace's identity service was called keystone, it was implemented in java as i recall. the keystone we have now is a python-based rewrite, which was initially dubbed keystone-lite | 18:12 |
| JayF | fungi: internally I think we called it java identity or something; at least my team did | 18:12 |
| gtema | for some reason if that would rewrite of keystone in python nobody would even say a word, just because different language is proposed it all matters all of a sudden - this does not look right to me | 18:12 |
| JayF | I mean, yeah, it does matter, and it's not anti-rust -- it's about resetting operator expectations | 18:13 |
| JayF | how you maintain and operate a rust-based service is drastically different than a python-based one | 18:13 |
| gtema | it keystone says we introduce api v4 the discussion would be very different. Since we say we need to make architectural rebirth it matters differently? | 18:13 |
| gtema | it=if | 18:14 |
| fungi | and also leveraging an entire community's infrastructure and processes which have built up over 15 years around primarily python-based projects, so supporting something in a different language (any language) has an inherent cost to the entire community that shouldn't be ignored or hand-waved away as trivial | 18:14 |
| JayF | I think you are sorta leaning into part of what folks are struggling with: usually the "What do we want out of an API v4?" would be the first step of that process. In this case, the first I hear of a rust replacement is it being promoted as the next generation of keystone... despite there not even being an on-ramp for that language in OpenStack | 18:14 |
| gtema | I am not claiming something/everything is trivial. I am saying that in my perception people mix different things into the discussion | 18:15 |
| JayF | I legitimately could not care what language something is written in, really. I just don't like that this situation seems like one where planning was done outside of the community and presented as fait accompli. | 18:15 |
| gtema | jays, I repeat yet another time - there was NO discussion outside of community. I raised this years ago already | 18:16 |
| fungi | and part of that is perception too. i know the keystone team has discussed this rust rewrite in their ptg sessions, for example | 18:16 |
| gtema | when there was literally nothing. Arguments back those days were - neah, we need proof. Now there is a proof and at the same time there is an urgent need | 18:16 |
| fungi | that it seemed to come as a surprise to most of the community speaks in part to how little most of the community seems to want to get involved in maintaining keystone in the first place | 18:16 |
| gtema | fungi ++ | 18:17 |
| fungi | otherwise this would have come up in broader discussion naturally, i expect | 18:17 |
| JayF | gtema: fair enough, fungi probably nailed my situation. As an openstacker working on it for >10y it was shocking to hear "this is a next generation of $service" and be given a github link when it happened. That probably anchors a lot of folks' first impression -- it did mine. | 18:18 |
| fungi | rather than seeming like a fait accompli announcement | 18:18 |
| gtema | there were pre-ptg announcements, there were ML discussions, both on rust as a whole (with example of new cli) and keystone specific. Most wondering people started appearing after the keystone-rs was presented as "look, we have something what can serve us as a base" | 18:20 |
| fungi | i have rather a lot of sympathy for the current keystone maintainers when the lack of people wanting to get involved in design discussions from the outset is turned around and used to accuse them of working in secret | 18:20 |
| gtema | I strongly disagree about "working in secret" | 18:21 |
| gtema | nothing was done in secret, I was shouting about that loudly multiple times | 18:21 |
| fungi | i'm not saying i agree with some of their choices, but the current situation points to an overall breakdown in communication and engagement between team silos and across the community | 18:21 |
| gtema | but still thanks for sympathy ;-) | 18:21 |
| JayF | fungi: and I feel more than a little guilty, because I know how difficult it'd be at my current employer to justify keystone work directly :| | 18:22 |
| mnaser | As a long time operator the work [@gtema:matrix.org](https://matrix.to/#/@gtema:matrix.org) is doing is not new to me. I've seen this happen with other people like adjutant back then | 18:24 |
| mnaser | First they come in with an idea.. and be told you must find real use cases and real need and have people behind it | 18:24 |
| mnaser | Come back later with code.. be told you've went too far.. this needs to be done this way and that way | 18:24 |
| mnaser | Respectfully I don't think any operator or community member gets to say what keystone does other than the main keystone team and people who actually show up to the meetings etc | 18:25 |
| gtema | thanks mnaser for repeating that again | 18:25 |
| mnaser | I think our biggest problem is drive by "I don't like this" by people who aren't contributing code, working in the project, joining meetings etc | 18:25 |
| mnaser | I hate to say it but being an operator isn't enough to get a voice in the room anymore, especially in low contribution projects. | 18:26 |
| cardoe | mnaser: I'm at all the meetings which haven't happened. | 18:26 |
| cardoe | I'm all for the keystone rewrite effort. | 18:26 |
| cardoe | I just need keystone to be reliable until we're ready to move to the rewrite. | 18:26 |
| cardoe | As an operator | 18:26 |
| mnaser | Keystone is not reliable ? | 18:27 |
| cardoe | I can crash it multiple ways today. | 18:27 |
| cardoe | I can find a few paths without any tests | 18:27 |
| mnaser | You can do far worse with many other projects. Also perfect software doesn't exist. | 18:27 |
| cardoe | Of course not. | 18:27 |
| cardoe | But fixing those issues is my interest. | 18:28 |
| JayF | cardoe: You have active changes that were needing review and didn't get them, right? | 18:28 |
| JayF | cardoe: might be a good time to move the conversation from the generic to the specific | 18:28 |
| cardoe | I've got some active patches that I'm happy to take different approaches on. | 18:28 |
| mnaser | You fixing the crash and parallel efforts at lifting the auth ecosystem are two things that can happen in parallel | 18:28 |
| cardoe | mnaser: agreed | 18:28 |
| mnaser | There's no operator that can sit here and say we're happy with how auth happens in OpenStack today :( we're lacking so much sadly | 18:29 |
| cardoe | So today you're able to get a system-scoped token via federation... it's not covered by a test... I'd like to see https://review.opendev.org/c/openstack/keystone/+/981321for that land | 18:29 |
| JayF | mnaser: the entire TC subject was basically "how do we serve both of those groups" and it sorta spiraled to here | 18:29 |
| cardoe | I'm just linking what led me here. | 18:30 |
| gtema | cardoe - I still haven't received promised data for the referred change | 18:30 |
| cardoe | gtema: yep. I've gotta get new logs. | 18:30 |
| cardoe | gtema: I'm just answering what led me here. | 18:30 |
| gtema | and I repeat that adding a workaround like that is equal at adding new feature that would need to be supported "forever" | 18:30 |
| cardoe | We've discussed this one previously and it's not really had any more progress until last week. | 18:31 |
| cardoe | gouthamr had already put this topic on the agenda by then | 18:31 |
| mnaser | To be fair, we can't also tell people what they can work on or not work on. | 18:31 |
| gtema | that's why certain fixes, while they sound reasonable for non/core people, are pretty painful from cores pov | 18:31 |
| mnaser | JayF: I welcome innovation. Anyone doing something new and novel in OpenStack. I will applaud and push behind. | 18:32 |
| cardoe | tkajinam has put together a number of patches to validate and reject bad config files and I've been using those patches and I asked what it would take to land them. | 18:32 |
| cardoe | gtema put together patches to add some more type checking and validation to keystone and I asked what it would take to land them. | 18:32 |
| JayF | mnaser: I think 99% of my issue here is that it's not being done *in openstack*, even though it's using openstack trademarks, but that's not a constructive thing to discuss in this particular context :) | 18:32 |
| fungi | mnaser: agreed, if there are sufficient volunteers (i'm not saying i've seen evidence yet that there are) to maintain the existing keystone so that the people who want to work on an alternative replacement can focus on that instead, then they should be allowed to | 18:32 |
| gtema | tkajinam knows how to ping me and he does so often to get a necessary attention to certain patches | 18:33 |
| cardoe | A few keystone meetings didn't happen but then gtema told me that the core's were too overwhelmed to review patches like the ones I mentioned | 18:33 |
| cardoe | So I felt that we should bring up the topic at the TC. | 18:33 |
| gtema | some keystone meetings didn't happen because it makes no sense to hold a meeting where a single guys just goes over agenda with nobody else saying a word | 18:34 |
| cardoe | I think we're on to something by acknowledging the rewrite work and the on going maintenance work. | 18:34 |
| mnaser | JayF: I don't think a single bit of progress would have been done if this needed to happen in our (imho kinda broken) way. I think taking a little sidebar to move faster and then come back to our rules is a good idea | 18:34 |
| cardoe | gtema: yep which is part of the problem | 18:34 |
| gtema | cardoe - but this is exactly describing that apat of the core team there is nobody else really dedicating anything to keystone | 18:35 |
| mnaser | fungi: Fair but it looks like the current set works on it to keep it alive in the hope of building the next big thing :) | 18:35 |
| JayF | mnaser: the statement acknowledges that we have some broken governance pieces but takes the path of routing around them being the right solution. That's the sorta thing that deconstructs a community in the long term. I'd prefer a route direct through -- fixing any governance cruft along the way. | 18:35 |
| gtema | there are people sometimes (sorry for the word) annoying to get their spec in and disappear immediately once it lands. Such things are what hurts us most | 18:35 |
| JayF | gtema: there's nothing I dread more than a well-thought-out spec for Ironic, around a complex subject, from a name I've never seen before | 18:36 |
| cardoe | I think we need to bring the rust work under the OpenStack umbrella. But I think we need to also ensure we're keeping the current code base alive until such a time we make a switch. | 18:36 |
| gtema | jayf - what works for ironic doesn't necessarily work for keystone. That's a dangerous misconception I am strugling to explain to people | 18:37 |
| JayF | gtema: because you know you'll spend an uphill battle explaining to folks about the limitations the exist because of use case #182 even though they have use case #52 | 18:37 |
| mnaser | JayF: With my ex TC hat on.. I agree with this. But the change has been hard to drive. It takes weeks of meetings and deliberation.. convincing and pulling people.. and change is hard so I feel sometimes there isn't interest in fighting that fight.. cause it is quite and undertaking. | 18:37 |
| JayF | mnaser: I have an ex-TC hat on for that exact reason -- but I see it like technical debt; the more we route around governance damage, the deeper we get into the hole of governance being broken | 18:38 |
| JayF | gtema: I'm trying to commisserate with you in this case, not disagree :) | 18:39 |
| gtema | I don't really get the "broken governance" argument again here. Nothing from the governance processes has been violated, nothing | 18:39 |
| mnaser | JayF: Yep and to be frank I got tired of trying and pushing cause any change was going through a billion hoops | 18:39 |
| cardoe | heh.. that's something I think is misunderstood in this channel a bunch... folks are agreeing a lot more than disagreeing but we seem to focus on the back and forth. | 18:39 |
| JayF | gtema: Your team didn't feel like they could use our existing infrastructure and tooling for their new project. That indicates a failure of governance to support you, regardless of if I agree with the move to use github instead of not | 18:40 |
| gtema | cardoe - lol, so true | 18:40 |
| gtema | jayf - you are again very wrong in the assesment | 18:40 |
| JayF | cardoe: 90% of this is people arguing over which part of the problem sucks the most. We could just move on if every agrees that MY thoughts on the problem are correct (/s) | 18:40 |
| gtema | I was explaining it multiple times and every time after explanation I feel like it is accepted, but few weeks later it is again from 0 | 18:41 |
| cardoe | I mean I think keystone overall needs more involvement and I don't think anyone will disagree there. | 18:41 |
| fungi | gtema: it's more that mnaser was suggesting to make an exception to current policies and then fix things up later. that's what was highlighted as theoretical) brokenness | 18:42 |
| cardoe | In a perfect world if we had staffing we could assign I would say some folks on the new effort and some folks on maintenance effort. | 18:42 |
| gtema | in a perfect world - yes, but even that is not really relevant to the situation imho | 18:43 |
| cardoe | Maintenance is my interest as an operator. It's why I've joined the ansible collections and it's why I've joined the SDKs. | 18:47 |
| cardoe | I'm not looking for new features. | 18:47 |
| cardoe | I'm looking for stability and reliability. | 18:48 |
| cardoe | You gimme keystone-rs and all OpenStack projects migrated to using it and feature compat for 2026.2 then I'll say bye to the Python code base. | 18:48 |
| gtema | glad for you cardoe. One of the points mentioned above is, however, some of the features in 2026.2 are doomed with vulnerabilities and it makes 0 sense to reimplement the same in different technology - ec2creds are one of the things which we fight vulns since more than a year already and are still not able to even disable it without hacks | 18:51 |
| cardoe | feature compat where it makes sense | 18:52 |
| cardoe | Not saying byte for byte compat | 18:52 |
| cardoe | But we can achieve the functionality for most folks and be able to actually retire it. | 18:52 |
| gtema | totally with you. Unfortunately this is not something where everybody agrees (at least in my perception) | 18:53 |
Generated by irclog2html.py 4.1.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!