Wednesday, 2025-11-26

*** mhen_ is now known as mhen02:27
*** ykarel_ is now known as ykarel05:59
opendevreviewArtem Goncharov proposed openstack/keystone master: Drop declaring dependency on scrypt  https://review.opendev.org/c/openstack/keystone/+/96844211:06
opendevreviewStephen Finucane proposed openstack/oslo.limit master: fixture: Mock out services, regions  https://review.opendev.org/c/openstack/oslo.limit/+/96846313:02
opendevreviewStephen Finucane proposed openstack/oslo.limit master: Handle missing endpoint, region, service  https://review.opendev.org/c/openstack/oslo.limit/+/96846413:02
opendevreviewStephen Finucane proposed openstack/oslo.limit master: WIP: fixture: Autospec the identity proxy API mock  https://review.opendev.org/c/openstack/oslo.limit/+/96847313:24
dmendiza[m]🙋‍♂️15:07
dmendiza[m]Not sure if Dave Wilde (d34dh0r53) is around for the weekly? 👀15:07
gtemaapparently not15:07
gtema#startmeeting keystone15:07
opendevmeetMeeting 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
opendevmeetUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.15:07
opendevmeetThe meeting name has been set to 'keystone'15:07
gtemaReminder: This meeting takes place under the OpenInfra Foundation Code of Conduct15:08
dmendiza[m]🙋‍♂️15:08
gtema#link https://openinfra.dev/legal/code-of-conduct15:08
gtema#topic roll call15:08
gtemaadmiyo, 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, deydra15:08
gtemaso it's you and me only15:09
gtemawith just 2 of us the official meeting makes no sense to me, what do you think dmendiza ? We can just run quickly through open topics15:11
dmendiza[m]Sure, I don't have much to talk about15:11
gtemawhat about the security compliance testing?15:11
dmendiza[m]Yeah, that's been on the back burner for a bit15:12
dmendiza[m]IIRC, we left off with gtema being on board for changing the default from True to False15:12
* dmendiza[m] checks CRs15:13
dmendiza[m]#link https://review.opendev.org/c/openstack/devstack/+/95796915:14
gtemawe 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 pace15:14
Moutaz_ChaaraHi, 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
dmendiza[m]Yeah, I'll rebase the CR and keep an eye on it15:14
gtemaI am looking at it Moutaz_Chaara 15:14
Moutaz_ChaaraThank you gtema15:15
gtemawas just wondering why do we need a notification for cache invalidation15:15
gtemadmendiza: when is Grzegorz Grasza back?15:17
dmendiza[m]gtema: I think Grzegorz Grasza should be back next week.15:18
gtemaok, thks15:18
dmendiza[m]No reviewathon this week btw, Thanksgiving holiday is tomorrow and pretty much everyone is off Friday as well.15:19
gtemaoh right, good that you say this. I will not wait like last week15:19
Moutaz_ChaaraFrom 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
Moutaz_Chaaraand 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:20
gtemaMoutaz_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 everywhere15:21
gtemait 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
gtemaI do not see it necessary in this case15:23
Moutaz_Chaarahmm you are right, will this cover the two caches, the assignments region, and token region?15:25
gtemawell, 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 table15:26
gtemaand you invalidate the assignments region manually anyway15:27
gtemaI think you may want to invalidate the identity cache though15:27
gtemadue to the user group relations updated15:27
Moutaz_ChaaraBut 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:28
gtemabut the expiring group membership is not cached at all from what I see, so it should not be necessary15:29
gtemahmmm15:29
gtemanotification, as said - is not triggering cache invalidation15:30
gtemait is only an audit log entry15:30
gtematheoretically we may want to create a revocation record when group membership changes. For such case we may also want to emit audit record15:32
gtemabut it is also not trivial. We should not automatically revoke all user tokens, only those with affected new/dropped privileges15:34
gtemabut there is no way to actually calculate this reasonably15:34
Moutaz_Chaaraok, i thought the drop_token_cache will be triggered as a result of the notification. - will need to debug it and verify. 15:35
gtemano, this is definitely not the case15:35
Moutaz_Chaaraok 15:35
gtemaI 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 anyway15:37
gtemaso perhaps we do not need anything additional.15:37
gtemaI hate this caching - it only makes problems everywhere15:38
Moutaz_Chaaraas they say there are 2 hard problems in computer science: cache invalidation, naming things.15:39
Moutaz_ChaaraI will try to see the whole execution path for that one, still don't have the big picture until yet.15:39
gtemaright. 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 impact15:40
gtemaor actually was making it slower because of introducing network roundtrip15:41
gtemaanyway, It seems we have no new bugs in any deliverables15:41
Moutaz_Chaarayeah agree it makes the simple problems complicated. But good if it is used wisely xD. 15:42
gtemaI 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 repo15:42
gtemathere is nothing else from my side. Anything from you folks?15:43
Moutaz_Chaaranothing from my side, will take a deeper debugging about that notification execustion trace and get back to you. 15:44
Moutaz_ChaaraThanks for the feedback. 15:44
gtemathank you for working on that issue as well15:44
gtemathan we are done for today15:45
gtema#endmeeting15:45
opendevmeetMeeting ended Wed Nov 26 15:45:18 2025 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)15:45
opendevmeetMinutes:        https://meetings.opendev.org/meetings/keystone/2025/keystone.2025-11-26-15.07.html15:45
opendevmeetMinutes (text): https://meetings.opendev.org/meetings/keystone/2025/keystone.2025-11-26-15.07.txt15:45
opendevmeetLog:            https://meetings.opendev.org/meetings/keystone/2025/keystone.2025-11-26-15.07.log.html15:45
dmendiza[m]Thanks gtema !15:45
gtema:)15:45
jjung.16:15
opendevreviewMerged openstack/keystone master: Drop declaring dependency on scrypt  https://review.opendev.org/c/openstack/keystone/+/96844216:45

Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!