15:05:08 <d34dh0r53> #startmeeting keystone
15:05:08 <opendevmeet> Meeting started Wed Oct  9 15:05:08 2024 UTC and is due to finish in 60 minutes.  The chair is d34dh0r53. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:05:08 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:05:08 <opendevmeet> The meeting name has been set to 'keystone'
15:05:23 <d34dh0r53> Reminder: This meeting takes place under the OpenInfra Foundation Code of Conduct
15:05:23 <d34dh0r53> #link https://openinfra.dev/legal/code-of-conduct
15:05:38 <d34dh0r53> #topic roll call
15:05:44 <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:05:50 <gtema> o/
15:06:04 <cardoe> o/
15:06:07 <jph> o/
15:06:12 <d34dh0r53> o/
15:07:50 <d34dh0r53> #topic review past meeting work items
15:08:01 <d34dh0r53> #link https://meetings.opendev.org/meetings/keystone/2024/keystone.2024-10-02-15.00.html
15:08:09 <xek> o/
15:08:12 <d34dh0r53> only one
15:08:13 <d34dh0r53> reviewathon discuss and hopefully perform the removal of passlib https://review.opendev.org/q/topic:%22passlib%22
15:08:41 <d34dh0r53> we merged just about everything, gtema (Artem Goncharov) do you think we're good to pull the bandaid off or should we wait?
15:09:00 <gtema> I do not have strong preference
15:09:17 <gtema> maybe lets rip it off now to detect problems earlier
15:12:35 <d34dh0r53> sounds good, I'll push the button after this meeting
15:12:46 <gtema> perfect, thanks
15:12:53 <d34dh0r53> #topic liaison updates
15:13:03 <d34dh0r53> nothing from VMT or releases
15:13:33 <d34dh0r53> #topic specification OAuth 2.0 (hiromu)
15:13:55 <d34dh0r53> #link https://review.opendev.org/q/topic:bp%252Foauth2-client-credentials-ext
15:13:56 <d34dh0r53> #link https://review.opendev.org/q/topic:bp%252Fenhance-oauth2-interoperability
15:13:58 <d34dh0r53> External OAuth 2.0 Specification
15:13:59 <d34dh0r53> #link https://review.opendev.org/c/openstack/keystone-specs/+/861554 (merged)
15:14:00 <d34dh0r53> OAuth 2.0 Implementation
15:14:02 <d34dh0r53> #link https://review.opendev.org/q/topic:bp%252Fsupport-oauth2-mtls
15:14:06 <d34dh0r53> OAuth 2.0 Documentation
15:14:10 <d34dh0r53> #link https://review.opendev.org/c/openstack/keystone/+/838108 (merged)
15:14:13 <d34dh0r53> #link https://review.opendev.org/c/openstack/keystoneauth/+/838104 (merged)
15:15:00 <d34dh0r53> no updates this week
15:15:09 <d34dh0r53> #topic specification Secure RBAC (dmendiza[m])
15:15:20 <d34dh0r53> #link https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#z-release-timeline_
15:15:23 <d34dh0r53> 2024.1 Release Timeline
15:15:26 <d34dh0r53> Update oslo.policy in keystone to enforce_new_defaults=True
15:15:30 <d34dh0r53> Update oslo.policy in keystone to enforce_scope=True
15:15:47 <d34dh0r53> dmendiza: is on PTO for the rest of the week
15:15:49 <d34dh0r53> next up
15:15:53 <d34dh0r53> #topic specification OpenAPI support (gtema)
15:15:57 <d34dh0r53> #link https://review.opendev.org/q/topic:%22openapi%22+project:openstack/keystone
15:16:01 <d34dh0r53> https://review.opendev.org/c/openstack/keystone/+/925020 could now also land to ease api-ref work
15:16:08 <d34dh0r53> gtema: api-ref work started
15:16:39 <gtema> under api-ref work I mean start rendering generated openapi as api-ref
15:16:53 <d34dh0r53> ahh, cool
15:17:11 <gtema> there is series of dependency-hell issues that I currently stuck on (openstackdocstheme need first upgrade of bootstrap from 5years old version)
15:17:27 <gtema> bootstrap upgrade breaks current os-api-ref
15:17:58 <gtema> and my sphinx plugin also needs openapi first, so api-ref job would first need to generate openapi doc
15:18:19 <gtema> anyway, with the fact that first openapi changes landed I now have a better overview what is there and what is missing
15:18:59 <gtema> maybe my friday I will have some changes with depends-on (like 5-6 dependent changes ;-) to demo overall flow
15:19:07 <gtema> s/my/by/
15:19:25 <d34dh0r53> okay, cool, ping me for reviews
15:20:03 <gtema> sure, is somebody here also owning core reviewers in openstackdocstheme/os-api-ref projects?
15:20:37 <d34dh0r53> I don't know
15:20:44 <gtema> ok
15:21:31 <gtema> that's it for now on openapi
15:22:49 <d34dh0r53> thanks gtema (Artem Goncharov)
15:22:51 <d34dh0r53> next up
15:22:55 <d34dh0r53> #topic specification domain manager (mhen)
15:22:57 <d34dh0r53> #link https://review.opendev.org/q/topic:%22domain-manager%22
15:23:01 <d34dh0r53> tempest core lib patch has been merged, only keystone-tempest-plugin left
15:23:04 <d34dh0r53> created a patchset for documentation: https://review.opendev.org/c/openstack/keystone/+/928135
15:24:59 <d34dh0r53> mhen_: are you around?
15:26:22 <d34dh0r53> ok, cores, please review the tempest plugin and docs patch for this
15:26:24 <d34dh0r53> moving on
15:26:35 <d34dh0r53> #topic specification Type annotations (stephenfin)
15:26:39 <d34dh0r53> #link https://review.opendev.org/q/project:openstack/keystoneauth+topic:typing
15:26:46 <d34dh0r53> This is just pending reviews now. I will push the remaining patches as soon as a sufficient quantity of the current ones land.
15:27:10 <gtema> I reviewed some portion of those today
15:27:25 <gtema> this is not trivial, so take your time
15:27:43 <d34dh0r53> indeed, I need to spend some time reviewing them
15:28:05 <stephenfin> Nothing to add. Per that note, just need reviews. The sooner we get them merged the better, so we can cut a release and iron out any kinks we see once it's in use
15:28:15 <gtema> on the topic: we were discussing ruff-ing the keystone
15:28:24 <d34dh0r53> ack, thanks stephenfin
15:28:28 <gtema> today I pushed https://review.opendev.org/c/openstack/keystone/+/931959 - and as you see it's mega huge
15:28:29 <d34dh0r53> I'm good with ruff-ing the keystone
15:28:58 <gtema> sadly here reformatted stuff started immediately violating hackings
15:29:02 <stephenfin> gtema: Don't forget to add a .git-blame-ignore-revs file once you're done
15:29:11 <gtema> so I needed to give a lovely human touch to lots of files
15:29:19 <gtema> yes, sure
15:30:04 <gtema> sad that bandit coverage under ruff is not too configurable
15:30:08 <stephenfin> gtema: I disabled much of the E class flake8 errors since they effectively duplicated what ruff was doing. ruff/black will do their best to respect line width
15:30:13 <gtema> otherwise I would have switched to that as well
15:30:55 <gtema> stephenfin - in the unreleased hacking or where?
15:31:33 <stephenfin> https://github.com/openstack/openstacksdk/blob/master/tox.ini#L143-L151
15:31:54 <stephenfin> The 'select' option is the important one
15:31:58 <gtema> ah this way, ok
15:32:24 <gtema> well, I anyway already touched plenty of files and addressed the E501, so it's bit too late ;-)
15:32:37 <stephenfin> you know for next time :)
15:32:50 <gtema> sure
15:32:53 * stephenfin goes back to lurking
15:34:03 <d34dh0r53> thanks stephenfin
15:34:12 <d34dh0r53> #topic open discussion
15:34:22 <noonedeadpunk> I have https://review.opendev.org/c/openstack/keystone/+/930589 to talk to
15:34:29 <d34dh0r53> I don't have anything, we already talked about saying bye-bye to passlib
15:35:12 <noonedeadpunk> In terms that - it's an annoying issue to have, but I can justify time to work on units tests for it, given that keystone-manage is basically not covered in tests currently
15:35:19 * d34dh0r53 looking at noonedeadpunk 's patch
15:35:24 <noonedeadpunk> so scope looks quite big
15:35:34 <noonedeadpunk> (at least for me)
15:36:08 <noonedeadpunk> the issue was introduced with sqlalchemy 2 patches iirc
15:38:53 <d34dh0r53> hmm, there are currently no unit tests with keystone-manage, but maybe a zuul job that checks this would suffice
15:39:19 <noonedeadpunk> arte there upgrade jobs existing?
15:39:35 <d34dh0r53> I thought so, but I'm not seeing any
15:39:35 <noonedeadpunk> as I don't see anything like that either
15:39:54 <noonedeadpunk> I _think_ last time keystone had an upgrade job - it was an OSA job
15:40:07 <d34dh0r53> That could be what I'm thinking about
15:40:19 <noonedeadpunk> ofc I can work on adding it again :)
15:40:35 <d34dh0r53> https://github.com/openstack/keystone/blob/f7ffacb7ad2d09da01b00cf50192a5c2b2d899a1/.zuul.yaml#L68
15:40:35 <cardoe> Question around inherited permissions. I know that you can have sub-projects and give permissions on the parent project which can be inherited. But can I have a domain and have roles set on the domain and inherited to projects? Since a domain is really just a project now.
15:40:42 <noonedeadpunk> but I guess you might be in favor of grenade
15:41:07 <noonedeadpunk> I can revive that testing fwiw
15:41:43 <d34dh0r53> noonedeadpunk: yeah, let's revive that testing, it should suffice for your keystone-manage patch.
15:42:08 <noonedeadpunk> but the problem with the patch, is that command now reports "ok" whenever you ask it if migrations needed
15:42:32 <noonedeadpunk> and upgrade job is jsut checking for the return code
15:42:34 <d34dh0r53> because it's comparing the same thing
15:42:39 <noonedeadpunk> so it's not catching the issue
15:42:42 <noonedeadpunk> yeah
15:42:45 <d34dh0r53> yeah
15:43:15 <noonedeadpunk> so this specific issue won't be catched by such job
15:43:32 <d34dh0r53> ok, I'll review that patch and add the note that you're going to work on an upgrade job to ensure it's correct going forward
15:43:46 <noonedeadpunk> ++
15:43:55 <noonedeadpunk> upgrade job is on me
15:44:16 <d34dh0r53> to your question cardoe , I'm not 100% sure
15:44:50 <d34dh0r53> that's a question for dmendiza or mhen_ but neither of them are around
15:45:37 <cardoe> okay I'll chase them down. It's not clear from the docs to me and the behavior is making me scratch my head using 2024.1 based on the domains.
15:45:48 <gtema> the best answer - try it out. My guess - it will not work
15:46:26 <gtema> point of concern is that domain is not returned in list_projects and neither the opposite
15:47:00 <gtema> so for grant inheriting to work  there must be explicit logic which I have never seen
15:47:12 <cardoe> My idea might be stupid anyway. Hooking ironic to be authenticated via keystone for users. All the projects are just different teams having hardware. So wanted to give the admins permission to all the projects with hardware.
15:47:28 <noonedeadpunk> I don't think it will work either....
15:47:29 <cardoe> Without having to explicitly give them permission to each project.
15:47:58 <noonedeadpunk> you can add them to group?
15:48:39 <cardoe> I guess I could grant a group permission to each project. yeah that would be fine.
15:48:40 <noonedeadpunk> but also - giving admin permissions to the project will give a global admin to all projects
15:48:50 <noonedeadpunk> and all domains
15:49:18 <cardoe> well I said "admin" but wasn't referring to keystone admin role but humans. giving them "member" on the projects
15:49:18 <noonedeadpunk> ah, I guess I misread
15:49:26 <noonedeadpunk> ++
15:49:27 <gtema> noonedeadpunk - for that we have now domain manager - to not need granting admin for users
15:49:43 <noonedeadpunk> oh, yes, I already use them in one place
15:49:51 <noonedeadpunk> though Horizon still needs to be patched...
15:49:55 <cardoe> It's so they can do stuff like baremetal service to upgrade firmware and such on machines.
15:50:07 <noonedeadpunk> as it doesn;t like manager with domain only assignment
15:50:32 <gtema> https://docs.openstack.org/api-ref/identity/v3/#assign-role-to-user-on-projects-owned-by-domain claims you grant to the use certain role on all projects owned by domain
15:50:45 <gtema> user
15:51:08 <noonedeadpunk> `inherited_to_projects` - oh, nice
15:51:19 <cardoe> So it works when I make sub-projects and parent it to a project
15:51:27 <cardoe> then have that project be a domain
15:51:41 <cardoe> But maybe that call will work straight away. Thank you gtema.
15:52:10 <gtema> it looks you do not need any other stuff, you grant directly on the domain
15:52:32 <gtema> but - test whether it does what you need
15:52:42 <cardoe> yeah will do thank you.
15:52:55 <d34dh0r53> moving on for time, let us know how it works cardoe
15:52:58 <cardoe> I wanted to also bring up OpenID Connect. Would proposing keystoneauth-websso for inclusion be something that would be workable? There's at least 3 operators now that are using it. I know that there's work on changing the integration in the pipeline.
15:53:21 <d34dh0r53> yeah, I would be very interested in that car
15:53:25 <d34dh0r53> oops cardoe
15:53:41 <noonedeadpunk> well, I'd say it's a bit weird one...
15:53:59 <noonedeadpunk> As basically it neglects all benefits of OIDC
15:54:25 <noonedeadpunk> since you can't re-use token issued by oidc provider, nor you can use 2fa in oidc
15:54:26 <gtema> no it doesn't, but other issue is that without token caching it doesn't bring you anything
15:55:13 <cardoe> So today the upstream version caches the token on disk just like kubelogin does.
15:55:33 <noonedeadpunk> I think it does... As OIDC most usable is to have single interface and flow for authentication between different services
15:55:36 <cardoe> https://github.com/int128/kubelogin
15:55:46 <gtema> if you explicitly enable caching in the config and it has so may cornercases
15:56:01 <noonedeadpunk> and what you do with keystoneauth-websso is hardly interoperable with other services, unless you just disable half of keycloack
15:56:04 <noonedeadpunk> dunno
15:56:47 <gtema> this is a yet another case of half-knowledge on the complexity of federated logins :)
15:57:05 <noonedeadpunk> yeah, could be easily
15:57:08 <gtema> that is why I placed topic on PTG for a much deeper discussion
15:57:43 <noonedeadpunk> actually....
15:57:53 <noonedeadpunk> I think I'm mixing this up with some other repo
15:57:59 <cardoe> So I don't disagree it'd be nice to have deeper integration federation
15:58:06 <cardoe> https://github.com/vexxhost/keystone-keycloak-backend is the backend that Vexxhost uses.
15:58:24 <noonedeadpunk> oh, yes, I was all time talking about that ^
15:58:25 <noonedeadpunk> lol
15:58:44 <cardoe> I'm not talking about the backend
15:58:48 <cardoe> I'm talking about https://github.com/vexxhost/keystoneauth-websso
15:58:48 <noonedeadpunk> ++
15:58:53 <noonedeadpunk> ok, sure, sorry
15:58:58 <gtema> right, and for that in 2024.2 we now have possibility to configure it dynamically without needing to restart keystone (or let's say partially)
15:59:00 * noonedeadpunk need to take some rest
15:59:25 <cardoe> Which causes my browser window to open and go to my OIDC provider
15:59:37 <cardoe> and then it redirects me back to http://localhost:9999
15:59:48 <noonedeadpunk> that's actualy nice
15:59:51 <cardoe> and websso is listening on that port and it gets the id_token back
16:00:03 <gtema> yes cardoe, it works, works great, but it doesn't cover all crazy usecases of federation
16:00:04 <cardoe> It's called websso cause it's implemented how horizon works afaik.
16:00:17 <cardoe> gtema: agreed it's not perfect
16:00:37 <noonedeadpunk> but maybe it's possible to work on that collaboratively to make it better
16:01:04 <gtema> it works only for keycloak, that's one of the structural issues
16:01:06 <cardoe> Just wondering if I could submit it for inclusion and if I'd get feedback on what to improve on it OR if it's -1 immediately.
16:01:19 <cardoe> gtema: nope. I use it with Azure and GitHub today.
16:01:38 <gtema> cardoe - question for driver or the cliauth plugin?
16:01:48 <noonedeadpunk> ut also I can recall slightly different path in keystone code for okta vs keycloack
16:01:56 <cardoe> for the cliauth piece
16:02:02 <noonedeadpunk> so adding compatability is normal evolvment
16:02:12 <gtema> ah ok. I meant that the backend is keycloak only
16:02:20 <cardoe> pip install python-openstackclient keystoneauth-websso locally on my machine
16:02:39 <d34dh0r53> we're over time, I'll make sure that bugs are taken care of.  I'm going to end the meeting here, but please continue the conversation, this seems like a really good topic for the PTG.
16:02:47 <d34dh0r53> #endmeeting