| *** ykarel_ is now known as ykarel | 07:58 | |
| d34dh0r53 | #startmeeting keystone | 15:27 |
|---|---|---|
| opendevmeet | Meeting started Wed Mar 18 15:27:45 2026 UTC and is due to finish in 60 minutes. The chair is d34dh0r53. Information about MeetBot at http://wiki.debian.org/MeetBot. | 15:27 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 15:27 |
| opendevmeet | The meeting name has been set to 'keystone' | 15:27 |
| d34dh0r53 | Reminder: This meeting takes place under the OpenInfra Foundation Code of Conduct | 15:27 |
| d34dh0r53 | #link https://openinfra.dev/legal/code-of-conduct | 15:27 |
| d34dh0r53 | #topic roll call | 15:27 |
| d34dh0r53 | admiyo, bbobrov, crisloma, d34dh0r53, dpar, dstanek, hrybacki, lbragstad, lwanderley, kmalloc, rodrigods, samueldmq, ruan_he, wxy, sonuk, vishakha, Ajay, rafaelwe, xek, gmann, zaitcev, reqa, dmendiza[m], dmendiza, mharley, jph, gtema, cardoe, deydra | 15:28 |
| d34dh0r53 | sorry for the late start | 15:28 |
| gtema | I was sure we again fall victims of the DST change | 15:28 |
| gtema | o/ | 15:28 |
| d34dh0r53 | indeed | 15:28 |
| d34dh0r53 | #topic review past meeting work items | 15:32 |
| d34dh0r53 | #link https://meetings.opendev.org/meetings/keystone/2026/keystone.2026-03-04-15.07.html | 15:33 |
| d34dh0r53 | no action items from last week | 15:33 |
| d34dh0r53 | #link https://meetings.opendev.org/meetings/keystone/2026 | 15:33 |
| d34dh0r53 | oops | 15:33 |
| d34dh0r53 | #topic liaison updates | 15:33 |
| d34dh0r53 | nothing from me | 15:33 |
| gtema | neither from me | 15:33 |
| d34dh0r53 | cool | 15:33 |
| d34dh0r53 | #topic specification Secure RBAC (dmendiza) | 15:34 |
| d34dh0r53 | #link https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#z-release-timeline_ | 15:34 |
| d34dh0r53 | 2026.1 Release Timeline | 15:34 |
| d34dh0r53 | Update oslo.policy in keystone to enforce_new_defaults=True | 15:34 |
| d34dh0r53 | Update oslo.policy in keystone to enforce_scope=True | 15:34 |
| d34dh0r53 | dmendiza: you around? | 15:36 |
| d34dh0r53 | #topic specification Secuirty Compliance Testing (dmendiza) | 15:36 |
| d34dh0r53 | #link https://review.opendev.org/c/openstack/devstack/+/957969 | 15:36 |
| d34dh0r53 | #topic keystone-rs | 15:37 |
| d34dh0r53 | #link https://github.com/openstack-experimental/keystone | 15:37 |
| gtema | there are no major things to report this week. I was in a heavy refactor splitting huge project into smaller pieces (crates) to get possibility to manage plugins in separate repos and other CPU optimization crap | 15:38 |
| d34dh0r53 | ahh, cool | 15:39 |
| gtema | currently redesigning the API of the assignment provider | 15:39 |
| gtema | so that custom drivers do not depend on the groups/inheritance/etc resolution forcibly done by the provider itself | 15:40 |
| gtema | that is something that made my life creating openfga assignment plugin complex | 15:40 |
| gtema | so now it is the responsibility of the driver to resolve group memberships (using the API), ihnerited assignments, etc | 15:41 |
| d34dh0r53 | interesting, can that be put into a library function? seems like it would be a lot of duplicate work | 15:45 |
| gtema | actually not, that is the point - when you use remote authorization engine (openfga) - you rely on it resolving all of that already for you, so what the provider is resolving is just a waste of time | 15:46 |
| d34dh0r53 | Ohh, I see, that makes sense | 15:46 |
| d34dh0r53 | cool | 15:47 |
| gtema | but sure - now there would be lot of libraries and every driver could pick up what it needs | 15:47 |
| gtema | e.g. I now have a dedicated crate with api types only (useful in the API based integration tests) | 15:47 |
| gtema | the "core" crate defines the API and the basic provider functionality | 15:48 |
| gtema | than there is a zoo of individual driver crates and they all are then pulled into the unified crate for building a binary | 15:48 |
| gtema | but that issue exactly underlines the point of the reliance of drivers (or resources) on each other | 15:49 |
| d34dh0r53 | right | 15:49 |
| gtema | and here you see that you can't have a FK on the role, since role may be an external driver | 15:49 |
| gtema | and need to find a way to deal with issues like role deletion, user deletion, etc | 15:50 |
| gtema | this is now handleded by weird notification mechanisms (with a subscriptions) | 15:50 |
| gtema | and a direct invokation of the related resources deletion | 15:51 |
| gtema | i.e. role provider needs to know of the application credentials provider existence | 15:51 |
| gtema | this is not always a good coupling and we see a class of bugs related to that | 15:51 |
| d34dh0r53 | right, I think we have a keystone bug around that very issue | 15:53 |
| gtema | anyway, once this split is done I start experimenting with moving of drivers to the KV database backed by raft consensus | 15:53 |
| gtema | yes, indeed. I was looking at it multiple times digging through the change history | 15:53 |
| gtema | and unfortunately not able to find something reasonable to say | 15:54 |
| d34dh0r53 | okay | 15:54 |
| gtema | rough estimation of the raft + KV db gives a 10x+ bigger throughput compared to the RDBMS | 15:55 |
| d34dh0r53 | wow | 15:56 |
| gtema | write latency is bit bigger, read is marginally faster, but the throughput is magnitudes better | 15:56 |
| d34dh0r53 | that's awesome | 15:56 |
| d34dh0r53 | #topic open discussion | 15:57 |
| gtema | nothing from me today | 15:57 |
| d34dh0r53 | me either | 15:58 |
| d34dh0r53 | #topic bug review | 15:58 |
| d34dh0r53 | #link https://bugs.launchpad.net/keystone/?orderby=-id&start=0 | 15:58 |
| d34dh0r53 | one new bug in keystone | 15:58 |
| d34dh0r53 | #link https://bugs.launchpad.net/keystone/+bug/2144446 | 15:58 |
| d34dh0r53 | we just talked about this one | 15:58 |
| gtema | right, as said I grabbed into the history and can't find anything reasonable to argue | 15:58 |
| gtema | to me it feels like a better thing due to the potenrial role inheritance impact | 15:59 |
| gtema | I mean that AC is dropped when the role using it is dropped. But I totally get the inconsistency argument | 16:00 |
| d34dh0r53 | yeah, I do too | 16:00 |
| d34dh0r53 | let's move on, we can talk about this one on Friday | 16:01 |
| d34dh0r53 | #link https://bugs.launchpad.net/python-keystoneclient/?orderby=-id&start=0 | 16:01 |
| d34dh0r53 | nothing new in python-keystoneclient | 16:01 |
| d34dh0r53 | #link https://bugs.launchpad.net/keystoneauth/+bugs?orderby=-id&start=0 | 16:02 |
| d34dh0r53 | keystoneauth is good to go | 16:02 |
| d34dh0r53 | #link https://bugs.launchpad.net/keystonemiddleware/+bugs?orderby=-id&start=0 | 16:02 |
| d34dh0r53 | no new bugs in keystonemiddleware | 16:02 |
| d34dh0r53 | #link https://bugs.launchpad.net/pycadf/+bugs?orderby=-id&start=0 | 16:02 |
| d34dh0r53 | pycadf is clean | 16:03 |
| d34dh0r53 | #link https://bugs.launchpad.net/ldappool/+bugs?orderby=-id&start=0 | 16:03 |
| d34dh0r53 | so is ldappool | 16:03 |
| d34dh0r53 | #topic conclusion | 16:03 |
| d34dh0r53 | Thanks all | 16:03 |
| gtema | thks Dave | 16:03 |
| d34dh0r53 | #endmeeting | 16:04 |
| opendevmeet | Meeting ended Wed Mar 18 16:04:31 2026 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 16:04 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/keystone/2026/keystone.2026-03-18-15.27.html | 16:04 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/keystone/2026/keystone.2026-03-18-15.27.txt | 16:04 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/keystone/2026/keystone.2026-03-18-15.27.log.html | 16:04 |
Generated by irclog2html.py 4.1.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!