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