| *** mhen_ is now known as mhen | 01:37 | |
| *** mhen_ is now known as mhen | 08:22 | |
| opendevreview | Luca Miccini proposed openstack/keystonemiddleware stable/2025.1: Add TLS support to MemcacheClientPool https://review.opendev.org/c/openstack/keystonemiddleware/+/954018 | 14:58 |
|---|---|---|
| opendevreview | Boris Bobrov proposed openstack/keystone master: Invalidate cache if expiring groups change https://review.opendev.org/c/openstack/keystone/+/956176 | 15:01 |
| breton | hello, i am here for the weekly meeting | 15:11 |
| mharley[m] | o/ | 15:13 |
| d34dh0r53 | sorry, was heads down | 15:20 |
| d34dh0r53 | #startmeeting keystone | 15:20 |
| 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 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 15:20 |
| opendevmeet | The meeting name has been set to 'keystone' | 15:20 |
| d34dh0r53 | Reminder: This meeting takes place under the OpenInfra Foundation Code of Conduct | 15:22 |
| d34dh0r53 | #link https://openinfra.dev/legal/code-of-conduct | 15:22 |
| d34dh0r53 | #topic roll call | 15:22 |
| 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:22 |
| breton | o/ | 15:23 |
| d34dh0r53 | dmendiza: | 15:23 |
| xek | o/ | 15:23 |
| dmendiza[m] | 🙋♂️ | 15:24 |
| cardoe | o/ | 15:24 |
| d34dh0r53 | #topic review past meeting work items | 15:24 |
| d34dh0r53 | #link https://meetings.opendev.org/meetings/keystone/2025/keystone.2025-07-23-15.08.html | 15:24 |
| d34dh0r53 | no action items from last week | 15:25 |
| d34dh0r53 | #topic liaison updates | 15:25 |
| d34dh0r53 | nothing from me | 15:25 |
| *** breton is now known as bbobrov | 15:25 | |
| d34dh0r53 | #topic specification OAuth 2.0 (hiromu) | 15:26 |
| d34dh0r53 | #link https://review.opendev.org/q/topic:bp%252Foauth2-client-credentials-ext | 15:26 |
| d34dh0r53 | #link https://review.opendev.org/q/topic:bp%252Fenhance-oauth2-interoperability | 15:26 |
| d34dh0r53 | waiting on things to merge in barbican and tacker before we can merge our tempest plugin changes | 15:26 |
| d34dh0r53 | #topic specification Secure RBAC (dmendiza) | 15:26 |
| d34dh0r53 | #link https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#z-release-timeline_ | 15:26 |
| d34dh0r53 | 2025.2 Release Timeline | 15:26 |
| dmendiza[m] | 🙋♂️ | 15:27 |
| d34dh0r53 | Update oslo.policy in keystone to enforce_new_defaults=True | 15:27 |
| d34dh0r53 | Update oslo.policy in keystone to enforce_scope=True | 15:27 |
| dmendiza[m] | I actually do have an update this time! | 15:27 |
| dmendiza[m] | :D | 15:27 |
| dmendiza[m] | Let me find this link ... one sec ... | 15:27 |
| d34dh0r53 | 😲 | 15: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:28 |
| d34dh0r53 | ahh, that's a bummer | 15:29 |
| dmendiza[m] | I think we should flip the switch 👀 | 15:29 |
| 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 |
| dmendiza[m] | I need to remember what we can do in a SLURP/non-SLURP release though 🤔 | 15:30 |
| d34dh0r53 | yeah, I'm in favor of flipping the switch | 15:32 |
| dmendiza[m] | I'll submit a patch to flip it and keep and see what blows up | 15:32 |
| dmendiza[m] | Ugh, I can't type today | 15:32 |
| d34dh0r53 | sounds good | 15:33 |
| dmendiza[m] | Anyway, that's it for SRBAC this week. I'll update next week with patch results. | 15:33 |
| d34dh0r53 | thanks dmendiza | 15:33 |
| d34dh0r53 | next up | 15:33 |
| d34dh0r53 | #topic specification OpenAPI support (gtema) | 15:34 |
| d34dh0r53 | #link https://review.opendev.org/q/topic:%22openapi%22+project:openstack/keystone | 15:34 |
| dmendiza[m] | oh gtema is out on PTO this week and next | 15:35 |
| dmendiza[m] | I imagine right now he's having a delicious dinner of fish and chips next to the Eye of London | 15:35 |
| mharley[m] | ✌️ | 15:36 |
| d34dh0r53 | VPN just booted me | 15:37 |
| d34dh0r53 | not sure if I missed anything | 15:38 |
| dmendiza[m] | tl;dr gtema is ooo for 2 weeks | 15:38 |
| d34dh0r53 | ack, thanks | 15:38 |
| d34dh0r53 | next up | 15:38 |
| d34dh0r53 | #topic open discussion | 15:38 |
| d34dh0r53 | drencrom | 15:38 |
| d34dh0r53 | Review patch proposal: https://review.opendev.org/c/openstack/keystone/+/951792 | 15:39 |
| d34dh0r53 | It is passing ldap tests with the devstack patches | 15:39 |
| drencrom | Hi, just wanted to mention that my AD patch is now passing the ldap tests | 15:39 |
| d34dh0r53 | sweet, I'll review this week | 15:40 |
| drencrom | thanks! | 15:40 |
| drencrom | it depends on a couple of devstack patches | 15:40 |
| d34dh0r53 | ack | 15:41 |
| d34dh0r53 | anything else for open discussion? | 15:42 |
| dmendiza[m] | kind of | 15:42 |
| dmendiza[m] | Although its kind-of mostly tempest related | 15:43 |
| dmendiza[m] | I'm helping a teammate with a security compliance test | 15:43 |
| mharley[m] | I'm going through gtema's repo with the Keystone's rewriting. Intend to contribute with it. | 15:43 |
| dmendiza[m] | 🦀 | 15:44 |
| dmendiza[m] | tempest does not currently test the keystone option for setting a security compliance regex | 15:45 |
| dmendiza[m] | I'm helping with a patch to add one: | 15:45 |
| dmendiza[m] | #link https://review.opendev.org/c/openstack/tempest/+/954029 | 15:45 |
| 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 |
| dmendiza[m] | I'm not sure of the best way to fix it though 🤔 | 15:46 |
| 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 |
| dmendiza[m] | * Pros: security compliance is tested everywhere | 15:47 |
| dmendiza[m] | * Cons: we may break more things by introducing regex validation to every single other test case | 15:47 |
| d34dh0r53 | I think we definitely need to move towards testing with the regex | 15:47 |
| 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:48 |
| 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 |
| d34dh0r53 | cool! | 15:49 |
| d34dh0r53 | anything else for open discussion? | 15:50 |
| d34dh0r53 | mharley: did you have something? | 15:52 |
| d34dh0r53 | cool, moving on | 15:54 |
| d34dh0r53 | #topic bug review | 15:55 |
| d34dh0r53 | #link https://bugs.launchpad.net/keystone/?orderby=-id&start=0 | 15:55 |
| d34dh0r53 | a couple of new keystone bugs | 15:55 |
| d34dh0r53 | #link https://bugs.launchpad.net/keystone/+bug/2119091 | 15:55 |
| mharley[m] | Nope. | 15:55 |
| d34dh0r53 | dmendiza: this one may be up your alley | 15:55 |
| dmendiza[m] | Ack, set an #action for me, please 👍️ | 15:56 |
| d34dh0r53 | #action dmendiza look into https://bugs.launchpad.net/keystone/+bug/2119091 | 15:57 |
| d34dh0r53 | we also have | 15:57 |
| d34dh0r53 | #link https://bugs.launchpad.net/keystone/+bug/2119031 | 15:57 |
| bbobrov | i have reported 2119031 and i have 4 ideas for fixing it | 15:57 |
| d34dh0r53 | which Boris is working on | 15:57 |
| d34dh0r53 | ahh, hi bbobrov o/ | 15:57 |
| bbobrov | idea 1 is to just invalidate cache every time. Bad idea, because cache will become useless after a certain rate. | 15:57 |
| bbobrov | o/ | 15:57 |
| 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:57 |
| bbobrov | (patch was not tested at all, please do not merge it yet, i should mark it as wip) | 15:58 |
| 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 |
| 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 |
| bbobrov | i haven't done it yet, because idea 2 is already complex, and this will add even more complexity. | 15:58 |
| 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 |
| bbobrov | other suggestions would be appreciated | 15:59 |
| 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:03 |
| bbobrov | yes, i am doing it. But doing it is *very* slow, because i don't see a way to unit-test this | 16:04 |
| d34dh0r53 | Yeah, I don't either, it seems like it has to be manual testing | 16:06 |
| d34dh0r53 | moving on for the sake of time | 16:07 |
| bbobrov | yep | 16:07 |
| d34dh0r53 | #link https://bugs.launchpad.net/python-keystoneclient/?orderby=-id&start=0 | 16:07 |
| d34dh0r53 | no new bugs here | 16:07 |
| d34dh0r53 | #link https://bugs.launchpad.net/keystoneauth/+bugs?orderby=-id&start=0 | 16:07 |
| d34dh0r53 | nor in keystoneauth | 16:07 |
| d34dh0r53 | #link https://bugs.launchpad.net/keystonemiddleware/+bugs?orderby=-id&start=0 | 16:07 |
| d34dh0r53 | keystonemiddleware is good | 16:08 |
| d34dh0r53 | #link https://bugs.launchpad.net/pycadf/+bugs?orderby=-id&start=0 | 16:08 |
| d34dh0r53 | no new bugs in pycadf | 16:08 |
| d34dh0r53 | #link https://bugs.launchpad.net/ldappool/+bugs?orderby=-id&start=0 | 16:08 |
| d34dh0r53 | ldappool is also good | 16:08 |
| d34dh0r53 | #topic conclusion | 16:08 |
| d34dh0r53 | thanks all, nothing else from me | 16:08 |
| d34dh0r53 | #endmeeting | 16:09 |
| d34dh0r53 | s/// | 16:09 |
| d34dh0r53 | #endmeeting | 16:09 |
| opendevmeet | Meeting ended Wed Jul 30 16:09:26 2025 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 16:09 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/keystone/2025/keystone.2025-07-30-15.20.html | 16:09 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/keystone/2025/keystone.2025-07-30-15.20.txt | 16:09 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/keystone/2025/keystone.2025-07-30-15.20.log.html | 16:09 |
| cardoe | So as an aside, I landed some RFC8628 conformance fixes to Dex IDP upstream. Their next release should make it that v3oidcdevicecode works out of the box. Happy to contribute some tests against them as well. | 17:39 |
| cardoe | I saw there were some patches in the queue around non-conformant implementations from I believe Canonical. Dex was actually behaving the same way as those implementations so I'm guessing somebody copied some code or behavior or tested against those. | 17:40 |
| d34dh0r53 | yeah, I reviewed the patches by canonical today. I feel like we keep going in circles with the client_id though | 18:16 |
| *** drencrom_ is now known as drencrom | 22:41 | |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!