| *** zseguin is now known as Guest14350 | 07:21 | |
| opendevreview | Mauricio Harley proposed openstack/keystone master: Add transparent PBKDF2-SHA512 password rehashing on login https://review.opendev.org/c/openstack/keystone/+/992893 | 10:10 |
|---|---|---|
| opendevreview | Mauricio Harley proposed openstack/keystone master: Increase PBKDF2-SHA512 default iterations to 600,000 https://review.opendev.org/c/openstack/keystone/+/991059 | 10:24 |
| *** ralonsoh_ is now known as ralonsoh | 11:01 | |
| opendevreview | Grzegorz Grasza proposed openstack/keystone master: Use constant-time comparison for TOTP passcode validation https://review.opendev.org/c/openstack/keystone/+/999082 | 11:12 |
| opendevreview | Grzegorz Grasza proposed openstack/keystone master: Sign SAML assertions with SHA-256 instead of SHA-1 https://review.opendev.org/c/openstack/keystone/+/999083 | 11:12 |
| opendevreview | Grzegorz Grasza proposed openstack/keystone master: Fix dropped validation constraints in role_assignments schema https://review.opendev.org/c/openstack/keystone/+/999084 | 11:15 |
| opendevreview | Grzegorz Grasza proposed openstack/keystone master: Fix dropped validation constraints in role_assignments schema https://review.opendev.org/c/openstack/keystone/+/999084 | 11:23 |
| d34dh0r53 | #startmeeting keystone | 15:01 |
| opendevmeet | Meeting started Wed Jul 29 15:01:36 2026 UTC and is due to finish in 60 minutes. The chair is d34dh0r53. Information about MeetBot at http://wiki.debian.org/MeetBot. | 15:01 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 15:01 |
| opendevmeet | The meeting name has been set to 'keystone' | 15:01 |
| d34dh0r53 | Reminder: This meeting takes place under the OpenInfra Foundation Code of Conduct | 15:01 |
| d34dh0r53 | #link https://openinfra.dev/legal/code-of-conduct | 15:01 |
| d34dh0r53 | #topic roll call | 15:01 |
| 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:02 |
| d34dh0r53 | o/ dmendiza | 15:02 |
| gtema | o/ | 15:02 |
| moutazchaara[m] | /o | 15:02 |
| cardoe | o/ (though I've not looked at keystone since the last time cause I've been neck deep in neutron) | 15:02 |
| dmendiza[m] | 🙋♂️ | 15:02 |
| dmendiza[m] | Appreciate the artisanal bespoke ping | 15:03 |
| d34dh0r53 | hand crafted | 15:03 |
| dmendiza[m] | pasture raised, locally sourced | 15:03 |
| d34dh0r53 | 100% organic | 15:03 |
| d34dh0r53 | lol | 15:03 |
| dmendiza[m] | 😂 | 15:04 |
| d34dh0r53 | #topic review past meeting work items | 15:04 |
| d34dh0r53 | #link https://meetings.opendev.org/meetings/keystone/2026/keystone.2026-07-22-15.01.html | 15:04 |
| d34dh0r53 | I have an action item but I'm not sure if I'm going to get to it in a meaningful time. I'm on bereavement leave next week, followed by PTO and then some more bereavement leave | 15:04 |
| d34dh0r53 | dwilde plan mid-cycle keystone virtual meetup | 15:05 |
| dmendiza[m] | s/mid-cycle/late-cycle/ | 15:05 |
| d34dh0r53 | yeah, that's what I'm thinking | 15:06 |
| d34dh0r53 | going to defer that till later in the cycle | 15:06 |
| d34dh0r53 | next up | 15:06 |
| d34dh0r53 | #topic liaison updates | 15:06 |
| d34dh0r53 | nothing from me | 15:06 |
| gtema | neither from me | 15:06 |
| d34dh0r53 | cool | 15:07 |
| d34dh0r53 | #topic specification Secure RBAC (dmendiza) | 15:07 |
| d34dh0r53 | #link https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#z-release-timeline_ | 15:07 |
| d34dh0r53 | 2026.1 Release Timeline | 15:07 |
| d34dh0r53 | Update oslo.policy in keystone to enforce_new_defaults=True | 15:07 |
| d34dh0r53 | Update oslo.policy in keystone to enforce_scope=True | 15:08 |
| d34dh0r53 | Fix config options in keystone-tempest-plugin https://review.opendev.org/c/openstack/keystone-tempest-plugin/+/930829 | 15:08 |
| d34dh0r53 | keystone-tempest-plugin has merged | 15:08 |
| dmendiza[m] | Nice | 15:08 |
| d34dh0r53 | anything else on SRBAC dmendiza ? | 15:10 |
| dmendiza[m] | I don't think so? ... We can probably take it off the agenda now and revisit removing the deprecated policies at the PTG | 15:11 |
| d34dh0r53 | cool, I'll archive that spec on the etherpad | 15:13 |
| d34dh0r53 | #topic specification Secuirty Compliance Testing (dmendiza) | 15:13 |
| d34dh0r53 | #link https://review.opendev.org/c/openstack/devstack/+/957969 | 15:13 |
| dmendiza[m] | No updates ... I need to revisit this during an Upstream Friday | 15:14 |
| d34dh0r53 | #topic specification User Specified Project/User UUIDs (dmendize, alee) | 15:14 |
| d34dh0r53 | https://review.opendev.org/c/openstack/keystone-specs/+/997320 | 15:14 |
| d34dh0r53 | #link https://review.opendev.org/c/openstack/keystone-specs/+/997320 | 15:14 |
| dmendiza[m] | Yeah, Andre (one of our teammates at RH) is going to keep working on these. Not sure he's in here though? | 15:15 |
| dmendiza[m] | The Project/Domain spec needs to be updated to address gtema 's comments. Not sure the other one for Users has any comments that need addressing yet | 15:16 |
| gtema | not from me yet, had no chance to look into user one except seeing it is same huge long | 15:16 |
| d34dh0r53 | cool, next up | 15:18 |
| d34dh0r53 | #topic keystone-rs | 15:19 |
| d34dh0r53 | #link https://github.com/openstack-experimental/keystone | 15:19 |
| gtema | I am busy with polishing after it was finally deployed in our stage env. | 15:19 |
| gtema | works great, performance is awesome | 15:19 |
| d34dh0r53 | nice | 15:19 |
| gtema | need to apply some fixes in area of missing journalctl support for logging, absence of sql logging, etc | 15:20 |
| gtema | again have seen that some internal caching is only having negative performance impact - so no caching | 15:20 |
| gtema | however understood, that for the case of side-by-side deployment with python keystone I would need to understand how python keystone caches data to be able to invalidate it remotely | 15:21 |
| gtema | token validation with 0 caching takes 5ms while python without cached token 200ms, for warm cache 80ms, for hot cache 25ms | 15:22 |
| gtema | fare-well caching | 15:23 |
| gtema | I am pretty done on features, now really focused on this ops items | 15:23 |
| gtema | that's it for this week | 15:23 |
| d34dh0r53 | that's impressive gtema , thank you | 15:24 |
| d34dh0r53 | #topic open discussion | 15:24 |
| moutazchaara[m] | Hi, I have this one here https://review.opendev.org/c/openstack/keystone/+/997724 | 15:25 |
| moutazchaara[m] | would be great if you gtema Grzegorz Grasza have time to take a look at it | 15:25 |
| gtema | I still remember it. On Rust side I have the same problem and also consider how to implement pagination for composite results (like assignments) | 15:26 |
| moutazchaara[m] | ok, yeah with the ldap the pagination breaks. not sure about the Rust one, i can take a look at it also | 15:27 |
| gtema | I mean it is the same issue conceptually that ldap does not support keyset pagination and we need to invent a solution for this | 15:28 |
| moutazchaara[m] | got it | 15:28 |
| gtema | fetching all and calculate the offset is the most "naive" approach, but depending on the number of entries it is so inefficient | 15:28 |
| moutazchaara[m] | yes it is a naive one, but not really sure if ldap support something works out of the box for that thing | 15:29 |
| gtema | Rust can keep the session to the ldap, so there is a chance of at least using the native ldap pagination inside | 15:29 |
| moutazchaara[m] | but in python it won't actually work with session that way ? | 15:30 |
| gtema | not really - you never know on which node the request for next page lands so you can't reuse the connection cookie | 15:31 |
| moutazchaara[m] | yeah no guarantee | 15:31 |
| moutazchaara[m] | i would suggest to go at least with the naive approach and then we can optimize it. As it is currently actually a bug for the ldap pagination. | 15:31 |
| gtema | not sure it is bug, I guess we are just returning all entries ignoring pagination | 15:32 |
| moutazchaara[m] | np, it is actually broken, you can't get page 2. | 15:32 |
| moutazchaara[m] | the hash was calcuated incorrectly and passed there which ldap is not able to resolve it and lands always on 1st page | 15:33 |
| gtema | I was sure we just return all entries unpaged to the client | 15:34 |
| moutazchaara[m] | if client doesn't has limit, then yeah | 15:34 |
| moutazchaara[m] | but if has limit. it won't make it to the client | 15:34 |
| gtema | my naive fix would be to simply ignore the limit for ldap domain | 15:34 |
| moutazchaara[m] | yes list_limit = 0 and then it will be unlimited, but a pagination is ideal. | 15:35 |
| gtema | I know pagination is ideal, but if for the domain with 5000 users and page size 20-100 you fetch all users multiple times just to discard 90% it is such a terrible waste | 15:38 |
| moutazchaara[m] | yeah, in the patch if the user puts the limit to 5k, then he get's 5k and can paginate with it. | 15:40 |
| moutazchaara[m] | but without the patch if he puts 5k he won't be able to paginate | 15:40 |
| gtema | I would definitely have no problem to simply discard the pagination for the LDAP as the first fix improving it further. Discarding so much data on Keystone is something I am not very comfortable with | 15:42 |
| moutazchaara[m] | yeah that's what we did as preliminary fix | 15:43 |
| moutazchaara[m] | so would you suggest to invest more time into the sessions as there might be a solution for that? | 15:44 |
| gtema | there is pretty much definitely no solution to session in the current keystone architecture | 15:45 |
| gtema | keystone-rs has at least way to address this | 15:45 |
| gtema | since nodes are form a cluster | 15:45 |
| gtema | s/are// | 15:46 |
| gtema | let's move on for the sake of the time | 15:46 |
| moutazchaara[m] | yp | 15:46 |
| d34dh0r53 | good discussion, thanks both! | 15:47 |
| d34dh0r53 | #topic bug review | 15:47 |
| d34dh0r53 | #link https://bugs.launchpad.net/keystone/?orderby=-id&start=0 | 15:47 |
| d34dh0r53 | no new keystone bugs | 15:47 |
| d34dh0r53 | #link https://bugs.launchpad.net/python-keystoneclient/?orderby=-id&start=0 | 15:47 |
| d34dh0r53 | python-keystoneclient is good | 15:48 |
| d34dh0r53 | #link https://bugs.launchpad.net/keystoneauth/+bugs?orderby=-id&start=0 | 15:48 |
| d34dh0r53 | nothing new in keystoneauth | 15:48 |
| d34dh0r53 | #link https://bugs.launchpad.net/keystonemiddleware/+bugs?orderby=-id&start=0 | 15:48 |
| d34dh0r53 | keystonemiddleware is good | 15:48 |
| d34dh0r53 | #link https://bugs.launchpad.net/pycadf/+bugs?orderby=-id&start=0 | 15:48 |
| d34dh0r53 | nothing new in pycadf | 15:48 |
| d34dh0r53 | #link https://bugs.launchpad.net/ldappool/+bugs?orderby=-id&start=0 | 15:48 |
| d34dh0r53 | and ldappool is good | 15:48 |
| d34dh0r53 | #topic conclusion | 15:48 |
| d34dh0r53 | That's all from me, thanks folks! | 15:48 |
| d34dh0r53 | I'm out next week | 15:49 |
| gtema | thanks guys, cy | 15:49 |
| dmendiza[m] | Dave Wilde (d34dh0r53): I can chair next week | 15:49 |
| d34dh0r53 | thanks dmendiza !! | 15:50 |
| d34dh0r53 | #endmeeting | 15:50 |
| opendevmeet | Meeting ended Wed Jul 29 15:50:22 2026 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 15:50 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/keystone/2026/keystone.2026-07-29-15.01.html | 15:50 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/keystone/2026/keystone.2026-07-29-15.01.txt | 15:50 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/keystone/2026/keystone.2026-07-29-15.01.log.html | 15:50 |
| opendevreview | Udayendu Kar proposed openstack/keystone master: Fix updating unified limit resource_limit to zero https://review.opendev.org/c/openstack/keystone/+/999175 | 18:53 |
Generated by irclog2html.py 4.1.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!