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