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