15:02:36 <d34dh0r53> #startmeeting keystone 15:02:36 <opendevmeet> Meeting started Wed Apr 16 15:02:36 2025 UTC and is due to finish in 60 minutes. The chair is d34dh0r53. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:02:36 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:02:36 <opendevmeet> The meeting name has been set to 'keystone' 15:03:29 <d34dh0r53> Reminder: This meeting takes place under the OpenInfra Foundation Code of Conduct 15:03:37 <gtema> thanks Dave, I was stuck in the limbo of compilation 15:04:07 <xek> o/ 15:04:34 <d34dh0r53> #link https://openinfra.dev/legal/code-of-conduct 15:04:35 <gtema> o/ 15:04:39 <d34dh0r53> #topic roll call 15:04:47 <d34dh0r53> #topic review past meeting work items 15:05:05 <d34dh0r53> #undo 15:05:05 <opendevmeet> Removing item from minutes: #topic review past meeting work items 15:05:07 <d34dh0r53> sorry 15:05:11 <d34dh0r53> got ahead of myself 15:05:29 <d34dh0r53> admiyo, bbobrov, crisloma, d34dh0r53, dpar, dstanek, hrybacki, lbragstad, lwanderley, kmalloc, rodrigods, samueldmq, ruan_he, wxy, sonuk, vishakha, Ajay, rafaelwe, xek, gmann, zaitcev, reqa, dmendiza[m], dmendiza, mharley, jph, gtema, cardoe, deydra 15:05:51 <d34dh0r53> and a shoutout to dmendiza 15:07:20 <d34dh0r53> #topic review past meeting work items 15:07:38 <d34dh0r53> there wasn't a meeting last week (PTG) and we didn't have any from the previous week 15:07:38 <gtema> i feel irc bridge has a lag now. Do you guys want me to send out a summary of PTG discussions through the mailing list? 15:07:43 <d34dh0r53> #link https://meetings.opendev.org/meetings/keystone/2025 15:08:04 <d34dh0r53> gtema: Yeah, that would be good 15:08:09 <mharley[m]> o/ 15:08:13 <dmendiza[m]> 🙋♂️ 15:08:13 <gtema> ok, will do that tomorrow 15:08:27 <d34dh0r53> Thank you! 15:08:50 <dmendiza[m]> +1 to PTG summary 15:09:03 <mharley[m]> +2 15:11:42 <d34dh0r53> #topic liaison updates 15:12:13 <d34dh0r53> nothing from me, but there are VMT changes afoot that shouldn't affect us too much since we have VMT members already 15:12:13 <xek> I'd like to volunteer to be the Security liaison for keystone 15:13:02 <xek> I see right now dmendiza is listed in https://wiki.openstack.org/wiki/CrossProjectLiaisons#Vulnerability_management 15:13:12 <gtema> sure, why not 15:13:17 <d34dh0r53> That's awesome, thanks Grzegorz Grasza 15:14:06 <xek> I'll also volunteer for Barbican 15:15:27 <d34dh0r53> I'll figure out how to change that for keystone (unless someone already knows what repo that's in) and add your name 15:15:52 <d34dh0r53> #topic specification OAuth 2.0 (hiromu) 15:16:19 <d34dh0r53> #link https://review.opendev.org/q/topic:bp%252Foauth2-client-credentials-ext 15:16:22 <d34dh0r53> #link https://review.opendev.org/q/topic:bp%252Fenhance-oauth2-interoperability 15:16:27 <d34dh0r53> External OAuth 2.0 Specification 15:16:32 <d34dh0r53> #link https://review.opendev.org/c/openstack/keystone-specs/+/861554 (merged) 15:16:44 <d34dh0r53> OAuth 2.0 Implementation 15:16:49 <d34dh0r53> #link https://review.opendev.org/q/topic:bp%252Fsupport-oauth2-mtls (merged) 15:16:53 <d34dh0r53> OAuth 2.0 Documentation 15:16:58 <d34dh0r53> #link https://review.opendev.org/c/openstack/keystone/+/838108 (merged) 15:17:03 <d34dh0r53> #link https://review.opendev.org/c/openstack/keystoneauth/+/838104 (merged) 15:17:29 <d34dh0r53> no updates from me 15:17:36 <d34dh0r53> #topic specification Secure RBAC (dmendiza[m]) 15:17:41 <d34dh0r53> #link https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#z-release-timeline_ 15:17:43 <d34dh0r53> 2024.1 Release Timeline 15:17:47 <d34dh0r53> Update oslo.policy in keystone to enforce_new_defaults=True 15:17:58 <d34dh0r53> Update oslo.policy in keystone to enforce_scope=True 15:18:54 <dmendiza[m]> I need to review current status... 15:19:08 <dmendiza[m]> ... but I think we're already defaulting to True in both? 15:19:20 <d34dh0r53> I think so 15:19:28 <dmendiza[m]> I think there's some pending domain-level tempest tests too 15:23:38 <gtema> wrt VMT Liasons: apparently all it takes is just an edit of the https://wiki.openstack.org/wiki/CrossProjectLiaisons. I have however weird feeling about who is allowed to make updates to it 15:24:06 <d34dh0r53> Ok cool 15:24:25 <d34dh0r53> I'll suggest an edit and see how it goes :) 15:24:42 <d34dh0r53> anything else on srbac dmendiza ? 15:24:56 <dmendiza[m]> Not right now... 15:25:27 <d34dh0r53> Cool, thanks 15:25:32 <d34dh0r53> #topic specification OpenAPI support (gtema) 15:25:37 <d34dh0r53> #link https://review.opendev.org/q/topic:%22openapi%22+project:openstack/keystone 15:26:19 <gtema> unfortunately I was (and still am) caught in other limbo of openapi related work on the codegenerator side, so no progress explicitly on the keystone side 15:26:39 <gtema> in the meanwhile I have seen that the new openstackdocstheme is slowly rolling out new api ref docs 15:27:02 <gtema> I also fixed few things in the codegenerator that parses this new output 15:27:35 <gtema> we have noticed one interesting (not really openapi related) stuff for domain group users 15:28:19 <gtema> current python-keystoneclient takes domain_id as a param which is respected in the user groups case, but not in the group users (or vie versa) 15:28:55 <gtema> anyway - the api-ref does not state anything about filtering the results, but the code does filter explciitly by the scope 15:29:58 <gtema> but much worse issue is with glance api design - CSP is able to modify supported enum values. Luckily this is not what we have in Keystone 15:30:30 <gtema> just that we need to ensure we are not introducing any APIs where property is enum which can be altered by the deployment 15:30:55 <gtema> all sort of CLI/TUI/UI is literally broken in such case 15:31:18 <gtema> that's it on the topic for this week 15:31:47 <d34dh0r53> ack, thanks gtema 15:31:57 <d34dh0r53> #topic open discussion 15:32:48 <gtema> nothing from me this time 15:32:53 <d34dh0r53> I don't have anything other than to say it was a good PTG, thanks for the participation and ideas. Interesting days ahead for keystone :) 15:33:04 <gtema> :) 15:33:22 <mharley[m]> Guys, I was checking the Keystone's specs. 15:33:47 <mharley[m]> It seems the only proposal for the 2025.1 cycle was this one: https://github.com/openstack/keystone-specs/blob/master/specs/keystone/2025.1/pci-dss-invalid-password-reporting.rst. 15:33:54 <mharley[m]> Does anyone know if it has been implemented? 15:34:32 <gtema> it was not merged in time 15:34:43 <gtema> but it is in master now 15:35:21 <mharley[m]> Understood. So, no further specs are open to be implemented? I see the backlog directory is around six or seven years old... 15:36:05 <gtema> the federation improvements are like experiment without a spec 15:36:14 <gtema> since this is not landing in the Keystone in the current form 15:37:04 <gtema> other than that there are no specs and things we want to introduce 15:38:07 <mharley[m]> You mean, the federation feature was implemented but it doesn't have a corresponding specification? 15:39:32 <xek> I'll work on the OAuth2.0, but it's just implementing the missing peaces, so no new specs needed for that 15:39:58 <gtema> no, I am working on redoing federation from scratch in Rust cli without spec, because atm final design is not fixed 15:41:24 <xek> (I meant specifically External OAuth2.0, which is not really federation) 15:41:53 <dmendiza[m]> Somewhat related to Blueprints ... the Launchpad project probably needs some TLC. 15:43:04 <gtema> oh right 15:44:14 <dmendiza[m]> I can help clean up branches and such 15:44:34 <gtema> thanks a lot dmendiza 15:45:11 <d34dh0r53> Yeah, I've been negligent in that regard :/ 15:45:11 <mharley[m]> dmendiza:, are you referring this? 15:45:12 <mharley[m]> https://blueprints.launchpad.net/keystone/ 15:46:19 <dmendiza[m]> mharley: yeah, that one. Well, not just the blueprints, but the series and milestones 15:47:33 <mharley[m]> It seems there is a couple of issues with no assignees. :-) 15:49:07 <dmendiza[m]> Oh yeah, we've got an endless backlog of bugs 😅 15:50:06 <gtema> just 254, not that bad 15:50:34 <dmendiza[m]> If we fix one a day we might be done by the end of the year 😛 15:51:10 <d34dh0r53> lol 15:51:28 <gtema> we may propose a fix, but surely not land one change a day (not on weekends) 15:51:32 <d34dh0r53> OBAD (One Bug A Day) 15:51:43 <mharley[m]> hahaha 15:52:19 <mharley[m]> Start the campaign: adopt a bug. And do that every single day. :-( 15:52:59 <gtema> ouch, that's gonna hurt 15:53:48 <d34dh0r53> Indeed, speaking of bugs we should move on for the sake of time 15:53:54 <d34dh0r53> #topic bug review 15:53:57 <gtema> indeed 15:54:00 <d34dh0r53> #link https://bugs.launchpad.net/keystone/?orderby=-id&start=0 15:54:23 <d34dh0r53> one new bug in keystone 15:54:28 <d34dh0r53> #link https://bugs.launchpad.net/keystone/+bug/2107423 15:55:01 <gtema> I'll have a look 15:55:17 <d34dh0r53> thanks 15:55:22 <d34dh0r53> #link https://bugs.launchpad.net/python-keystoneclient/?orderby=-id&start=0 15:55:40 <d34dh0r53> nothing new here 15:55:46 <d34dh0r53> #link https://bugs.launchpad.net/keystoneauth/+bugs?orderby=-id&start=0 15:56:02 <d34dh0r53> we have a new one in keystoneauth 15:56:07 <d34dh0r53> #link https://bugs.launchpad.net/keystoneauth/+bugs?orderby=-id&start=0 15:56:20 <d34dh0r53> #undo 15:56:20 <opendevmeet> Removing item from minutes: #link https://bugs.launchpad.net/keystoneauth/+bugs?orderby=-id&start=0 15:56:30 <d34dh0r53> #link https://bugs.launchpad.net/keystoneauth/+bug/2107373 15:56:48 <d34dh0r53> Looks like a fix has been proposed 15:57:04 <d34dh0r53> so we should review 15:58:52 <d34dh0r53> There are several related bugs from the last few weeks in keystoneauth, all seem to be somewhat related to OIDC or Device Authorization 15:59:11 <d34dh0r53> #link https://bugs.launchpad.net/keystonemiddleware/+bugs?orderby=-id&start=0 15:59:37 <d34dh0r53> we have a new one in keystonemiddleware as well 15:59:47 <d34dh0r53> #link https://bugs.launchpad.net/keystonemiddleware/+bugs?orderby=-id&start=0 15:59:58 <d34dh0r53> #undo 15:59:58 <opendevmeet> Removing item from minutes: #link https://bugs.launchpad.net/keystonemiddleware/+bugs?orderby=-id&start=0 16:00:16 <d34dh0r53> https://bugs.launchpad.net/keystonemiddleware/+bug/2106597 16:00:30 <d34dh0r53> #link https://bugs.launchpad.net/keystonemiddleware/+bug/2106597 16:03:04 <gtema> hmm, weird one 16:04:19 <d34dh0r53> yeah 16:04:51 <dmendiza[m]> I wonder if it can't tell the difference between a 403 because the subject token is not good or a 403 because the service credentials are no good 16:07:21 <d34dh0r53> yeah, let's try to investigate this one 16:07:23 <d34dh0r53> next up 16:07:23 <d34dh0r53> #link https://bugs.launchpad.net/pycadf/+bugs?orderby=-id&start=0 16:07:26 <d34dh0r53> no new bugs in pycadf 16:07:29 <d34dh0r53> #link https://bugs.launchpad.net/ldappool/+bugs?orderby=-id&start=0 16:07:43 <d34dh0r53> ldappool is good as well 16:07:46 <d34dh0r53> #topic conclusion 16:08:04 <gtema> thanks Dave 16:08:07 <d34dh0r53> nothing more from me 16:08:35 <d34dh0r53> thank you all 16:08:38 <d34dh0r53> #endmeeting