15:07:49 <gtema> #startmeeting keystone
15:07:49 <opendevmeet> Meeting started Wed Nov 26 15:07:49 2025 UTC and is due to finish in 60 minutes.  The chair is gtema. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:07:49 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:07:49 <opendevmeet> The meeting name has been set to 'keystone'
15:07:59 <gtema> Reminder: This meeting takes place under the OpenInfra Foundation Code of Conduct
15:08:03 <dmendiza[m]> 🙋‍♂️
15:08:15 <gtema> #link https://openinfra.dev/legal/code-of-conduct
15:08:26 <gtema> #topic roll call
15:08:33 <gtema> 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:41 <gtema> so it's you and me only
15:11:08 <gtema> with just 2 of us the official meeting makes no sense to me, what do you think dmendiza ? We can just run quickly through open topics
15:11:28 <dmendiza[m]> Sure, I don't have much to talk about
15:11:44 <gtema> what about the security compliance testing?
15:12:05 <dmendiza[m]> Yeah, that's been on the back burner for a bit
15:12:24 <dmendiza[m]> IIRC, we left off with gtema being on board for changing the default from True to False
15:13:22 * dmendiza[m] checks CRs
15:14:27 <dmendiza[m]> #link https://review.opendev.org/c/openstack/devstack/+/957969
15:14:27 <gtema> we can maybe recheck the devstack change - it failed last time 20 days ago - it's like back in the stone age on the today's pace
15:14:40 <Moutaz_Chaara> Hi, I'm Moutaz Chaara. I have a patch fixing federated user role assignment caching issues at https://review.opendev.org/c/openstack/keystone/+/967048 - would appreciate reviews when possible.
15:14:41 <dmendiza[m]> Yeah, I'll rebase the CR and keep an eye on it
15:14:57 <gtema> I am looking at it Moutaz_Chaara
15:15:22 <Moutaz_Chaara> Thank you gtema
15:15:23 <gtema> was just wondering why do we need a notification for cache invalidation
15:17:54 <gtema> dmendiza: when is Grzegorz Grasza back?
15:18:35 <dmendiza[m]> gtema: I think Grzegorz Grasza should be back next week.
15:18:48 <gtema> ok, thks
15:19:12 <dmendiza[m]> No reviewathon this week btw, Thanksgiving holiday is tomorrow and pretty much everyone is off Friday as well.
15:19:37 <gtema> oh right, good that you say this. I will not wait like last week
15:20:23 <Moutaz_Chaara> From my understanding the keystone uses multiple instances, and when a fedrated user's group memebership changes, only one instance proc3ess it. but all instances have cached tokens.
15:20:55 <Moutaz_Chaara> and noticed that without the notification, validated tokens with old group memberships would remain cached and accepted as valid, even though the role assignments have been recalculated.
15:21:31 <gtema> Moutaz_Chaara: it is supposed to use one memcache cluster for all instances. This way when you invalidate a cache on one instance it is purged everywhere
15:23:35 <gtema> it is currently used mostly for when the token cache needs to be invalidated, which s in the case when user group memberships are updated upon relogin is anyway automatically the "case"
15:23:49 <gtema> I do not see it necessary in this case
15:25:01 <Moutaz_Chaara> hmm you are right, will this cover the two caches, the assignments region, and token region?
15:26:32 <gtema> well, the notification on it's own has nothing to do with the cache invalidation anyway - it only emits audit entry and adds a record into the revocation table
15:27:09 <gtema> and you invalidate the assignments region manually anyway
15:27:43 <gtema> I think you may want to invalidate the identity cache though
15:27:52 <gtema> due to the user group relations updated
15:28:56 <Moutaz_Chaara> But the token_region is a seperate cache region maintained by token provider. the assignment has no direct way to invalidate it. that's why was thinking the approach of notification is needed. wdyt?
15:29:13 <gtema> but the expiring group membership is not cached at all from what I see, so it should not be necessary
15:29:46 <gtema> hmmm
15:30:53 <gtema> notification, as said - is not triggering cache invalidation
15:30:59 <gtema> it is only an audit log entry
15:32:52 <gtema> theoretically we may want to create a revocation record when group membership changes. For such case we may also want to emit audit record
15:34:15 <gtema> but it is also not trivial. We should not automatically revoke all user tokens, only those with affected new/dropped privileges
15:34:29 <gtema> but there is no way to actually calculate this reasonably
15:35:10 <Moutaz_Chaara> ok, i thought the drop_token_cache will be triggered as a result of the notification. - will need to debug it and verify.
15:35:28 <gtema> no, this is definitely not the case
15:35:37 <Moutaz_Chaara> ok
15:37:10 <gtema> I would need to sleep over with those thoughts. The user already tries to re-login, so we should update the group membership and corresponding role assignments. The token cache is supposed to be automatically overwritten later in the code chain anyway
15:37:56 <gtema> so perhaps we do not need anything additional.
15:38:13 <gtema> I hate this caching - it only makes problems everywhere
15:39:10 <Moutaz_Chaara> as they say there are 2 hard problems in computer science: cache invalidation, naming things.
15:39:29 <Moutaz_Chaara> I will try to see the whole execution path for that one, still don't have the big picture until yet.
15:40:39 <gtema> right. I can imagine how euphoric devs feel when they see how cache improves performance of selected cases. But I was being more euphoric when I figured out that my code with no cache is faster that the existing one with cache. And adding cache had 0 impact
15:41:03 <gtema> or actually was making it slower because of introducing network roundtrip
15:41:49 <gtema> anyway, It seems we have no new bugs in any deliverables
15:42:54 <Moutaz_Chaara> yeah agree it makes the simple problems complicated. But good if it is used wisely xD.
15:42:58 <gtema> I self-approved change today on dropping scrypt from keystone requirements, since we do not use it anyway and this is a necessary change before that gets dropped from general requirements repo
15:43:52 <gtema> there is nothing else from my side. Anything from you folks?
15:44:32 <Moutaz_Chaara> nothing from my side, will take a deeper debugging about that notification execustion trace and get back to you.
15:44:41 <Moutaz_Chaara> Thanks for the feedback.
15:44:55 <gtema> thank you for working on that issue as well
15:45:17 <gtema> than we are done for today
15:45:18 <gtema> #endmeeting