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