15:01:48 <d34dh0r53> #startmeeting keystone 15:01:48 <opendevmeet> Meeting started Wed Jul 3 15:01:48 2024 UTC and is due to finish in 60 minutes. The chair is d34dh0r53. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:01:48 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:01:48 <opendevmeet> The meeting name has been set to 'keystone' 15:02:02 <d34dh0r53> #topic roll call 15:02:03 <d34dh0r53> admiyo, bbobrov, crisloma, d34dh0r53, dpar, dstanek, hrybacki, knikolla[m], lbragstad, lwanderley, kmalloc, rodrigods, samueldmq, ruan_he, wxy, sonuk, vishakha, Ajay, rafaelwe, xek, gmann, zaitcev, reqa, dmendiza[m], mharley, jph, gtema 15:02:53 <xek> o/ 15:03:02 <gtema> o/ 15:03:46 <d34dh0r53> o/ 15:04:23 <d34dh0r53> #topic review past meeting work items 15:05:01 <d34dh0r53> #link https://meetings.opendev.org/meetings/keystone/2024/keystone.2024-06-26-15.01.html 15:05:09 <d34dh0r53> no work items of note 15:05:20 <d34dh0r53> #topic liaison updates 15:07:02 <d34dh0r53> from the VMT side of things 15:07:09 <d34dh0r53> #link https://security.openstack.org/ossa/OSSA-2024-001.html 15:07:45 <gtema> a nasty thing, but which does not affect Keystone, anyway important for people to know 15:07:47 <d34dh0r53> was released yesterday, it doesn't affect keystone per se, but it does impact openstack significantly which is why I'm calling it out here 15:07:54 <d34dh0r53> yep 15:08:28 <d34dh0r53> for releases, Dalmatian-2 was this week 15:08:47 <d34dh0r53> no blockers from us so everything has progressed 15:08:58 <d34dh0r53> that's it for liaison updates 15:08:58 <d34dh0r53> moving on 15:09:08 <Luzi> o/ 15:09:13 <d34dh0r53> #topic specification OAuth 2.0 (hiromu) 15:09:27 <d34dh0r53> #link https://review.opendev.org/q/topic:bp%252Foauth2-client-credentials-ext 15:09:39 <d34dh0r53> #link https://review.opendev.org/q/topic:bp%252Fenhance-oauth2-interoperability 15:09:40 <mhen> o/ 15:09:57 <d34dh0r53> #link https://review.opendev.org/q/topic:bp%252Fsupport-oauth2-mtls 15:09:59 <d34dh0r53> no updates from me on this 15:10:11 <d34dh0r53> Hi Luzi and mhen o/ 15:10:23 <d34dh0r53> next up 15:10:35 <d34dh0r53> #topic specification Secure RBAC (dmendiza[m]) 15:10:44 <d34dh0r53> #link https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#z-release-timeline_ 15:10:58 <d34dh0r53> dmendiza: is on PTO today so no updates on SRBAC 15:11:19 <d34dh0r53> #topic specification Improve federated users management (gtema) 15:11:26 <d34dh0r53> #link https://review.opendev.org/c/openstack/keystone/+/920892 15:11:48 <d34dh0r53> I started reviewing this but haven't finished yet 15:11:51 <gtema> still waiting for reviews ;-) 15:11:58 <gtema> sounds good 15:12:06 <gtema> anything found so far 15:12:08 <gtema> ? 15:12:16 <gtema> I mean conceptually 15:12:37 <d34dh0r53> not that I can see 15:13:13 <gtema> ok, that's promising, because it is more conceptually a question then implementation 15:13:31 <d34dh0r53> right 15:14:14 <d34dh0r53> next up 15:14:15 <d34dh0r53> #topic specification OpenAPI support (gtema) 15:14:34 <d34dh0r53> #link https://review.opendev.org/q/topic:%22openapi%22+project:openstack/keystone 15:14:50 <gtema> so 15:14:55 <d34dh0r53> Are these ready for reviews or still WIP? 15:15:00 <gtema> I pushed first wip changes for people to see what it is 15:15:17 <gtema> well, 2 first are ready 15:15:34 <gtema> I mean adding job for openapi generator and adding a validation framework as such 15:15:47 <gtema> adding schemas as WIP and there is one thing to discuss 15:16:18 <gtema> also stephenfin noticed that as well: with this style that we are adding across all services we have a small change in behavior 15:16:36 <gtema> namely that we need to validate input first and evaluate policy after that 15:17:11 <gtema> so with invalid input user is getting 403 now, but will get 400 with new validation 15:17:58 <gtema> and so the question is: do we agree that it make sense to do first a routing and understand whether the input is valid before we evaluate whether user is allowed to perform that operation 15:18:09 <gtema> basically this is how other services work 15:18:50 <gtema> otherwise, if that is nok and we want to keep the behavior, I would also need to rework policy evaluation and convert it to decorators as well 15:19:03 <mhen> "valid" as in a) "is number or string" or b) "project id exists"? 15:19:09 <gtema> #link the discussion is in https://review.opendev.org/c/openstack/keystone/+/923181 15:19:25 <gtema> a) number or string 15:19:38 <gtema> this is purely jsonschema based input validation 15:19:47 <gtema> no access to DB or whatsoever 15:19:50 <mhen> good, otherwise it would be a risk to expose things before authorizing users 15:20:16 <gtema> I repeat - this is how other services work, so it is not something unique 15:20:31 <gtema> one point to underline here is that sometimes the body is influencing routing 15:20:49 <gtema> and we can't properly route the request before we actually analyze the input 15:21:43 <d34dh0r53> I'm okay with the 400, it's a bit outside of what the RFC states but an argument can be made that it is malformed 15:22:31 <gtema> 400 is what we also use now, just that it is thrown after policy evaluation take place 15:22:50 <d34dh0r53> I see 15:23:34 <gtema> more or less I need to know now whether it is ok for us to change order (and thus behavior) because it influences dramatically how I should address the changes 15:26:53 <d34dh0r53> I'm good with changing the order, I can't think of a reason not to 15:27:26 <gtema> ok, great. I would appreciate if you can add small comment on that in the referred change for protocoling 15:27:36 <d34dh0r53> I will do that 15:27:42 <gtema> thanks 15:28:01 <d34dh0r53> thank you! 15:28:03 <d34dh0r53> next up 15:28:08 <d34dh0r53> #topic open discussion 15:28:16 <d34dh0r53> move reviewaton to 14:00 during Daylight time (d34dh0r53) 15:28:28 <d34dh0r53> any objections? 15:28:31 <d34dh0r53> UTC time 15:28:50 <gtema> that is very desired by me, cause I have mentoring meeting at 15 and it is nearly impossible to move it 15:29:35 <d34dh0r53> ack 15:32:08 <d34dh0r53> cool, I'll move the meeting to 14:00 UTC 15:32:25 <gtema> perfect, thanks a lot 15:32:36 <d34dh0r53> #action d34dh0r53 move reviewathon to 14:00 UTC for Daylight time 15:32:47 <d34dh0r53> we'll revisit the time once DST rolls around for everyone 15:32:51 <d34dh0r53> next up 15:32:59 <d34dh0r53> domain manager (mhen) 15:33:07 <d34dh0r53> https://review.opendev.org/c/openstack/keystone-specs/+/903172 15:33:14 <mhen> spec freeze is approaching - can we still make it? 15:33:30 <gtema> we agreed last week to do the best possible to squeeze it 15:33:34 <gtema> in 15:34:38 <d34dh0r53> Grzegorz Grasza: can you review this today? 15:34:44 <gtema> Dave Wilde (d34dh0r53): do you happen to know if dmendiza is in PTO only today or longer? 15:34:54 <d34dh0r53> The rest of the week 15:35:03 <gtema> uh, ok 15:36:42 <gtema> from my pov all his comments were addressed and landing spec is not landing implementation 15:36:44 <d34dh0r53> I'll see if I can get Grzegorz Grasza to do it 15:36:53 <mhen> thank you d34dh0r53 15:37:14 <d34dh0r53> np 15:38:05 <d34dh0r53> #topic bug review 15:38:13 <d34dh0r53> #link https://bugs.launchpad.net/keystone/?orderby=-id&start=0 15:38:37 <d34dh0r53> no new bugs for keystone 15:38:47 <d34dh0r53> #link https://bugs.launchpad.net/python-keystoneclient/?orderby=-id&start=0 15:39:05 <d34dh0r53> python-keystoneclient is good to go 15:39:06 <d34dh0r53> #link https://bugs.launchpad.net/keystoneauth/+bugs?orderby=-id&start=0 15:39:27 <d34dh0r53> nothing new in keystoneauth 15:39:28 <d34dh0r53> #link https://bugs.launchpad.net/keystonemiddleware/+bugs?orderby=-id&start=0 15:39:47 <d34dh0r53> nor in keystonemiddleware 15:39:49 <d34dh0r53> #link https://bugs.launchpad.net/pycadf/+bugs?orderby=-id&start=0 15:40:01 <d34dh0r53> pycadf is good 15:40:08 <d34dh0r53> #link https://bugs.launchpad.net/ldappool/+bugs?orderby=-id&start=0 15:40:27 <d34dh0r53> so is ldappool 15:40:33 <d34dh0r53> #topic conclusion 15:40:45 <d34dh0r53> Tomorrow is a US holiday so I'll be out 15:41:08 <gtema> oh yeah. Have fun 15:41:17 <d34dh0r53> Thank you! 15:41:42 <d34dh0r53> Thanks folks! 15:41:46 <d34dh0r53> #endmeeting