15:02:10 <d34dh0r53> #startmeeting keystone
15:02:10 <opendevmeet> Meeting started Wed Feb 19 15:02:10 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:10 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:02:10 <opendevmeet> The meeting name has been set to 'keystone'
15:02:14 <d34dh0r53> Reminder: This meeting takes place under the OpenInfra Foundation Code of Conduct
15:02:19 <d34dh0r53> #link https://openinfra.dev/legal/code-of-conduct
15:02:28 <d34dh0r53> #topic roll call
15:02:38 <gtema> o/
15:02:39 <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:02:46 <d34dh0r53> dmendiza: o/
15:02:49 <cardoe> o/
15:02:53 <mhen> o/
15:03:04 <xek> o/
15:03:17 <cardoe> before we start, just wanna say thanks to d34dh0r53 and all his efforts on keystone and being the PTL for so long :)
15:03:28 <gtema> +10
15:03:46 <d34dh0r53> Thank you <3
15:04:21 <d34dh0r53> It's been fun and I was struggling with the decision but the time is right
15:04:45 <d34dh0r53> #topic review past meeting work items
15:05:13 <d34dh0r53> #link https://meetings.opendev.org/meetings/keystone/2025/keystone.2025-02-12-15.06.html
15:05:22 <d34dh0r53> no action items from last week
15:05:36 <d34dh0r53> #topic liaison updates
15:05:43 <d34dh0r53> nothing from VMT or releases
15:06:54 <d34dh0r53> #topic specification OAuth 2.0 (hiromu)
15:06:58 <d34dh0r53> #link https://review.opendev.org/q/topic:bp%252Foauth2-client-credentials-ext
15:07:00 <d34dh0r53> #link https://review.opendev.org/q/topic:bp%252Fenhance-oauth2-interoperability
15:07:02 <d34dh0r53> External OAuth 2.0 Specification
15:07:05 <d34dh0r53> #link https://review.opendev.org/c/openstack/keystone-specs/+/861554 (merged)
15:07:08 <d34dh0r53> OAuth 2.0 Implementation
15:07:12 <d34dh0r53> #link https://review.opendev.org/q/topic:bp%252Fsupport-oauth2-mtls (merged)
15:07:13 <d34dh0r53> OAuth 2.0 Documentation
15:07:15 <d34dh0r53> #link https://review.opendev.org/c/openstack/keystone/+/838108 (merged)
15:07:17 <d34dh0r53> #link https://review.opendev.org/c/openstack/keystoneauth/+/838104 (merged)
15:07:32 <d34dh0r53> no updates from me this week
15:07:57 <d34dh0r53> I should have time to rebase the last couple of patches and I'll bug for reviews on Friday :)
15:08:04 <d34dh0r53> #topic specification Secure RBAC (dmendiza[m])
15:08:06 <d34dh0r53> #link https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#z-release-timeline_
15:08:08 <d34dh0r53> 2024.1 Release Timeline
15:08:11 <d34dh0r53> Update oslo.policy in keystone to enforce_new_defaults=True
15:08:13 <d34dh0r53> Update oslo.policy in keystone to enforce_scope=True
15:09:34 <d34dh0r53> guess dmendiza isn't around yet
15:10:01 <d34dh0r53> #topic specification OpenAPI support (gtema)
15:10:04 <d34dh0r53> #link https://review.opendev.org/q/topic:%22openapi%22+project:openstack/keystone
15:10:35 <gtema> I just merged the openstackdocstheme change (and created DNM change in keystone to verify it is running)
15:10:59 <gtema> after that I'll proceed integrating openapi rendered into our api-ref
15:11:18 <gtema> other than that there are no other things from me
15:12:20 <d34dh0r53> thank you! that's awesome
15:12:27 <d34dh0r53> #topic specification domain manager (mhen)
15:12:29 <d34dh0r53> still unmerged are:
15:12:32 <d34dh0r53> documentation: https://review.opendev.org/c/openstack/keystone/+/928135
15:12:34 <d34dh0r53> tempest tests: https://review.opendev.org/c/openstack/keystone-tempest-plugin/+/924222
15:13:30 <cardoe> How can I best provide some logs or some debugging around behavior I'm not expecting with the domain manager? I expected to be able to create projects if I have manager on the domain.
15:13:58 <gtema> indeed, you should
15:14:30 <gtema> in last weeks I am working on porting oslo.policy to the OpenPolicyAgent and found also few suspicious policy rules
15:15:02 <gtema> the point is that string interpretation is not always working as a human expects (order of AND, OR and brackets)
15:15:30 <gtema> cardoe - the best thing is actually to create policy test simulating different payloads
15:15:42 <gtema> neutron is using this heavily
15:16:06 <cardoe> okay I'll try that. thanks good idea.
15:18:02 <d34dh0r53> thanks!
15:18:30 <mhen> gtema: the "suspicious policy rules" you speak of - are they domain manager related specifically?
15:18:48 <d34dh0r53> core reviewers, if you can please review these last two remaining patches for domain manager spec.
15:19:28 <gtema> yeah, but not always. There are few incredibly long rules and I guess they are just missing brakets or so. But afaik there were few non-domain-manager-related things
15:20:41 <gtema> I noticed certain strange things once I pulled oslo.policy internals from the string implementation and rules looked like related under the wrong subrule
15:21:03 <gtema> I might be wrong though, it was some weeks ago
15:27:32 <d34dh0r53> next up
15:27:54 <d34dh0r53> 'v
15:27:55 <d34dh0r53> #topic specification Include bad password details in audit messages (stanislav-z)
15:27:59 <d34dh0r53> #link https://review.opendev.org/q/topic:%22pci-dss-invalid-password-reporting%22
15:28:03 <d34dh0r53> #link https://review.opendev.org/c/openstack/keystone-specs/+/915482 (merged)
15:28:06 <d34dh0r53> #link https://review.opendev.org/c/openstack/keystone/+/932423 (to be reviewed)
15:28:36 <d34dh0r53> #link https://review.opendev.org/c/openstack/keystone-specs/+/942084 (to be reviewed)
15:28:42 <d34dh0r53> 18-Feb update: the implementation has been updated to reflect the merged spec state
15:29:21 <stanislav-z> I've updated the implementation, and would appreciate reviews. It includes also tests and a release note :)
15:29:48 <d34dh0r53> ack, I'll take a look this week
15:29:56 <stanislav-z> thanks!
15:30:17 <d34dh0r53> Thank you!
15:30:30 <d34dh0r53> #topic open discussion
15:31:19 <gtema> first tests of comparing rust reimpl of keystone vs python show 20+ lower response latency and 100 times better throughput from the single process
15:32:06 <gtema> I am currently in the forest of parsing the token - it's lot of fun with certain "wow" moments
15:32:23 <d34dh0r53> that's amazing
15:32:47 <gtema> i.e. that if deployment changes order of auth plugins in config previous token become partially invalid
15:32:50 <d34dh0r53> I'll bet there are going to be several more "wow" moments ;)
15:33:00 <gtema> indeed
15:33:51 <gtema> nothing else from me and I need to run in few minutes
15:36:44 <d34dh0r53> ack, thanks!
15:36:50 <d34dh0r53> #topic bug review
15:36:53 <d34dh0r53> #link https://bugs.launchpad.net/keystone/?orderby=-id&start=0
15:36:57 <d34dh0r53> nothing new for keystone
15:37:00 <d34dh0r53> #link https://bugs.launchpad.net/python-keystoneclient/?orderby=-id&start=0
15:37:01 <cardoe> so if I can throw something into open discussion
15:37:19 <d34dh0r53> yes, please go ahead cardoe
15:37:27 <cardoe> I brought up vexxhost's keystoneauth-websso upstreaming previously. I still want to work on doing that.
15:38:07 <cardoe> I've also go a Go developer that's going to be working with me. Just wanted to share that I've asked him to work on gophercloud.
15:38:33 <cardoe> Since that's used for a number of OpenStack integration points, especially with kubernetes tools.
15:38:55 <cardoe> I'm asking them to follow how the python keystone implementation does things and respect the auth_type in clouds.yaml
15:39:09 <gtema> cardoe - I always wanted to plugin somebody with golang to start relying on openapi
15:39:11 <cardoe> I just was curious if there was a keystone spec around this behavior.
15:39:29 <cardoe> gtema: yeah that'd be the best.
15:39:43 <gtema> cardoe - this is all so damned unspecified and fragile
15:40:23 <gtema> depending on how CSP deploys the stuff it works one way or different and osc is currently also cannot  be used as a reference
15:40:51 <cardoe> I just want their auth to behave like the python does. Because it behaves differently because they try to "guess" what auth you use based on env vars and clouds.yaml is really secondary and only certain fields are read if other fields are seen.
15:41:11 <cardoe> okay well I guess no real good answer.
15:41:59 <cardoe> I know that OSC today treats clouds.yaml as the first party source and internally creates one basically. While the Go side reads stuff from env vars and other places and then plucks stuff from clouds.yaml if it's missing data.
15:42:28 <cardoe> Anyway, that's the only question I had was if there was some documented or reference I could point gophercloud folks at.
15:42:45 <gtema> cardoe - maybe we can have a separate meeting where I explain you certain findings. But for now sorry, need to run. cy
15:43:10 <d34dh0r53> Sound like a possible PTG discussion
15:43:22 <cardoe> gtema: absolutely. have a good day.
15:43:23 <d34dh0r53> That would be very interesting
15:43:25 <cardoe> d34dh0r53: good idea.
15:43:51 <d34dh0r53> okay, back to bug triage
15:44:00 <d34dh0r53> #link https://bugs.launchpad.net/keystoneauth/+bugs?orderby=-id&start=0
15:44:06 <d34dh0r53> nothing new in keystoneauth
15:44:27 <d34dh0r53> #link https://bugs.launchpad.net/keystonemiddleware/+bugs?orderby=-id&start=0
15:44:34 <d34dh0r53> keystonemiddleware is also good
15:44:40 <d34dh0r53> #link https://bugs.launchpad.net/pycadf/+bugs?orderby=-id&start=0
15:44:48 <d34dh0r53> no new bugs in pycadf
15:44:52 <d34dh0r53> #link https://bugs.launchpad.net/ldappool/+bugs?orderby=-id&start=0
15:44:55 <d34dh0r53> nor in ldappool
15:45:00 <d34dh0r53> #topic conclusion
15:45:27 <d34dh0r53> Like we stated at the beginning, this is my last cycle as PTL :(
15:45:51 <d34dh0r53> I'll do the formal handoff to the new PTL at the PTG and run things until then
15:46:23 <d34dh0r53> It's been an absolute pleasure and thank you all for everything!
15:46:52 <d34dh0r53> #endmeeting