15:08:18 <d34dh0r53> #startmeeting keystone
15:08:18 <opendevmeet> Meeting started Wed Jul 23 15:08:18 2025 UTC and is due to finish in 60 minutes.  The chair is d34dh0r53. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:08:18 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:08:18 <opendevmeet> The meeting name has been set to 'keystone'
15:08:29 <d34dh0r53> Reminder: This meeting takes place under the OpenInfra Foundation Code of Conduct
15:08:40 <d34dh0r53> #link https://openinfra.dev/legal/code-of-conduct
15:09:01 <d34dh0r53> #topic roll call
15:09:12 <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:09:15 <d34dh0r53> dmendiza: o/
15:09:19 <gtema> op/
15:10:57 <d34dh0r53> #topic review past meeting work items
15:11:32 <d34dh0r53> #link https://meetings.opendev.org/meetings/keystone/2025/keystone.2025-07-09-15.20.html
15:11:49 <d34dh0r53> We had one action item: @Greg to look at the ldap failures
15:11:59 <d34dh0r53> He's on PTO this week, so I'll push that to next week
15:12:05 <gtema> that was done
15:12:13 <d34dh0r53> oh, cool
15:12:21 <gtema> and fixed. Sadly not all necessary devstack changes are merged yet
15:12:36 <d34dh0r53> I think I reviewed those
15:12:59 <gtema> yes
15:13:06 <dmendiza[m]> 🙋
15:14:28 <d34dh0r53> #topic liaison updates
15:14:32 <d34dh0r53> hi dmendiza
15:14:45 <d34dh0r53> nothing from me for liaison updates
15:15:00 <gtema> nothing on my side either
15:15:43 <d34dh0r53> #topic specification OAuth 2.0 (hiromu)
15:15:47 <d34dh0r53> #link https://review.opendev.org/q/topic:bp%252Foauth2-client-credentials-ext
15:15:49 <d34dh0r53> #link https://review.opendev.org/q/topic:bp%252Fenhance-oauth2-interoperability
15:15:52 <d34dh0r53> External OAuth 2.0 Specification
15:15:54 <d34dh0r53> #link https://review.opendev.org/c/openstack/keystone-specs/+/861554 (merged)
15:15:57 <d34dh0r53> OAuth 2.0 Implementation
15:16:00 <d34dh0r53> #link https://review.opendev.org/q/topic:bp%252Fsupport-oauth2-mtls (merged)
15:16:03 <d34dh0r53> OAuth 2.0 Documentation
15:16:06 <d34dh0r53> #link https://review.opendev.org/c/openstack/keystone/+/838108 (merged)
15:16:08 <d34dh0r53> #link https://review.opendev.org/c/openstack/keystoneauth/+/838104 (merged)
15:16:31 <d34dh0r53> no idea where this is, probably just waiting for tacker, et al, to merge things so we can merge the tests
15:16:46 <d34dh0r53> #topic specification Secure RBAC (dmendiza)
15:16:48 <d34dh0r53> #link https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#z-release-timeline_
15:16:50 <d34dh0r53> 2025.2 Release Timeline
15:16:52 <d34dh0r53> Update oslo.policy in keystone to enforce_new_defaults=True
15:16:56 <d34dh0r53> Update oslo.policy in keystone to enforce_scope=True
15:18:10 <dmendiza[m]> Yeah... I'm not sure if there's anything else we need right now.
15:19:14 <d34dh0r53> Should we remove this, can we consider it done?
15:19:58 <dmendiza[m]> Possibly? The only thing I'm unsure about is whether Devstack defaults to SRBAC on? 🤔
15:21:04 <d34dh0r53> I'm asking AI 😜
15:25:57 <d34dh0r53> Unclear
15:26:42 <gtema> it tells you all the history of SRBAC in OpenStack perhaps instead of giving the answer, right?
15:26:56 <gtema> ;)
15:27:15 <d34dh0r53> yeah, and then I tried having it collate each of the core projects and it wouldn't
15:27:43 <d34dh0r53> maybe if I pointed cursor at it
15:28:10 <gtema> its faster to dig ourselves ;-)
15:28:18 <d34dh0r53> #topic specification OpenAPI support (gtema)
15:28:19 <d34dh0r53> indeed
15:28:24 <d34dh0r53> #link https://review.opendev.org/q/topic:%22openapi%22+project:openstack/keystone
15:28:33 <gtema> no news on that front sadly
15:28:51 <gtema> was busy with openpolicyagent as wasm crashing
15:30:55 <d34dh0r53> ack, did you figure out the wasm thing?
15:31:40 <gtema> not really
15:31:52 <gtema> found few articles on how to debug it, but haven't tried yet
15:32:13 <d34dh0r53> ack
15:32:16 <gtema> the only fact is that this starts happening from a certain number of rules
15:32:49 <d34dh0r53> no memory errors because rust doesn't give you enough memory? ;)
15:33:26 <gtema> neah. In general wasm itself is like a programming language
15:34:07 <gtema> and the rust implementation for it has an invalid memory access once the wasm for openpolicyagent reaches certain count of rules (functions or whatsoever)
15:34:36 <gtema> the size of binary does not matter though, so I assume it really has to do with the number of rules
15:34:53 <d34dh0r53> ahh
15:34:54 <gtema> till now I implemented calling of OPA using http
15:35:11 <gtema> what is anyway a recommended approach with slightly more features
15:35:47 <gtema> it also apparently has nearly no influence on the performance, so ... who cares
15:36:05 <gtema> I will definitely continue trying to debug it though
15:36:27 <gtema> the policies in OPA are so much greater than oslo.policy
15:37:19 <d34dh0r53> Yeah, it's very promising, keep us posted
15:37:19 <d34dh0r53> #topic open discussion
15:37:22 <d34dh0r53> drencrom
15:37:27 <d34dh0r53> Review patch proposal: https://review.opendev.org/c/openstack/keystone/+/951792
15:37:30 <d34dh0r53> Can I help with ldap tests? How hard it is to run them locally?
15:38:11 <gtema> we just need to have devstack change on restarting slapd landed
15:38:30 <d34dh0r53> Yeah, that's what I figured
15:38:33 <gtema> afterwards things are great again and we can come back to that change
15:38:50 <d34dh0r53> this did pass keystone-tempest-ldap-domain-specific-driver, does that instantiate slapd?
15:39:05 <gtema> I see the change already sets depends-on and tests are now passing
15:39:15 <gtema> so we can review that
15:39:27 <gtema> yes, it does
15:39:53 <gtema> because of that that job was failing for a very long time
15:40:09 <gtema> we just never looked at it
15:40:51 <d34dh0r53> okay, I'll review it
15:40:59 <d34dh0r53> who should we ping about the devstack patches?
15:41:49 <gtema> no idea. I think frickler approved one change of both, but not the slapd restart
15:42:01 <gtema> so he should have rights
15:42:36 <gtema> oh crap. Now I see the other +Wed change did't land - need recheck
15:44:51 <d34dh0r53> ahh, okay
15:46:31 <d34dh0r53> #topic bug review
15:46:35 <d34dh0r53> #link https://bugs.launchpad.net/keystone/?orderby=-id&start=0
15:46:52 <d34dh0r53> several new bugs for keystone, not sure if we've covered any yet, but I'll go through the list
15:46:57 <d34dh0r53> first up
15:47:08 <d34dh0r53> #link https://bugs.launchpad.net/keystone/+bug/2117217
15:48:16 <d34dh0r53> I thought this was fixed
15:48:50 <gtema> maybe this is a side-effect of the fix?
15:50:33 <d34dh0r53> no, it just didn't address application credentials
15:50:55 <d34dh0r53> commit e9513f8e4f25e1f20bc6fcab71d9177120000abf if anyone is interested
15:51:25 <gtema> yeah, looks like that
15:51:40 <d34dh0r53> I think we can confirm this one
15:51:52 <gtema> right
15:52:06 <d34dh0r53> next up
15:52:11 <d34dh0r53> #link https://bugs.launchpad.net/keystone/+bug/2116948
15:52:45 <d34dh0r53> Can we bump the requirements for epoxy?
15:53:31 <gtema> hmm, I doubt
15:54:08 <gtema> I just wonder this is happening, since I use that command in github ci since months and haven't seen issues
15:55:21 <d34dh0r53> hmm
15:55:22 <gtema> so the problem is that we haven't raised the low constraint for that
15:55:46 <gtema> additional issue is that the platform the reporter runs does not have a newer version
15:56:04 <gtema> almalinux 9.6
15:57:32 <gtema> if we just raise the constraint in Epoxy the reported would still fail to run it since the package is likely not there
15:57:58 <d34dh0r53> ahh, do you mind responding to that bug?
15:58:08 <gtema> it looks it can be updated only in el10
15:58:16 <gtema> sure, I'll do
15:58:24 <d34dh0r53> thanks
15:58:25 <d34dh0r53> next up
15:58:29 <d34dh0r53> #link https://bugs.launchpad.net/keystone/+bug/2116930
16:01:04 <gtema> I remember stephenfin was complaining on limits that they require system scope tokens or so.
16:01:18 <gtema> Maybe this is somehow related
16:01:35 <d34dh0r53> I was just wondering about that
16:01:45 <stephenfin> That looks like the same issues, yes
16:01:54 <stephenfin> *issue
16:02:01 <d34dh0r53> ok, so that's confirmed
16:02:23 <gtema> well, works as designed as we figured out back those days
16:02:35 <d34dh0r53> yeah, thats true
16:02:41 <gtema> but that is definitely not how anybody would want to use the feature
16:02:53 <d34dh0r53> especially for admin
16:03:27 <gtema> right
16:04:42 <d34dh0r53> finally
16:04:44 <d34dh0r53> #link https://bugs.launchpad.net/keystone/+bug/2116750
16:06:07 <gtema> needs further check - not sure this is the default policy
16:06:30 <gtema> at least my local checkout tells current policy for create_grant is an insanely long and complex rule
16:06:48 <gtema> it's 3 lines on 32'' 4k monitor
16:07:30 <d34dh0r53> wow
16:07:34 <dmendiza[m]> I can take a look at that
16:09:53 <gtema> addition to that ticket is wording: "when a project admin" - looks like they grant admin on project to non admin users
16:10:35 <d34dh0r53> yeah, thanks dmendiza
16:10:53 <d34dh0r53> that does it for keystone
16:11:00 <d34dh0r53> #link https://bugs.launchpad.net/python-keystoneclient/?orderby=-id&start=0
16:11:05 <d34dh0r53> nothing new in python-keystoneclient
16:11:08 <d34dh0r53> #link https://bugs.launchpad.net/keystoneauth/+bugs?orderby=-id&start=0
16:11:32 <d34dh0r53> #link https://bugs.launchpad.net/keystoneauth/+bugs?orderby=-id&start=0
16:11:35 <d34dh0r53> keystoneauth is good
16:11:41 <d34dh0r53> #link https://bugs.launchpad.net/keystonemiddleware/+bugs?orderby=-id&start=0
16:11:51 <d34dh0r53> so is keystonemiddleware
16:11:57 <d34dh0r53> #link https://bugs.launchpad.net/pycadf/+bugs?orderby=-id&start=0
16:11:59 <d34dh0r53> good here
16:12:04 <d34dh0r53> #link https://bugs.launchpad.net/ldappool/+bugs?orderby=-id&start=0
16:12:07 <d34dh0r53> and ldappool is good to go
16:12:10 <d34dh0r53> 'v
16:12:11 <d34dh0r53> #topic conclusion
16:12:27 <d34dh0r53> Thanks all! Nothing else from e
16:12:29 <d34dh0r53> me
16:12:55 <gtema> nothing on my side either
16:16:09 <d34dh0r53> #endmeeting