15:20:44 <d34dh0r53> #startmeeting keystone 15:20:44 <opendevmeet> Meeting started Wed Jul 30 15:20:44 2025 UTC and is due to finish in 60 minutes. The chair is d34dh0r53. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:20:44 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:20:44 <opendevmeet> The meeting name has been set to 'keystone' 15:22:26 <d34dh0r53> Reminder: This meeting takes place under the OpenInfra Foundation Code of Conduct 15:22:31 <d34dh0r53> #link https://openinfra.dev/legal/code-of-conduct 15:22:47 <d34dh0r53> #topic roll call 15:22:59 <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:23:00 <breton> o/ 15:23:04 <d34dh0r53> dmendiza: 15:23:19 <xek> o/ 15:24:32 <dmendiza[m]> 🙋♂️ 15:24:45 <cardoe> o/ 15:24:50 <d34dh0r53> #topic review past meeting work items 15:24:53 <d34dh0r53> #link https://meetings.opendev.org/meetings/keystone/2025/keystone.2025-07-23-15.08.html 15:25:00 <d34dh0r53> no action items from last week 15:25:06 <d34dh0r53> #topic liaison updates 15:25:13 <d34dh0r53> nothing from me 15:26:15 <d34dh0r53> #topic specification OAuth 2.0 (hiromu) 15:26:17 <d34dh0r53> #link https://review.opendev.org/q/topic:bp%252Foauth2-client-credentials-ext 15:26:20 <d34dh0r53> #link https://review.opendev.org/q/topic:bp%252Fenhance-oauth2-interoperability 15:26:42 <d34dh0r53> waiting on things to merge in barbican and tacker before we can merge our tempest plugin changes 15:26:52 <d34dh0r53> #topic specification Secure RBAC (dmendiza) 15:26:54 <d34dh0r53> #link https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#z-release-timeline_ 15:26:58 <d34dh0r53> 2025.2 Release Timeline 15:27:01 <dmendiza[m]> 🙋♂️ 15:27:03 <d34dh0r53> Update oslo.policy in keystone to enforce_new_defaults=True 15:27:07 <d34dh0r53> Update oslo.policy in keystone to enforce_scope=True 15:27:24 <dmendiza[m]> I actually do have an update this time! 15:27:26 <dmendiza[m]> :D 15:27:38 <dmendiza[m]> Let me find this link ... one sec ... 15:27:58 <d34dh0r53> 😲 15:28:27 <dmendiza[m]> Looks like devstack is still defaulting to de deprecated legacy policies: https://opendev.org/openstack/devstack/src/branch/master/lib/keystone#L122 15:29:08 <d34dh0r53> ahh, that's a bummer 15:29:37 <dmendiza[m]> I think we should flip the switch 👀 15:30:12 <dmendiza[m]> I'll have to look up how long ago the policies were marked as deprecated ... but I'm sure it's been at least a couple of years. 15:30:29 <dmendiza[m]> I need to remember what we can do in a SLURP/non-SLURP release though 🤔 15:32:03 <d34dh0r53> yeah, I'm in favor of flipping the switch 15:32:31 <dmendiza[m]> I'll submit a patch to flip it and keep and see what blows up 15:32:42 <dmendiza[m]> Ugh, I can't type today 15:33:21 <d34dh0r53> sounds good 15:33:42 <dmendiza[m]> Anyway, that's it for SRBAC this week. I'll update next week with patch results. 15:33:55 <d34dh0r53> thanks dmendiza 15:33:58 <d34dh0r53> next up 15:34:15 <d34dh0r53> #topic specification OpenAPI support (gtema) 15:34:16 <d34dh0r53> #link https://review.opendev.org/q/topic:%22openapi%22+project:openstack/keystone 15:35:22 <dmendiza[m]> oh gtema is out on PTO this week and next 15:35:52 <dmendiza[m]> I imagine right now he's having a delicious dinner of fish and chips next to the Eye of London 15:36:10 <mharley[m]> ✌️ 15:37:57 <d34dh0r53> VPN just booted me 15:38:04 <d34dh0r53> not sure if I missed anything 15:38:41 <dmendiza[m]> tl;dr gtema is ooo for 2 weeks 15:38:49 <d34dh0r53> ack, thanks 15:38:52 <d34dh0r53> next up 15:38:57 <d34dh0r53> #topic open discussion 15:38:59 <d34dh0r53> drencrom 15:39:02 <d34dh0r53> Review patch proposal: https://review.opendev.org/c/openstack/keystone/+/951792 15:39:04 <d34dh0r53> It is passing ldap tests with the devstack patches 15:39:39 <drencrom> Hi, just wanted to mention that my AD patch is now passing the ldap tests 15:40:01 <d34dh0r53> sweet, I'll review this week 15:40:25 <drencrom> thanks! 15:40:47 <drencrom> it depends on a couple of devstack patches 15:41:07 <d34dh0r53> ack 15:42:00 <d34dh0r53> anything else for open discussion? 15:42:46 <dmendiza[m]> kind of 15:43:31 <dmendiza[m]> Although its kind-of mostly tempest related 15:43:51 <dmendiza[m]> I'm helping a teammate with a security compliance test 15:43:53 <mharley[m]> I'm going through gtema's repo with the Keystone's rewriting. Intend to contribute with it. 15:44:32 <dmendiza[m]> 🦀 15:45:02 <dmendiza[m]> tempest does not currently test the keystone option for setting a security compliance regex 15:45:13 <dmendiza[m]> I'm helping with a patch to add one: 15:45:15 <dmendiza[m]> #link https://review.opendev.org/c/openstack/tempest/+/954029 15:46:23 <dmendiza[m]> it turns out that security_compliance is turned on by default, which is cool, but now the new test is causing everything to fail 15:46:45 <dmendiza[m]> I'm not sure of the best way to fix it though 🤔 15:47:10 <dmendiza[m]> Since security_compliance is turned on by default in all other jobs, then we could argue that all other jobs should also have a regex set. 15:47:10 <dmendiza[m]> * Pros: security compliance is tested everywhere 15:47:10 <dmendiza[m]> * Cons: we may break more things by introducing regex validation to every single other test case 15:47:44 <d34dh0r53> I think we definitely need to move towards testing with the regex 15:48:35 <dmendiza[m]> Cool ... other options include defaulting to security_compliance = false --- which I don't want to do, or splitting the security compliance tests into multiple options in tempest.conf (not ideal) 15:49:36 <dmendiza[m]> We'll update the patches to set the regex everywhere ... and then probalby not even need a new job that's specific for security compliance since it'll be tested in all other jobs. 👍️ 15:49:50 <d34dh0r53> cool! 15:50:11 <d34dh0r53> anything else for open discussion? 15:52:28 <d34dh0r53> mharley: did you have something? 15:54:55 <d34dh0r53> cool, moving on 15:55:14 <d34dh0r53> #topic bug review 15:55:16 <d34dh0r53> #link https://bugs.launchpad.net/keystone/?orderby=-id&start=0 15:55:21 <d34dh0r53> a couple of new keystone bugs 15:55:42 <d34dh0r53> #link https://bugs.launchpad.net/keystone/+bug/2119091 15:55:48 <mharley[m]> Nope. 15:55:57 <d34dh0r53> dmendiza: this one may be up your alley 15:56:51 <dmendiza[m]> Ack, set an #action for me, please 👍️ 15:57:12 <d34dh0r53> #action dmendiza look into https://bugs.launchpad.net/keystone/+bug/2119091 15:57:17 <d34dh0r53> we also have 15:57:24 <d34dh0r53> #link https://bugs.launchpad.net/keystone/+bug/2119031 15:57:30 <bbobrov> i have reported 2119031 and i have 4 ideas for fixing it 15:57:33 <d34dh0r53> which Boris is working on 15:57:44 <d34dh0r53> ahh, hi bbobrov o/ 15:57:46 <bbobrov> idea 1 is to just invalidate cache every time. Bad idea, because cache will become useless after a certain rate. 15:57:49 <bbobrov> o/ 15:57:59 <bbobrov> idea 2 is here: https://review.opendev.org/c/openstack/keystone/+/956176. List all expiring groups, compare to the existing ones, if they differ - drop the cache 15:58:19 <bbobrov> (patch was not tested at all, please do not merge it yet, i should mark it as wip) 15:58:32 <bbobrov> idea 3 is idea 2 + checks of ttls and cache timeout. I don't exactly understand how cache works when a group membership expires. 15:58:43 <bbobrov> Which is why we might need to add an additional check, that the existing group membership will live after the cache expiry, and if not, delete the cache. 15:58:55 <bbobrov> i haven't done it yet, because idea 2 is already complex, and this will add even more complexity. 15:59:13 <bbobrov> idea 4 is to document this as a known issue, and live with it. Users who run into the bad cache will just need to wait. I don't like this too much. 15:59:48 <bbobrov> other suggestions would be appreciated 16:03:30 <d34dh0r53> I like idea 3, but it does add some complexity. Can we see how well idea 2 works in testing and determine if we need the additional checks of idea 3? 16:04:09 <bbobrov> yes, i am doing it. But doing it is *very* slow, because i don't see a way to unit-test this 16:06:09 <d34dh0r53> Yeah, I don't either, it seems like it has to be manual testing 16:07:29 <d34dh0r53> moving on for the sake of time 16:07:33 <bbobrov> yep 16:07:35 <d34dh0r53> #link https://bugs.launchpad.net/python-keystoneclient/?orderby=-id&start=0 16:07:40 <d34dh0r53> no new bugs here 16:07:45 <d34dh0r53> #link https://bugs.launchpad.net/keystoneauth/+bugs?orderby=-id&start=0 16:07:53 <d34dh0r53> nor in keystoneauth 16:07:57 <d34dh0r53> #link https://bugs.launchpad.net/keystonemiddleware/+bugs?orderby=-id&start=0 16:08:09 <d34dh0r53> keystonemiddleware is good 16:08:13 <d34dh0r53> #link https://bugs.launchpad.net/pycadf/+bugs?orderby=-id&start=0 16:08:20 <d34dh0r53> no new bugs in pycadf 16:08:22 <d34dh0r53> #link https://bugs.launchpad.net/ldappool/+bugs?orderby=-id&start=0 16:08:28 <d34dh0r53> ldappool is also good 16:08:33 <d34dh0r53> #topic conclusion 16:08:40 <d34dh0r53> thanks all, nothing else from me 16:09:12 <d34dh0r53> #endmeeting 16:09:20 <d34dh0r53> s/// 16:09:26 <d34dh0r53> #endmeeting