15:00:51 <d34dh0r53> #startmeeting keystone 15:00:51 <opendevmeet> Meeting started Wed Nov 8 15:00:51 2023 UTC and is due to finish in 60 minutes. The chair is d34dh0r53. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:52 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:52 <opendevmeet> The meeting name has been set to 'keystone' 15:01:17 <d34dh0r53> #topic roll call 15:01:19 <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] 15:01:21 <d34dh0r53> o/ 15:01:28 <mhen> o/ 15:02:01 <hiromu> o/ 15:02:32 <d34dh0r53> hi all, let's get started 15:02:34 <d34dh0r53> #topic review past meeting work items 15:02:54 <xek> o/ 15:02:55 <dmendiza[m]> 🙋 15:02:58 <d34dh0r53> #link https://meetings.opendev.org/meetings/keystone/2023/keystone.2023-10-18-15.01.html 15:03:08 <d34dh0r53> 2 past work items, both for me, both no updates on 15:03:16 <d34dh0r53> #action d34dh0r53 Look into adding/restoring a known issues section to our documentation 15:03:23 <d34dh0r53> #action d34dh0r53 add https://bugs.launchpad.net/keystone/+bug/1305950 to the known issues section of our documentation 15:03:33 <d34dh0r53> next up 15:03:36 <d34dh0r53> #topic liaison updates 15:03:50 <d34dh0r53> nothing from VMT 15:05:50 <d34dh0r53> I think we're good on the releases front as well, there were some stable branch patches that came in to fix the gates and only one is left with a transient failure 15:06:11 <d34dh0r53> #topic specification OAuth 2.0 (hiromu) 15:06:21 <d34dh0r53> #link https://review.opendev.org/q/topic:bp%252Foauth2-client-credentials-ext 15:06:23 <d34dh0r53> #link https://review.opendev.org/q/topic:bp%252Fenhance-oauth2-interoperability 15:06:25 <d34dh0r53> External OAuth 2.0 Specification 15:06:27 <d34dh0r53> #link https://review.opendev.org/c/openstack/keystone-specs/+/861554 15:06:29 <d34dh0r53> OAuth 2.0 Implementation 15:06:31 <d34dh0r53> #link https://review.opendev.org/q/topic:bp%252Fsupport-oauth2-mtls 15:06:33 <d34dh0r53> OAuth 2.0 Documentation 15:06:35 <d34dh0r53> #link https://review.opendev.org/c/openstack/keystone/+/838108 15:06:37 <d34dh0r53> #link https://review.opendev.org/c/openstack/keystoneauth/+/838104 15:06:50 <hiromu> I have one topic that I want to discuss today, regarding Zuul jobs for Ext. OAuth2.0 support 15:06:57 <hiromu> https://etherpad.opendev.org/p/keystone-weekly-meeting 15:07:41 <hiromu> I have a problem while implementing tests. It gonna be too many Zuul jobs. 15:08:16 <hiromu> Ext. OAuth2.0 support feature has 5 different authentication methods and I think we need to test all of them. 15:08:18 <d34dh0r53> hmm 15:08:45 <hiromu> However, if we want change the method, we need to update config and restart openstack services (e.g., tacker, barbican, etc) 15:09:10 <hiromu> I think it's not good idea to restart services within a Zuul job. 15:09:54 <hiromu> but, if we split the job, we need to create 5 jobs (correspoinding to authn methods) per a service. 15:10:04 <xek> It can be done, although usually that happens during the configuration step 15:10:58 <xek> But maybe one configuration is sufficient to test the integration? 15:11:14 <hiromu> it gonnabe testing, restarting, testing the same job... 15:11:18 <xek> The various cases are tested with unit tests 15:11:23 <d34dh0r53> that's what I was wondering, if there is one configuration that is good enough 15:11:52 <hiromu> I think we need to chance codes to do that 15:12:44 <hiromu> https://review.opendev.org/c/openstack/keystonemiddleware/+/868734/16/keystonemiddleware/external_oauth2_token.py#62 15:12:53 <hiromu> This is the config I am talking 15:13:07 <hiromu> about 15:13:55 <d34dh0r53> can't we override that config option in the test itself? 15:15:07 <hiromu> sorry, what does you mean by override exactly? 15:15:14 <xek> oslo.config supports reloading the config, so maybe it's possible without restarting the service 15:16:15 <hiromu> I see 15:16:53 <hiromu> okay, I'll try that and see if it's possible in our case. 15:17:11 <hiromu> anyway you think putting many jobs is not good idea, is that right? 15:17:48 <d34dh0r53> it's not ideal but it can be done 15:18:20 <hiromu> I mean if overriding is not possible, restarting with in a single Zuul job is better or splitting job into many jobs is better?. 15:19:24 <hiromu> I thought many jobs having simple test is better than making a complex job where restarting happens inside it 15:19:49 <xek> I'm guessing most of the runtime will be setting the environment, so in that case it's preferable to have one job 15:20:11 <d34dh0r53> agree, job spinup is expensive 15:20:33 <hiromu> okay, I understand. 15:21:03 <hiromu> anyway thank you for the discussion. I'll try overiding first. 15:21:13 <d34dh0r53> thank you hiromu, anything else for your spec? 15:21:25 <hiromu> I don't have, thanks. 15:22:09 <d34dh0r53> great, moving on 15:22:26 <d34dh0r53> #topic specification Secure RBAC (dmendiza[m]) 15:22:38 <d34dh0r53> #link https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#z-release-timeline_ 15:22:40 <d34dh0r53> 2024.1 Release Timeline 15:22:42 <d34dh0r53> Update oslo.policy in keystone to enforce_new_defaults=True 15:22:44 <d34dh0r53> Update oslo.policy in keystone to enforce_scope=True 15:23:08 <dmendiza[m]> Heya! 15:23:15 <dmendiza[m]> Not a whole lot on RBAC 15:24:05 <d34dh0r53> ack 15:24:09 <d34dh0r53> thanks dmendiza[m] 15:24:41 <d34dh0r53> mhen: I moved your topic to open discussion as it's not a spec 15:24:43 <dmendiza[m]> Hey sorry wife called 15:24:51 <d34dh0r53> no worries dmendiza[m] 15:24:55 <dmendiza[m]> I did attend the RBAC meeting 15:24:58 <dmendiza[m]> this week 15:24:59 <mhen> d34dh0r53: thanks and sorry for the misplacement 15:25:11 <dmendiza[m]> and gmann asked if we could review this patch: https://review.opendev.org/c/openstack/keystone/+/886434 15:25:48 <d34dh0r53> ahh, ack 15:25:49 <dmendiza[m]> I also volunteered to change the defaults and add a job to test with the old policies 15:26:12 <d34dh0r53> ok 15:28:37 <d34dh0r53> thanks for volunteering to do that 15:31:02 <d34dh0r53> anything else for RBAC? 15:31:26 <dmendiza[m]> Nope that's it for today 15:32:44 <d34dh0r53> thanks dmendiza[m] 15:32:56 <d34dh0r53> #topic opendiscussion 15:33:05 <d34dh0r53> we have one topic 15:33:09 <d34dh0r53> domain scoping for "GET /v3/domains" (mhen) 15:33:34 <d34dh0r53> bug: #link https://bugs.launchpad.net/keystone/+bug/2041611 15:33:37 <d34dh0r53> patch: #link https://review.opendev.org/c/openstack/keystone/+/900028 15:33:39 <d34dh0r53> looking for reviewers 15:33:41 <d34dh0r53> Zuul tests fail 15:33:43 <d34dh0r53> "keystone_tempest_plugin.tests.rbac" seems to be the culprit 15:33:45 <d34dh0r53> how can patches of the keystone_tempest_plugin be integrated in a way that the patchset above incorporates it in its testing? (i.e. interlinked patchsets between keystone and keystone_tempest_plugin that depend on each other) 15:33:55 <mhen> hi 15:34:04 <d34dh0r53> dmendiza[m]: can you take a look at the failures? 15:34:08 <d34dh0r53> hi mhen! 15:35:15 <mhen> the unittests that I adjusted for this endpoint in the patchset expected a different behavior - I guess it's the same for the RBAC tests of the tempest plugin 15:35:29 <mhen> so those need adjustments as well 15:36:20 <mhen> I can also have a look myself but I'd need guidance on how I can make it so that it interlinks with the patchest in keystone to appease Zuul 15:36:29 <mhen> *patchset 15:37:59 <d34dh0r53> I would guide you to dmendiza[m], he knows the RBAC testing infra better than anyone 15:38:36 <dmendiza[m]> 👀 15:40:20 <d34dh0r53> :) 15:40:44 <mhen> let's say I have two patchsets on review.opendev.org, one for keystone and one for keystone-tempest-plugin, how can I tell Zuul to test the former using the latter and not the current master branch of keystone-tempest-plugin? 15:42:46 <dmendiza[m]> You can use "Depends-On:" 15:43:04 <d34dh0r53> dmendiza[m], xek: does depends-on do that across projects? 15:43:19 <d34dh0r53> ahh, yeah, what dmendiza[m] said :) 15:43:23 <dmendiza[m]> e.g. make a patch for Keystone with the necessary changes, then in the tempest-plugin patch add "Depends-On: <url for keystone change>" 15:43:52 <mhen> in the commit messag? 15:43:55 <dmendiza[m]> yeah 15:44:20 <mhen> alright, got it 15:44:23 <dmendiza[m]> ... although now that I think about it, the keystone one needs to know about the tempest-plugin patch too because it also runs tempest. 15:44:41 <mhen> yea that's the direction I was going for 15:44:46 <dmendiza[m]> so maybe, what you need is to make the changes in keystone and also make the tempest job non-voting in the same patch (because we'll expect a failure) 15:45:10 <d34dh0r53> yeah 15:45:15 <dmendiza[m]> Then the tempest-plugin patch with "Depends-On: <url to keystone patch>" in the commit message 15:45:35 <dmendiza[m]> then a third patch to re-enable the job in keystone that Depends-On the tempest-plugin patch 15:48:17 <mhen> so I'd add "voting: false" to the "keystone-protection-functional" entry in .zuul.yaml ? 15:48:45 <mhen> (to "make the tempest job non-voting") 15:49:55 <dmendiza[m]> yep 15:50:20 <mhen> thanks, I'll try the 3-step approach you outlined 15:50:42 <d34dh0r53> awesome, thanks dmendiza[m] and mhen ! 15:51:39 <mhen> if anybody reviews the patchset, please state your opinion on my comment about the RBAC "target" variable structure: https://review.opendev.org/c/openstack/keystone/+/900028/1/keystone/api/domains.py#104 15:52:01 <mhen> I was a bit unsure when implementing it since the groups and projects endpoints approach it differently 15:53:00 <d34dh0r53> will do 15:53:09 <mhen> thanks :) 15:53:10 <d34dh0r53> anything else for open discussion? 15:53:19 <mhen> nothing from my side 15:54:34 <d34dh0r53> great, moving on 15:54:44 <d34dh0r53> #topic bug review 15:54:48 <d34dh0r53> #link https://bugs.launchpad.net/keystone/?orderby=-id&start=0 15:54:55 <d34dh0r53> we have a couple of new bugs for keystone 15:55:03 <d34dh0r53> and one RFE 15:55:07 <d34dh0r53> first up, the RFE 15:55:33 <d34dh0r53> #link https://bugs.launchpad.net/keystone/+bug/2039269 15:56:37 <d34dh0r53> I marked this as wishlist as it doesn't appear to be a bug but rather an enhancement 15:56:56 <d34dh0r53> next up 15:57:00 <d34dh0r53> #link https://bugs.launchpad.net/keystone/+bug/2040299 15:57:20 <d34dh0r53> this looks like it might be a bug and I'll try to take a look this week 15:57:29 <d34dh0r53> unless someone else wants it :) 15:57:53 <d34dh0r53> next up is mhen's bug 15:57:56 <d34dh0r53> #link https://bugs.launchpad.net/keystone/+bug/2041611 15:58:23 <d34dh0r53> and finally we have what may be a configuration issue, but I'm not sure without some testing 15:58:32 <d34dh0r53> #link https://bugs.launchpad.net/keystone/+bug/2042744 15:59:15 <d34dh0r53> moving on to python-keystoneclient 15:59:18 <d34dh0r53> #link https://bugs.launchpad.net/python-keystoneclient/?orderby=-id&start=0 15:59:41 <d34dh0r53> no new bugs there 15:59:49 <d34dh0r53> moving on to keystoneauth 15:59:54 <d34dh0r53> #link https://bugs.launchpad.net/keystoneauth/+bugs?orderby=-id&start=0 16:00:22 <d34dh0r53> one new bug that looks like it already has a patch up 16:00:25 <d34dh0r53> #link https://bugs.launchpad.net/keystoneauth/+bug/2042670 16:01:31 <d34dh0r53> next up is keystonemiddleware 16:01:32 <d34dh0r53> #link https://bugs.launchpad.net/keystonemiddleware/+bugs?orderby=-id&start=0 16:01:41 <d34dh0r53> nothing new there 16:01:47 <d34dh0r53> pycadf is next 16:01:52 <d34dh0r53> #link https://bugs.launchpad.net/pycadf/+bugs?orderby=-id&start=0 16:02:03 <d34dh0r53> clean 16:02:06 <d34dh0r53> finally ldappool 16:02:11 <d34dh0r53> #link https://bugs.launchpad.net/ldappool/+bugs?orderby=-id&start=0 16:02:17 <d34dh0r53> also good 16:02:22 <d34dh0r53> #topic conclusion 16:02:32 <d34dh0r53> I don't have anything 16:02:58 <d34dh0r53> thanks folks! Reviewathon on Friday :) 16:03:01 <d34dh0r53> #endmeeting