15:07:00 <d34dh0r53> #startmeeting keystone
15:07:00 <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:00 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:07:00 <opendevmeet> The meeting name has been set to 'keystone'
15:07:35 <d34dh0r53> Reminder: This meeting takes place under the OpenInfra Foundation Code of Conduct
15:07:36 <gtema> oh, here are the folks
15:07:47 <d34dh0r53> #link https://openinfra.dev/legal/code-of-conduct
15:07:47 <xek> o/
15:07:56 <d34dh0r53> #topic roll call
15:07:57 <gtema> o/
15:08:08 <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:09 <d34dh0r53> o/
15:08:29 <d34dh0r53> sorry for missing the reviewathon last week, I had to take a personal day
15:08:41 <gtema> np
15:11:22 <dmendiza[m]> 🙋‍♂️
15:11:57 <d34dh0r53> #topic review past meeting work items
15:12:21 <d34dh0r53> #link meetings.opendev.org/meetings/keystone/2025/keystone.2025-08-27-15.04.html
15:12:23 <d34dh0r53> looks like we haven't had a meeting since August :o
15:12:48 <d34dh0r53> gtema and I have one action item, which I'll take care of today
15:12:56 <d34dh0r53> dwilde/gtema add PTG topic about service account
15:13:14 <d34dh0r53> although I'm not sure of the context
15:13:34 <d34dh0r53> that was about 100 years ago in my brain ;)
15:13:49 <gtema> I know - will do now
15:14:39 <gtema> added agenda to etherpad
15:14:53 <gtema> since we are on that we can discuss the times for keystone meetings
15:15:38 <d34dh0r53> yeah, I booked on Tues and Wed just to hold a room but we can definitely move things around
15:15:58 <d34dh0r53> #topic ptg planning
15:16:02 <gtema> ah ok, i missed that
15:16:34 <gtema> could stay like that - for me it's perfectly fine
15:17:29 <dmendiza[m]> #link https://ptg.opendev.org/ptg.html
15:17:38 <d34dh0r53> cool, thanks dmendiza
15:18:08 <d34dh0r53> we also need to have a combined session with the horizon team
15:18:14 <d34dh0r53> I can reach out to them to figure out the best time for that
15:18:44 <d34dh0r53> #action dwilde plan PTG session with Horizon folks
15:19:52 <gtema> cool, thks
15:20:38 <d34dh0r53> #topic liaison updates
15:20:42 <d34dh0r53> nothing from me
15:21:02 <gtema> neither me
15:21:23 <d34dh0r53> #topic specification OAuth 2.0 (hiromu)
15:21:25 <d34dh0r53> #link https://review.opendev.org/q/topic:bp%252Foauth2-client-credentials-ext
15:21:28 <d34dh0r53> #link https://review.opendev.org/q/topic:bp%252Fenhance-oauth2-interoperability
15:21:35 <d34dh0r53> no updates from me on this
15:21:45 <d34dh0r53> #topic specification Secure RBAC (dmendiza)
15:21:47 <d34dh0r53> #link https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#z-release-timeline_
15:21:50 <d34dh0r53> 2025.2 Release Timeline
15:21:52 <d34dh0r53> Update oslo.policy in keystone to enforce_new_defaults=True
15:21:54 <d34dh0r53> Update oslo.policy in keystone to enforce_scope=True
15:22:07 <dmendiza[m]> 🙋‍♂️
15:22:27 <dmendiza[m]> First day back from PTO, so I have no idea what's going on. 😅
15:23:00 <dmendiza[m]> I think we still have some code in devstack that is defaulting to false
15:23:05 * dmendiza[m] checks gerrit
15:23:05 <gtema> 2025.2 is gone as a target today
15:23:17 <gtema> so its from now 2026.1
15:24:22 <dmendiza[m]> ack, we need to update the agenda
15:24:23 <dmendiza[m]> #link https://review.opendev.org/c/openstack/devstack/+/956210
15:25:00 <dmendiza[m]> ^^ I just rebased that.  I think oslo.policy is going to remove the options soon.
15:25:27 <gtema> yeah, should do that sooner rather than later
15:26:13 <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:31 <d34dh0r53> thanks dmendiza
15:26:41 <d34dh0r53> #topic specification OpenAPI support (gtema)
15:26:44 <d34dh0r53> #link https://review.opendev.org/q/topic:%22openapi%22+project:openstack/keystone
15:27:14 <gtema> all crear, no changes. But I am from time to time struggling in development
15:27:44 <gtema> I mean doing certain experiments I end up with "updated" data in the db and json schema validation fail
15:27:59 <gtema> this result in no entries returned at all - this sucks
15:28:34 <gtema> nature of such experiments is the keystone-ng
15:29:12 <gtema> rust code returns such entries, but python not. I need to think again on the conceptual level about the topic
15:29:18 <d34dh0r53> yep, that does suck
15:29:53 <d34dh0r53> ack, thanks gtema
15:29:58 <dmendiza[m]> Dave Wilde (d34dh0r53): I added a topic to the agenda
15:30:08 <d34dh0r53> thanks dmendiza
15:30:14 <d34dh0r53> #topic open discussion
15:30:18 <d34dh0r53> drencrom
15:30:20 <d34dh0r53> pep8 (mypy) is broken on 2024.2 branch (see for example https://zuul.opendev.org/t/openstack/build/2fdbd3164c8c4241a5a6edd1895f6d3c)
15:30:41 <gtema> this should have been fixed some weeks ago
15:30:49 <dmendiza[m]> 🙋‍♂️ > Secuirty Compliance Testing (dmendiza)
15:31:38 <drencrom> hi, I think there might be some depencies issues on that branch but could not fix it myself
15:31:57 <gtema> oh, actually no. I guess I have not backported the fix so far away
15:32:34 <gtema> https://review.opendev.org/c/openstack/keystone/+/958665 should be backported most likely
15:33:28 <gtema> yes, it is the same issue
15:34:47 <opendevreview> Artem Goncharov proposed openstack/keystone stable/2024.2: Ignore typing on the single import  https://review.opendev.org/c/openstack/keystone/+/962696
15:35:34 <gtema> I wanted us to have a short chat about https://bugs.launchpad.net/keystone/+bug/2122615
15:35:53 <drencrom> Ok, I'll add a depends tag on that one and see it if works
15:36:28 <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:37:10 <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:51 <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:38:57 <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:39:30 <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:45:48 <dmendiza[m]> was catching up on the bug thread
15:47:23 <dmendiza[m]> > when validating a token ensure the user is active or disabled
15:47:29 <dmendiza[m]> ^^ that suggestion, right?
15:48:10 <gtema> yes - reject the token when the user status is disabled
15:48:43 <dmendiza[m]> so the question is whether to invalidate the token or not?
15:49:00 <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:25 <gtema> it's not actually a token revocation - it is a user revocation
15:50:17 <dmendiza[m]> Disabling the user if we see that the backend status is disabled seems like the right thing to do.
15:50:42 <gtema> https://opendev.org/openstack/keystone/src/commit/4275c6801e165f400d9bfadf4ea37e4a6b115e3f/keystone/identity/core.py#L1372
15:51:27 <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:41 <opendevreview> Jorge Merlino proposed openstack/keystone stable/2024.2: Fix AD nested groups issues  https://review.opendev.org/c/openstack/keystone/+/961413
15:52:16 <gtema> dmendiza - we do not disable the user explicitly - that's the point of the bug
15:52:57 <dmendiza[m]> Yeah, I think we agree that we should:
15:53:02 <dmendiza[m]> * invalidate token
15:53:04 <dmendiza[m]> * disable user
15:53:15 <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:54:29 <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:55:41 <gtema> ok, we are stretching time with that too much
15:55:56 <d34dh0r53> Yeah, but that segues into the bug review
15:56:05 <d34dh0r53> #topic bug review
15:56:08 <d34dh0r53> #link https://bugs.launchpad.net/keystone/?orderby=-id&start=0
15:56:18 <d34dh0r53> two bugs for keystone, the first we just discussed
15:56:28 <d34dh0r53> #link https://bugs.launchpad.net/keystone/+bug/2122615
15:56:39 <d34dh0r53> next is
15:56:48 <d34dh0r53> #link https://bugs.launchpad.net/keystone/+bug/2125042
15:57:16 <gtema> that looks like a duplicate of what recently got merged
15:58:51 <gtema> https://bugs.launchpad.net/keystone/+bug/2102096
16:00:33 <gtema> launchpad does not have duplicate option???
16:01:51 <d34dh0r53> I thought it did
16:02:06 <gtema> I can't find that
16:02:19 <gtema> anyway - you can go on with next ones
16:02:49 <d34dh0r53> huh, I guess wont-fix with a note and link to the dup
16:02:52 <d34dh0r53> anyways
16:02:56 <d34dh0r53> #link https://bugs.launchpad.net/python-keystoneclient/?orderby=-id&start=0
16:03:09 <d34dh0r53> nothing new here
16:03:14 <d34dh0r53> #link https://bugs.launchpad.net/keystoneauth/+bugs?orderby=-id&start=0
16:03:27 <d34dh0r53> keystoneauth is good
16:03:30 <d34dh0r53> #link https://bugs.launchpad.net/keystonemiddleware/+bugs?orderby=-id&start=0
16:03:46 <d34dh0r53> no new bugs in keystonemiddleware
16:03:56 <d34dh0r53> #link https://bugs.launchpad.net/pycadf/+bugs?orderby=-id&start=0
16:04:00 <d34dh0r53> pycadf is good
16:04:04 <d34dh0r53> #link https://bugs.launchpad.net/ldappool/+bugs?orderby=-id&start=0
16:04:15 <d34dh0r53> so is ldappool
16:04:18 <d34dh0r53> #topic conclusion
16:04:27 <d34dh0r53> add topics to the ptg etherpad
16:04:54 <gtema> service accounts topic is there already
16:05:09 <d34dh0r53> #link https://etherpad.opendev.org/p/oct2025-ptg-keystone
16:05:13 <d34dh0r53> thanks gtema
16:05:19 <d34dh0r53> that's all from me
16:06:16 <gtema> thanks Dave Wilde (d34dh0r53) , have a nice day
16:06:28 <d34dh0r53> thanks, likewise :)
16:06:30 <d34dh0r53> #endmeeting