15:01:32 #startmeeting keystone 15:01:32 Meeting started Wed Mar 13 15:01:32 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:32 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:01:32 The meeting name has been set to 'keystone' 15:01:38 #topic roll call 15:01:47 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:01:50 o/ 15:02:50 o/ 15:02:55 🙋 15:03:00 #topic review past meeting work items 15:03:04 #link https://meetings.opendev.org/meetings/keystone/2024/keystone.2024-02-28-15.02.html 15:03:31 no updates on my action items 15:03:40 #action d34dh0r53 Look into adding/restoring a known issues section to our documentation 15:03:45 d34dh0r53 add https://bugs.launchpad.net/keystone/+bug/1305950 to the known issues section of our documentation 15:03:49 #action d34dh0r53 add https://bugs.launchpad.net/keystone/+bug/1305950 to the known issues section of our documentation 15:03:56 moving on 15:04:01 #topic liaison updates 15:04:05 nothing from VMT, 15:04:19 working on approving all of the caracal-1 things 15:04:24 for release management 15:04:57 #topic specification OAuth 2.0 (hiromu) 15:05:14 #link https://review.opendev.org/q/topic:bp%252Foauth2-client-credentials-ext 15:05:16 #link https://review.opendev.org/q/topic:bp%252Fenhance-oauth2-interoperability 15:05:18 External OAuth 2.0 Specification 15:05:20 #link https://review.opendev.org/c/openstack/keystone-specs/+/861554 15:05:22 OAuth 2.0 Implementation 15:05:24 #link https://review.opendev.org/q/topic:bp%252Fsupport-oauth2-mtls 15:05:26 OAuth 2.0 Documentation 15:05:28 #link https://review.opendev.org/c/openstack/keystone/+/838108 15:05:30 #link https://review.opendev.org/c/openstack/keystoneauth/+/838104 15:06:04 hmm, hiromu hasn't been around in quite a while, anyone know what the status of this work is? 15:08:03 ok, next up 15:08:23 #topic specification Secure RBAC (dmendiza[m]) 15:08:26 Secure RBAC (dmendiza[m]) 15:08:28 #link https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#z-release-timeline_ 15:08:30 2024.1 Release Timeline 15:08:32 Update oslo.policy in keystone to enforce_new_defaults=True 15:08:34 Update oslo.policy in keystone to enforce_scope=True 15:08:36 #link https://review.opendev.org/c/openstack/keystone/+/902730 (Merged) 15:08:38 #link https://review.opendev.org/c/openstack/keystone-tempest-plugin/+/903713 15:08:44 o/ 15:08:54 hi mharley, welcome :) 15:08:57 ^^ was also merged. 15:09:01 woot 15:09:02 Hi. Thanks! 15:09:45 Next, I'm working on getting Keystone tested in the Tempest repo 15:09:57 Tempest already has an SRBAC test, but it is not currently testing Keystone 15:10:01 WIP patch is here: 15:10:05 ahh 15:10:05 #link https://review.opendev.org/c/openstack/tempest/+/912489 15:10:17 Two issues so far 15:10:38 First, I'm trying to figure out how Tempest decides the scope of the admin clients 15:10:55 Tempest has an option to auto-create networks when dynamically creating accounts 15:11:00 but it's using the wrong scope to do it 15:11:05 so it is currently failing for SRBAC 15:12:04 There seem to be some inconsistencies in the devstack plugin that sets up srbac for keystone 15:12:16 that's not surprising :) 15:12:22 I am unsure why policy.yaml needs to be set here: 15:12:24 #link https://opendev.org/openstack/keystone/src/branch/master/devstack/lib/scope.sh#L18 15:12:47 Also admin_system is supposed to be set to all, but it is currently set to true: 15:12:49 #link https://opendev.org/openstack/keystone/src/branch/master/devstack/lib/scope.sh#L24 15:13:24 We also probably want to use... (full message at ) 15:13:32 hmm 15:13:52 instead of what we currently use: [identity-feature-enabled] enforce_scope = true 15:14:00 #link https://opendev.org/openstack/keystone/src/branch/master/devstack/lib/scope.sh#L23 15:14:05 yeah, I think we definitely want to switch to that 15:14:20 although the docs are pretty confusing 15:14:23 So yeah, more work to do in SRBAC 15:15:15 ack, thanks dmendiza[m] 15:15:33 next up 15:15:40 #topic specification Improve federated users management (gtema) 15:15:47 #link https://review.opendev.org/c/openstack/keystone-specs/+/748748 - waiting for reviews 15:16:11 so after you last review there were minor nits to the spec and it was updated 15:16:36 I saw that, I'll take some to to re-review this week 15:16:48 and since there were also again questions about mess in federation setup I decided to do "-1" on the way of api change, since it only makes it more complex 15:16:59 but sadly after that Rafael is not responding 15:17:35 I would appreciate if you analyze this particular issue on your re-review 15:17:54 yes, I will focus on that 15:18:04 perfect, thanks 15:18:20 no problem, anything else on that? 15:18:36 btw, I proposed https://review.opendev.org/c/openstack/keystone-specs/+/910584 for next cycle to start improving openapi life 15:18:54 great, I'll take a look at that as well 15:19:18 great. This is a "copy" of same for Nova, so it is not something totally crazy 15:19:53 excellent 15:21:01 #topic open discussion 15:21:05 passlib update 15:21:07 The maintainer responded to the bug, and one of the top priorities is to fix the bcrypt version bug 15:21:09 #link https://foss.heptapod.net/python-libs/passlib/-/issues/190 15:21:11 The maintainer is working on setting up some more core reviewers and maintainers so the project so that the project will no longer be unmaintained 15:21:38 I noticed that today as well, great news 15:21:41 I think we can just hold on and wait for an updated passlib which is nice and should save us quite a bit of work in trying to remove it 15:22:14 but also he himself admitted it got too complex - this is exactly what I observed looking at the code 15:22:28 its over-designed 15:23:04 indeed, I think multiple project realized the same thing. Hopefully going forward it will be streamlined into what people use it for 15:23:31 right 15:24:06 based on the feedback from the maintenance status bug I think several projects will step up to help maintain it as it's used in a *lot* of places 15:24:30 indeed. Would be great to see that 15:24:45 anything else for open-discussion? 15:25:26 just a heads up that i proposed backports of https://review.opendev.org/c/openstack/keystone/+/908850 to all open branches because otherwise they're just going to lead to zuul configuration errors as soon as the node labels are removed (which for centos-7 will be friday, but the others will be soon as well) 15:26:04 in order to expedite things, i may just go ahead and bypass gating to merge those directly in gerrit, if there are no objections 15:26:21 #link https://review.opendev.org/q/topic:%22drop-centos-7%22 15:26:25 thanks fungi, I have no objections 15:26:52 appreciated 15:27:27 likewise! 15:27:34 mainly, some branches are in a bad enough state that the cleanup simply can't be merged any other way without disabling or fixing lots of other jobs in the process 15:29:59 yeah :/ 15:32:09 moving on 15:32:13 #topic bug review 15:32:24 #link https://bugs.launchpad.net/keystone/?orderby=-id&start=0 15:32:37 no new bugs for keystone 15:32:47 #link https://bugs.launchpad.net/python-keystoneclient/?orderby=-id&start=0 15:32:54 nor for python-keystoneclient 15:33:04 #link https://bugs.launchpad.net/keystoneauth/+bugs?orderby=-id&start=0 15:33:19 keystoneauth is good 15:33:26 #link https://bugs.launchpad.net/keystonemiddleware/+bugs?orderby=-id&start=0 15:33:40 so is keystonemiddleware 15:33:50 #link https://bugs.launchpad.net/pycadf/+bugs?orderby=-id&start=0 15:34:00 nothing new for pycadf 15:34:10 #link https://bugs.launchpad.net/ldappool/+bugs?orderby=-id&start=0 15:34:22 ldappool is also good to go 15:34:26 #topic conclusion 15:35:01 Reminder to register for the PTG 15:35:10 #link https://ptg2024.openinfra.dev 15:35:27 It's free and virtual 15:35:56 I'm thinking about hosting 2 1-hour sessions, but if we need more please let me know and I can add them 15:36:57 That does it for me, thanks folks! 15:37:01 #endmeeting