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