| *** mhen_ is now known as mhen | 01:11 | |
| *** tkajinam_ is now known as tkajinam | 10:54 | |
| *** darmach47 is now known as darmach | 13:01 | |
| d34dh0r53 | #startmeeting keystone | 15:07 |
|---|---|---|
| opendevmeet | Meeting started Wed Oct 1 15:07:00 2025 UTC and is due to finish in 60 minutes. The chair is d34dh0r53. Information about MeetBot at http://wiki.debian.org/MeetBot. | 15:07 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 15:07 |
| opendevmeet | The meeting name has been set to 'keystone' | 15:07 |
| d34dh0r53 | Reminder: This meeting takes place under the OpenInfra Foundation Code of Conduct | 15:07 |
| gtema | oh, here are the folks | 15:07 |
| d34dh0r53 | #link https://openinfra.dev/legal/code-of-conduct | 15:07 |
| xek | o/ | 15:07 |
| d34dh0r53 | #topic roll call | 15:07 |
| gtema | o/ | 15:07 |
| 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:08 |
| d34dh0r53 | o/ | 15:08 |
| d34dh0r53 | sorry for missing the reviewathon last week, I had to take a personal day | 15:08 |
| gtema | np | 15:08 |
| dmendiza[m] | 🙋♂️ | 15:11 |
| d34dh0r53 | #topic review past meeting work items | 15:11 |
| d34dh0r53 | #link meetings.opendev.org/meetings/keystone/2025/keystone.2025-08-27-15.04.html | 15:12 |
| d34dh0r53 | looks like we haven't had a meeting since August :o | 15:12 |
| d34dh0r53 | gtema and I have one action item, which I'll take care of today | 15:12 |
| d34dh0r53 | dwilde/gtema add PTG topic about service account | 15:12 |
| d34dh0r53 | although I'm not sure of the context | 15:13 |
| d34dh0r53 | that was about 100 years ago in my brain ;) | 15:13 |
| gtema | I know - will do now | 15:13 |
| gtema | added agenda to etherpad | 15:14 |
| gtema | since we are on that we can discuss the times for keystone meetings | 15:14 |
| d34dh0r53 | yeah, I booked on Tues and Wed just to hold a room but we can definitely move things around | 15:15 |
| d34dh0r53 | #topic ptg planning | 15:15 |
| gtema | ah ok, i missed that | 15:16 |
| gtema | could stay like that - for me it's perfectly fine | 15:16 |
| dmendiza[m] | #link https://ptg.opendev.org/ptg.html | 15:17 |
| d34dh0r53 | cool, thanks dmendiza | 15:17 |
| d34dh0r53 | we also need to have a combined session with the horizon team | 15:18 |
| d34dh0r53 | I can reach out to them to figure out the best time for that | 15:18 |
| d34dh0r53 | #action dwilde plan PTG session with Horizon folks | 15:18 |
| gtema | cool, thks | 15:19 |
| d34dh0r53 | #topic liaison updates | 15:20 |
| d34dh0r53 | nothing from me | 15:20 |
| gtema | neither me | 15:21 |
| d34dh0r53 | #topic specification OAuth 2.0 (hiromu) | 15:21 |
| d34dh0r53 | #link https://review.opendev.org/q/topic:bp%252Foauth2-client-credentials-ext | 15:21 |
| d34dh0r53 | #link https://review.opendev.org/q/topic:bp%252Fenhance-oauth2-interoperability | 15:21 |
| d34dh0r53 | no updates from me on this | 15:21 |
| d34dh0r53 | #topic specification Secure RBAC (dmendiza) | 15:21 |
| d34dh0r53 | #link https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#z-release-timeline_ | 15:21 |
| d34dh0r53 | 2025.2 Release Timeline | 15:21 |
| d34dh0r53 | Update oslo.policy in keystone to enforce_new_defaults=True | 15:21 |
| d34dh0r53 | Update oslo.policy in keystone to enforce_scope=True | 15:21 |
| dmendiza[m] | 🙋♂️ | 15:22 |
| dmendiza[m] | First day back from PTO, so I have no idea what's going on. 😅 | 15:22 |
| dmendiza[m] | I think we still have some code in devstack that is defaulting to false | 15:23 |
| * dmendiza[m] checks gerrit | 15:23 | |
| gtema | 2025.2 is gone as a target today | 15:23 |
| gtema | so its from now 2026.1 | 15:23 |
| dmendiza[m] | ack, we need to update the agenda | 15:24 |
| dmendiza[m] | #link https://review.opendev.org/c/openstack/devstack/+/956210 | 15:24 |
| dmendiza[m] | ^^ I just rebased that. I think oslo.policy is going to remove the options soon. | 15:25 |
| gtema | yeah, should do that sooner rather than later | 15:25 |
| dmendiza[m] | It failed the gate last time, so I'll keep an eye on the rebase and try to fix whatever comes up | 15:26 |
| d34dh0r53 | thanks dmendiza | 15:26 |
| d34dh0r53 | #topic specification OpenAPI support (gtema) | 15:26 |
| d34dh0r53 | #link https://review.opendev.org/q/topic:%22openapi%22+project:openstack/keystone | 15:26 |
| gtema | all crear, no changes. But I am from time to time struggling in development | 15:27 |
| gtema | I mean doing certain experiments I end up with "updated" data in the db and json schema validation fail | 15:27 |
| gtema | this result in no entries returned at all - this sucks | 15:27 |
| gtema | nature of such experiments is the keystone-ng | 15:28 |
| gtema | rust code returns such entries, but python not. I need to think again on the conceptual level about the topic | 15:29 |
| d34dh0r53 | yep, that does suck | 15:29 |
| d34dh0r53 | ack, thanks gtema | 15:29 |
| dmendiza[m] | Dave Wilde (d34dh0r53): I added a topic to the agenda | 15:29 |
| d34dh0r53 | thanks dmendiza | 15:30 |
| d34dh0r53 | #topic open discussion | 15:30 |
| d34dh0r53 | drencrom | 15:30 |
| d34dh0r53 | pep8 (mypy) is broken on 2024.2 branch (see for example https://zuul.opendev.org/t/openstack/build/2fdbd3164c8c4241a5a6edd1895f6d3c) | 15:30 |
| gtema | this should have been fixed some weeks ago | 15:30 |
| dmendiza[m] | 🙋♂️ > Secuirty Compliance Testing (dmendiza) | 15:30 |
| drencrom | hi, I think there might be some depencies issues on that branch but could not fix it myself | 15:31 |
| gtema | oh, actually no. I guess I have not backported the fix so far away | 15:31 |
| gtema | https://review.opendev.org/c/openstack/keystone/+/958665 should be backported most likely | 15:32 |
| gtema | yes, it is the same issue | 15:33 |
| opendevreview | Artem Goncharov proposed openstack/keystone stable/2024.2: Ignore typing on the single import https://review.opendev.org/c/openstack/keystone/+/962696 | 15:34 |
| gtema | I wanted us to have a short chat about https://bugs.launchpad.net/keystone/+bug/2122615 | 15:35 |
| drencrom | Ok, I'll add a depends tag on that one and see it if works | 15:35 |
| gtema | I was riping my hair out of my head tracing where the revocation and validation happens - it is a spaghetti with multiple tabs | 15:36 |
| gtema | anyway: any objections for us doing what I proposed in the last comment or should we rather in such case explicitly generate revokation | 15:37 |
| gtema | the point is that I have found unit test that checks that token for the disabled user does not work even after re-enabling it back (through the revocation entry) | 15:37 |
| gtema | if we only check additionally whether the user is now active or not to address the mentioned usecase the token will be again accepted once the user is activated again what is a different flow compared to what is the "normal" behavior | 15:38 |
| gtema | on the other hand ... it all sucks since we do not really have any info of user that got disabled in a remote backend | 15:39 |
| dmendiza[m] | was catching up on the bug thread | 15:45 |
| dmendiza[m] | > when validating a token ensure the user is active or disabled | 15:47 |
| dmendiza[m] | ^^ that suggestion, right? | 15:47 |
| gtema | yes - reject the token when the user status is disabled | 15:48 |
| dmendiza[m] | so the question is whether to invalidate the token or not? | 15:48 |
| gtema | place in code is pretty straight forward. Just the question: simply reject the token or generate a revoke event similar to what is done when user is disabled through api | 15:49 |
| gtema | it's not actually a token revocation - it is a user revocation | 15:49 |
| dmendiza[m] | Disabling the user if we see that the backend status is disabled seems like the right thing to do. | 15:50 |
| gtema | https://opendev.org/openstack/keystone/src/commit/4275c6801e165f400d9bfadf4ea37e4a6b115e3f/keystone/identity/core.py#L1372 | 15:50 |
| gtema | when now the user enabled attr is changed the revocation event for the user is generated that ensures that even after reenabling the old token work | 15:51 |
| opendevreview | Jorge Merlino proposed openstack/keystone stable/2024.2: Fix AD nested groups issues https://review.opendev.org/c/openstack/keystone/+/961413 | 15:51 |
| gtema | dmendiza - we do not disable the user explicitly - that's the point of the bug | 15:52 |
| dmendiza[m] | Yeah, I think we agree that we should: | 15:52 |
| dmendiza[m] | * invalidate token | 15:53 |
| dmendiza[m] | * disable user | 15:53 |
| gtema | when a backend driver is used and the user entry is changed there bypassing the api (keycloak, ldap) we do not have any info on that, but once we fecth user detail or it tries to login we see updated into | 15:53 |
| gtema | we can't invalidate the token because we do not know all the tokens the user has - thus need to add additional validation that bypasses regular revocation | 15:54 |
| gtema | ok, we are stretching time with that too much | 15:55 |
| d34dh0r53 | Yeah, but that segues into the bug review | 15:55 |
| d34dh0r53 | #topic bug review | 15:56 |
| d34dh0r53 | #link https://bugs.launchpad.net/keystone/?orderby=-id&start=0 | 15:56 |
| d34dh0r53 | two bugs for keystone, the first we just discussed | 15:56 |
| d34dh0r53 | #link https://bugs.launchpad.net/keystone/+bug/2122615 | 15:56 |
| d34dh0r53 | next is | 15:56 |
| d34dh0r53 | #link https://bugs.launchpad.net/keystone/+bug/2125042 | 15:56 |
| gtema | that looks like a duplicate of what recently got merged | 15:57 |
| gtema | https://bugs.launchpad.net/keystone/+bug/2102096 | 15:58 |
| gtema | launchpad does not have duplicate option??? | 16:00 |
| d34dh0r53 | I thought it did | 16:01 |
| gtema | I can't find that | 16:02 |
| gtema | anyway - you can go on with next ones | 16:02 |
| d34dh0r53 | huh, I guess wont-fix with a note and link to the dup | 16:02 |
| d34dh0r53 | anyways | 16:02 |
| d34dh0r53 | #link https://bugs.launchpad.net/python-keystoneclient/?orderby=-id&start=0 | 16:02 |
| d34dh0r53 | nothing new here | 16:03 |
| d34dh0r53 | #link https://bugs.launchpad.net/keystoneauth/+bugs?orderby=-id&start=0 | 16:03 |
| d34dh0r53 | keystoneauth is good | 16:03 |
| d34dh0r53 | #link https://bugs.launchpad.net/keystonemiddleware/+bugs?orderby=-id&start=0 | 16:03 |
| d34dh0r53 | no new bugs in keystonemiddleware | 16:03 |
| d34dh0r53 | #link https://bugs.launchpad.net/pycadf/+bugs?orderby=-id&start=0 | 16:03 |
| d34dh0r53 | pycadf is good | 16:04 |
| d34dh0r53 | #link https://bugs.launchpad.net/ldappool/+bugs?orderby=-id&start=0 | 16:04 |
| d34dh0r53 | so is ldappool | 16:04 |
| d34dh0r53 | #topic conclusion | 16:04 |
| d34dh0r53 | add topics to the ptg etherpad | 16:04 |
| gtema | service accounts topic is there already | 16:04 |
| d34dh0r53 | #link https://etherpad.opendev.org/p/oct2025-ptg-keystone | 16:05 |
| d34dh0r53 | thanks gtema | 16:05 |
| d34dh0r53 | that's all from me | 16:05 |
| gtema | thanks Dave Wilde (d34dh0r53) , have a nice day | 16:06 |
| d34dh0r53 | thanks, likewise :) | 16:06 |
| d34dh0r53 | #endmeeting | 16:06 |
| opendevmeet | Meeting ended Wed Oct 1 16:06:30 2025 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 16:06 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/keystone/2025/keystone.2025-10-01-15.07.html | 16:06 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/keystone/2025/keystone.2025-10-01-15.07.txt | 16:06 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/keystone/2025/keystone.2025-10-01-15.07.log.html | 16:06 |
| opendevreview | Jorge Merlino proposed openstack/keystone stable/2024.2: Fix AD nested groups issues https://review.opendev.org/c/openstack/keystone/+/961413 | 18:51 |
| cardoe | gtema: I'll be interested in your service account convo. Currently trying to reconcile that with federated logins as well. e.g. OIDC really only wants to have client credentials without userinfo | 21:45 |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!