15:01:18 <d34dh0r53> #startmeeting keystone
15:01:18 <opendevmeet> Meeting started Wed Feb  5 15:01:18 2025 UTC and is due to finish in 60 minutes.  The chair is d34dh0r53. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:18 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:18 <opendevmeet> The meeting name has been set to 'keystone'
15:01:28 <d34dh0r53> Reminder: This meeting takes place under the OpenInfra Foundation Code of Conduct
15:01:33 <d34dh0r53> #link https://openinfra.dev/legal/code-of-conduct
15:01:38 <d34dh0r53> #topic roll call
15:01:40 <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
15:01:43 <gtema> o/
15:01:55 <d34dh0r53> Super special ping for dmendiza
15:02:04 <xek> o/
15:04:00 <d34dh0r53> #topic review past meeting work items
15:04:04 <d34dh0r53> #link https://meetings.opendev.org/meetings/keystone/2025/keystone.2025-01-22-15.03.html
15:04:11 <d34dh0r53> no action items to review
15:04:15 <d34dh0r53> #topic liaison updates
15:04:36 <d34dh0r53> no updates from VMT or release management
15:05:49 <d34dh0r53> #topic specification OAuth 2.0 (hiromu)
15:05:50 <d34dh0r53> #link https://review.opendev.org/q/topic:bp%252Foauth2-client-credentials-ext
15:05:51 <d34dh0r53> #link https://review.opendev.org/q/topic:bp%252Fenhance-oauth2-interoperability
15:05:55 <d34dh0r53> External OAuth 2.0 Specification
15:05:57 <d34dh0r53> #link https://review.opendev.org/c/openstack/keystone-specs/+/861554 (merged)
15:06:00 <d34dh0r53> OAuth 2.0 Implementation
15:06:02 <d34dh0r53> #link https://review.opendev.org/q/topic:bp%252Fsupport-oauth2-mtls (merged)
15:06:05 <d34dh0r53> OAuth 2.0 Documentation
15:06:07 <d34dh0r53> #link https://review.opendev.org/c/openstack/keystone/+/838108 (merged)
15:06:10 <d34dh0r53> #link https://review.opendev.org/c/openstack/keystoneauth/+/838104 (merged)
15:07:00 <d34dh0r53> I did some review and the main thing we're waiting on are some functional jobs to be added in other projects, namely barbican and tacker
15:07:34 <d34dh0r53> We're also missing two keystone-tempest-plugin patches that I'll try to rebase today
15:08:03 <d34dh0r53> That's in on OAuth 2.0
15:08:07 <d34dh0r53> #topic specification Secure RBAC (dmendiza[m])
15:08:09 <d34dh0r53> #link https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#z-release-timeline_
15:08:12 <d34dh0r53> 2024.1 Release Timeline
15:08:14 <d34dh0r53> Update oslo.policy in keystone to enforce_new_defaults=True
15:08:16 <d34dh0r53> Update oslo.policy in keystone to enforce_scope=True
15:08:34 <d34dh0r53> i don't think dmendiza is around, but I'll give it a couple of minutes
15:10:19 <d34dh0r53> next up
15:10:22 <d34dh0r53> #topic specification OpenAPI support (gtema)
15:10:24 <d34dh0r53> #link https://review.opendev.org/q/topic:%22openapi%22+project:openstack/keystone
15:10:39 <d34dh0r53> I see there are a couple of patches for me to review, will do that after this meeting
15:10:55 <gtema> few changes are up to review. I just retriggered recheck on them to see fresh results from codegenerator
15:11:19 <gtema> since it wasn't working due to corrupted schema landed
15:11:41 <gtema> but anyway - seen one pretty interesting case wrt schemas and internal implementation on the endpoint region vs region_id front
15:12:32 <gtema> in our work we were reimplementing openstackclient to use sdk instead of keystoneclient and managed to end up with entry in the catalog with non empty region_id and region = Null
15:12:43 <gtema> I mean really explicit null value.
15:13:07 <gtema> in the normal API case this is not going to happen, but it was present in the catalog inside the token
15:13:28 <gtema> not something we should worry about here, just a fun fact of scrunity
15:14:01 <gtema> I am also frustrated by the fact that I am not able to land changes in the openstackdocstheme required to start rendering openapi specs
15:14:49 <gtema> was even thinking about starting just embedding swagger, but that is going to fail in the same way - collision of bootstrap versions
15:15:47 <gtema> so I was also thinking about tweaking api-ref job to build openapi separately and render it using custom theme and then copy it to the regular results so that we can publish it
15:15:59 <gtema> (sort of invisible without direct link)
15:16:04 <gtema> what do you think?
15:17:21 <d34dh0r53> What's the resistance to landing changes directly in openstackdocstheme?
15:17:26 <d34dh0r53> Just review capacity?
15:17:41 <gtema> its not a resistance, just nobody cares
15:18:02 <gtema> it's on the TC table for more then a month already with still no change
15:18:38 <d34dh0r53> hmm
15:19:05 <d34dh0r53> How hard is the api-ref tweak?
15:19:11 <gtema> in my rust poc I embedded the openapi directly into the binary so that it is rendered with the api (vendor) and it is so cooool
15:19:55 <gtema> api-ref tweak should not be hard, but it introduces new steps into it and a dependency that might fail. I will try to implement it fail safe so that the normal build is not affected
15:20:12 <gtema> it is just that it seems to be the only way to start publishing specs
15:20:24 <gtema> at least for now
15:20:40 <d34dh0r53> ack, I say go for it
15:20:57 <gtema> ok, thks
15:21:10 <d34dh0r53> anything else on openapi?
15:21:19 <gtema> nope
15:21:48 <d34dh0r53> #topic specification domain manager (mhen)
15:21:51 <d34dh0r53> still unmerged are:
15:21:53 <d34dh0r53> documentation: https://review.opendev.org/c/openstack/keystone/+/928135
15:21:55 <d34dh0r53> tempest tests: https://review.opendev.org/c/openstack/keystone-tempest-plugin/+/924222
15:23:24 <gtema> this now also has some followups - certain CSPs are relying on federation and then it becomes impossible to manage user/group relations (user - role - project is still fine)
15:23:47 <gtema> we try now to figure out what is the way to live properly with it
15:24:19 <gtema> it is not of big problem for upstream, but is certainly a thing for CSPs and certifications
15:24:52 <d34dh0r53> hmm, so the domain manager role makes it harder to manage user/group relations? how so?
15:25:24 <gtema> not really. Certain CSPs want that users are only coming from let's say keycloak and groups are also managed there
15:25:40 <gtema> they want to prevent any changes locally
15:26:02 <gtema> btw, I have also a POC on implementing SCIM for synchronizing data from IdP to Keystone
15:26:09 <opendevreview> Merged openstack/keystoneauth master: typing: Simplify some types, other TODOs  https://review.opendev.org/c/openstack/keystoneauth/+/935764
15:26:11 <d34dh0r53> Oh cool
15:26:46 <gtema> it's a cool thinkg since it is a rust application using openstack_sdk (the rust one) and proxy requests to keystone directly
15:27:08 <gtema> I want to also implement it with direct DB access, but that (as said on Friday) is taking much more time
15:28:08 <d34dh0r53> yeah
15:28:21 <gtema> I need to solve auth problem though
15:28:53 <gtema> generally scim providers typically only allow you to send bearer token or oauth (but that is not what we support now)
15:29:21 <d34dh0r53> Grzegorz Grasza: is working on that, although from a different perspective
15:29:53 <gtema> oh cool to know. Maybe then on Friday we can discuss details
15:30:42 <xek> That's actually what I briefly mentioned last Friday, further developing the external OAuth2.0
15:31:08 <gtema> yeah, I was just going through the spec and I miss there few critical things
15:31:19 <gtema> oauth is only authentication and not authorization
15:31:38 <xek> right, we can discuss this further on Friday
15:31:38 <gtema> so that need/may need to be handled differently
15:31:46 <gtema> perfect
15:32:50 <d34dh0r53> 👍
15:34:04 <d34dh0r53> next up
15:34:09 <d34dh0r53> #topic specification Include bad password details in audit messages (stanislav-z)
15:34:12 <d34dh0r53> #link https://review.opendev.org/c/openstack/keystone-specs/+/915482 (merged)
15:34:15 <d34dh0r53> #link https://review.opendev.org/q/topic:%22pci-dss-invalid-password-reporting%22
15:34:17 <d34dh0r53> #link https://review.opendev.org/c/openstack/keystone/+/932423
15:34:20 <d34dh0r53> 5-Feb update: implementation to be updated to reflect merged spec state (WIP by @stanislav-z)
15:34:47 <stanislav-z> thanks for the reviews of the spec 👍️ I'm on updating the implementation
15:35:32 <d34dh0r53> Awesome, thank you Stanislav Zaprudskiy !
15:35:50 <d34dh0r53> #topic open discussion
15:35:58 <d34dh0r53> I don't have anything
15:36:58 <stanislav-z> I wanted to join Friday's review sessions once, but was hanging in the lobby of the meeting - not sure, perhaps there was no meeting at all that Fri, or do I perhaps need some authorization to join?
15:37:26 <gtema> depends on when exactly
15:37:37 <gtema> it was cancelled few times in Jan
15:38:28 <d34dh0r53> Stanislav Zaprudskiy: if you /msg me your email address I'll add you to the invite
15:38:29 <stanislav-z> I only wanted to be around in case my PRs fall into view - would that be a valid reason to connect?
15:38:38 <stanislav-z> thanks!
15:40:40 <d34dh0r53> no problem
15:41:01 <d34dh0r53> moving on
15:41:05 <d34dh0r53> #topic bug review
15:41:08 <d34dh0r53> #link https://bugs.launchpad.net/keystone/?orderby=-id&start=0
15:41:18 <d34dh0r53> no new bugs for keystone
15:41:26 <d34dh0r53> 'v
15:41:32 <d34dh0r53> oops
15:41:36 <d34dh0r53> #link https://bugs.launchpad.net/python-keystoneclient/?orderby=-id&start=0
15:41:48 <d34dh0r53> python-keystoneclient is good
15:41:50 <d34dh0r53> #link https://bugs.launchpad.net/keystoneauth/+bugs?orderby=-id&start=0
15:42:09 <d34dh0r53> nothing new in keystoneauth
15:42:17 <d34dh0r53> #link https://bugs.launchpad.net/keystonemiddleware/+bugs?orderby=-id&start=0
15:42:43 <d34dh0r53> keystonemiddleware has no new bugs
15:42:46 <d34dh0r53> #link https://bugs.launchpad.net/pycadf/+bugs?orderby=-id&start=0
15:42:49 <d34dh0r53> pycadf is good
15:42:52 <d34dh0r53> #link https://bugs.launchpad.net/ldappool/+bugs?orderby=-id&start=0
15:42:56 <d34dh0r53> so is ldappool
15:43:00 <d34dh0r53> #topic conclusion
15:43:09 <d34dh0r53> nothing from me, thanks everyone!!
15:43:16 <gtema> thanks
15:43:25 <d34dh0r53> #endmeeting