15:02:24 <d34dh0r53> #startmeeting keystone
15:02:24 <opendevmeet> Meeting started Wed May 29 15:02:24 2024 UTC and is due to finish in 60 minutes.  The chair is d34dh0r53. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:02:24 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:02:24 <opendevmeet> The meeting name has been set to 'keystone'
15:02:35 <d34dh0r53> #topic roll call
15:02:46 <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], mharley, jph, gtema
15:02:46 <gtema> o/
15:02:47 <mharley[m]> o/
15:02:48 <d34dh0r53> o/
15:04:10 <d34dh0r53> #topic review past meeting work items
15:04:17 <d34dh0r53> #link https://meetings.opendev.org/meetings/keystone/2024/keystone.2024-05-22-15.01.html
15:04:51 <d34dh0r53> I've been thinking about my action item and I think it's best to handle those things with release notes and not have a known issues as I don't think anyone has the bandwidth to maintain it
15:05:26 <d34dh0r53> So...without any objections I'll punt on the known issues section
15:06:12 <gtema> wfm
15:06:30 <d34dh0r53> cool
15:06:49 <d34dh0r53> moving on
15:07:21 <d34dh0r53> #topic liaison updates
15:07:52 <d34dh0r53> nothing from VMT or releases
15:08:49 <d34dh0r53> #topic specification OAuth 2.0 (hiromu)
15:08:59 <d34dh0r53> #link https://review.opendev.org/q/topic:bp%252Foauth2-client-credentials-ext... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/kdtXgbfJHgyeUToLyMzvoNEp>)
15:09:51 <d34dh0r53> I'm going to work on rebasing the last outstanding patch and see how it goes
15:09:58 <d34dh0r53> next up we have
15:10:15 <d34dh0r53> #topic specification Secure RBAC (dmendiza[m])... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/pHxYbHZRGakynbkUtTdYMcJo>)
15:11:38 <d34dh0r53> dmendiza: you around?
15:13:00 <dmendiza[m]> 🙋
15:13:16 <dmendiza[m]> I don't htink we have any SRBAC udpates this week?
15:13:26 <dmendiza[m]> Maybe just the tempest-plugin 0.16.0 release?
15:14:06 <d34dh0r53> Yeah, we released a new version of keystone-tempest-plugin last week, it contains the latest SRBAC testing fixes
15:15:10 <dmendiza[m]> #link https://releases.openstack.org/dalmatian/index.html#keystone-tempest-plugin
15:17:57 <d34dh0r53> awesome, thanks dmendiza !
15:18:00 <d34dh0r53> next up
15:18:16 <d34dh0r53> #topic specification Improve federated users management (gtema) (on-hold until 05/29)
15:18:16 <d34dh0r53> #link https://review.opendev.org/c/openstack/keystone-specs/+/748748
15:18:16 <d34dh0r53> gtema: revoke support for the approach
15:18:32 <gtema> this one is going to be long
15:18:46 <gtema> I was thinking long time, prototyping, modelling
15:19:01 <gtema> talking also to mnasser on his tour across Europe
15:19:35 <gtema> and came to conclusion, that the approach is wrong. You should not try to model roles/projects/users/groups/domains mapping outside of Keystone
15:19:48 <gtema> and leave IdP to take care of users and groups
15:20:09 <gtema> with https://github.com/vexxhost/keystone-keycloak-backend it is very easy to get users visible in Keystone
15:20:53 <gtema> and once user is disabled in Keycloak (external IdP) it becomes immediately applied on Keystone side and user is not able to continue accessing cloud i.e. using ApplicationCredentials
15:21:11 <gtema> note: this is not the case with ephemeral users
15:21:17 <gtema> BUT
15:21:42 <gtema> Keystone docs recommend to create out-of tree drivers for cases like that  - all good
15:21:54 <gtema> the problem comes with configuration of out-of-tree backend drivers
15:22:12 <gtema> option a) FS (as domain_specific configs)
15:22:41 <gtema> this option works great except that it requires restart of keystone once you add new domain - this is a no go
15:22:51 <gtema> option b) DB
15:23:18 <gtema> here there is a problem that current implementation does not allow having drivers their own configuration
15:23:43 <gtema> and more then that, the API of domain_configs is hardcoding options that can be set
15:23:58 <gtema> so now let's come to questions:
15:24:24 <gtema> what is the preferred/recommended way dealing with config here: FS or DB?
15:25:00 <gtema> for the reference: https://docs.openstack.org/keystone/latest/admin/configuration.html#domain-specific-configuration
15:26:49 <gtema> Statement from docs: "Unlike the file-based method of specifying domain-specific configurations, options specified via the Identity API will become active without needing to restart the keystone server."
15:27:20 <d34dh0r53> Right, may have to wait for the cache to expire but no restart needed
15:27:51 <gtema> right
15:28:15 <gtema> from my pov using FS for config is not really an option for out-of-tree drivers. That leaves only DB
15:28:34 <gtema> and here I need to change 2 things in Keystone:
15:29:09 <gtema> a) allow out-of-tree drivers to register custom options (so that at least Keystone doesn't crash once I place them into DB)
15:29:38 <gtema> b) extend config to allow adding new driver specific options into the comain_config api
15:30:06 <gtema> https://opendev.org/openstack/keystone/src/branch/master/keystone/resource/core.py#L1048
15:30:21 <gtema> the link points to the place where current options are hardcoded
15:30:41 <gtema> fixing a) is something like 5 lines of code
15:30:56 <gtema> fixing b) seems also relatively strait forward
15:31:07 <gtema> BUT I need to know whether you are fine with that
15:31:48 <gtema> basically docs suggest people should go for out-of-tree drivers, but current code base makes it terrible hard to configure such drivers in such case
15:33:17 <d34dh0r53> I'm fine with it, I think keystone is moving in this direction and making the configuration easier for out of tree drivers is a win-win
15:33:39 <gtema> perfect. Then I' polish my changes in next days
15:33:58 <d34dh0r53> Excellent!
15:34:14 <d34dh0r53> Thank you gtema (Artem Goncharov) !
15:34:18 <gtema> wlcm.
15:34:54 <gtema> I am going to write better docs on how to establish federation for a real life once everything stabilizes
15:35:08 <d34dh0r53> sweet
15:35:16 <gtema> and wrt the point on the tracker: I am pulling off my support for the mentioned spec
15:35:27 <gtema> and instead focus on this alternative way
15:35:59 <d34dh0r53> okay
15:36:06 <gtema> that's it from me on the topic
15:36:19 <d34dh0r53> thanks!
15:36:22 <d34dh0r53> next up
15:36:36 <d34dh0r53> #topic specification OpenAPI support (gtema)
15:36:36 <d34dh0r53> #link https://review.opendev.org/c/openstack/keystone-specs/+/910584
15:36:36 <d34dh0r53> gtema: waiting for reviews
15:37:00 <gtema> waitign for the spec to land. The one for Nova was merged recently
15:37:37 <d34dh0r53> cool, dmendiza , Grzegorz Grasza ^ can y'all review?
15:38:27 <d34dh0r53> #topic open discussion
15:38:37 <d34dh0r53> 'passlib update
15:38:51 <d34dh0r53> no update from me, I'm going to pin in the upper-requirements for now
15:39:12 <d34dh0r53> domain manager (mhen)... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/LkRBdKyQlgcNtIMSmDMIFiWc>)
15:39:18 <d34dh0r53> This needs reviews
15:40:04 <gtema> i restored my +1, last changes are polishing phrasing
15:40:51 <gtema> would be really great to land this one soon, since it is also a one dependency of having federation to external IdP
15:42:18 <d34dh0r53> indeed
15:43:00 <d34dh0r53> domain list scoping fix (mhen)... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/dgBmgIPIkmxSDHRtBPdfUGQf>)
15:43:23 <d34dh0r53> I think this was on hold as well, can I remove the WIP?
15:44:44 <d34dh0r53> I don't think mhen is around today, so we'll move on for the sake of time
15:44:47 <d34dh0r53> Enforcing scope in keystone breaks heat (and probably magnum) (tkajinam)... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/xPvMPjeJnSzhIGXjRjozjnPJ>)
15:45:39 <d34dh0r53> I think this is mostly done, just a couple more reviews and perhaps backporting of 916707
15:47:01 <d34dh0r53> cool, moving on
15:47:17 <d34dh0r53> unless anyone has something not on the agenda for open discussion
15:47:24 <gtema> not from me
15:47:31 <d34dh0r53> #topic bug review
15:47:41 <d34dh0r53> #link https://bugs.launchpad.net/keystone/?orderby=-id&start=0
15:48:11 <d34dh0r53> no new bugs for keystone
15:48:14 <d34dh0r53> #link https://bugs.launchpad.net/python-keystoneclient/?orderby=-id&start=0
15:48:46 <d34dh0r53> nothing new for python-keystoneclient
15:48:49 <d34dh0r53> #link https://bugs.launchpad.net/keystoneauth/+bugs?orderby=-id&start=0
15:49:13 <d34dh0r53> no new bugs for keystoneauth
15:49:16 <d34dh0r53> #link https://bugs.launchpad.net/keystonemiddleware/+bugs?orderby=-id&start=0
15:49:35 <d34dh0r53> keystonemiddleware is good
15:49:36 <d34dh0r53> #link https://bugs.launchpad.net/pycadf/+bugs?orderby=-id&start=0
15:49:54 <d34dh0r53> pycadf doesn't have any new issues
15:50:08 <d34dh0r53> #link https://bugs.launchpad.net/ldappool/+bugs?orderby=-id&start=0
15:50:15 <d34dh0r53> nor does ldappool
15:50:21 <d34dh0r53> #topic conclusion
15:50:29 <d34dh0r53> Nothing from me, thanks all!
15:50:49 <gtema> thanks
15:50:55 <d34dh0r53> #endmeeting