15:01:48 #startmeeting keystone 15:01:48 Meeting started Wed Sep 25 15:01:48 2024 UTC and is due to finish in 60 minutes. The chair is d34dh0r53. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:01:48 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:01:48 The meeting name has been set to 'keystone' 15:03:32 #topic roll call 15:03:39 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], mharley, jph, gtema, cardoe 15:03:40 o/ 15:05:29 \o 15:05:52 o/ 15:05:54 let's get started 15:06:06 #topic review past meeting work items 15:06:25 #link https://meetings.opendev.org/meetings/keystone/2024/keystone.2024-09-11-15.04.html 15:06:32 no action items from last meeting 15:06:43 #topic liaison updates 15:06:47 nothing from VMT 15:06:59 We're nearing dalmatian release date 15:07:21 #topic specification 15:07:25 #undo 15:07:25 Removing item from minutes: #topic specification 15:07:44 #topic specification OAuth 2.0 (hiromu) 15:07:52 #link https://review.opendev.org/q/topic:bp%252Foauth2-client-credentials-ext 15:07:57 #link https://review.opendev.org/q/topic:bp%252Fenhance-oauth2-interoperability 15:08:01 External OAuth 2.0 Specification 15:08:07 #link https://review.opendev.org/c/openstack/keystone-specs/+/861554 (merged) 15:08:13 OAuth 2.0 Implementation 15:08:19 #link https://review.opendev.org/q/topic:bp%252Fsupport-oauth2-mtls 15:08:26 OAuth 2.0 Documentation 15:08:31 #link https://review.opendev.org/c/openstack/keystone/+/838108 (merged) 15:08:39 #link https://review.opendev.org/c/openstack/keystoneauth/+/838104 (merged) 15:09:06 I worked on a couple of these before my PTO, I'll take a look again this week and try to get them passing the gates 15:09:11 next up 15:09:27 #topic specification Secure RBAC (dmendiza[m]) 15:09:34 #link https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#z-release-timeline_ 15:09:43 2024.1 Release Timeline 15:09:50 Update oslo.policy in keystone to enforce_new_defaults=True 15:09:54 Update oslo.policy in keystone to enforce_scope=True 15:11:34 I don't think dmendiza is around today, so moving on 15:11:49 #topic specification OpenAPI support (gtema) 15:11:55 #link https://review.opendev.org/q/topic:%22openapi%22+project:openstack/keystone 15:12:03 gtema: changes awaiting review 15:12:55 you haven't reloaded page where I added please please please 15:13:02 lol 15:13:03 it is frustrating not to see any movement 15:13:04 one sec 15:13:50 I will try to get folks to review these, Grzegorz Grasza is on PTO until next week though 15:13:51 wrt to OAuth 2.0, I'm using OIDC (or at least trying to) and was hoping to ask some questions there 15:14:42 pertaining to the spec itself or support for your deployment cardoe ? 15:15:03 Yes. :) 15:15:17 lol 15:15:37 question: A or B? Answer: yes 15:15:42 Happy to wait until the agenda items are over. 15:15:50 The answer is really both. 15:16:05 So the docs for OIDC aren't correct. I've started to write some patches... https://review.opendev.org/c/openstack/keystone/+/929315 is the first. 15:16:42 The mapping docs page is wrong from what the code expect and then the jsonschema patches alter things even further as well. 15:16:53 cardoe - I suggest really not to do this now. I have a huge agenda for the PTG to discuss on the federation support as whole 15:17:11 there are plenty of things done wrong afaik 15:17:22 okay I'll go back to my observation corner 15:17:56 Thank you for that docs patch though, I've known the docs use some incorrect terminology but haven't gotten around to fixing them 15:18:52 it's not about observation corner, it's about that current functionality on its own is pretty limited and having many issues that I wanted to discuss broadly. I am doing a huge research among different CSPs for their usecases and complains 15:19:20 So back to openapi suport, I will review and try to get some movement on the patches 15:19:49 would appreciate Dave Wilde (d34dh0r53) 15:20:44 next up 15:20:54 #topic specification domain manager (mhen) 15:20:59 #link https://review.opendev.org/q/topic:%22domain-manager%22 15:21:02 tempest core lib patch has been merged, only keystone-tempest-plugin left 15:21:09 created a patchset for documentation: https://review.opendev.org/c/openstack/keystone/+/928135 15:21:58 awesome, thanks mhen_ 15:24:27 doc looks good, I will review offline in detail 15:26:12 thanks gtema (Artem Goncharov) 15:26:29 #topic specification Type annotations (stephenfin) 15:26:54 bunch of changes merged already 15:26:57 #link https://review.opendev.org/q/project:openstack/keystoneauth+topic:typing 15:27:06 rest have one +2 15:27:07 This came about from adding type hints to openstacksdk. Since we're based on/heavily use keystoneauth, we need these annotations to be able to type things correctly. After much blood and tears, I now have the thing fully typed (except for tests and fixtures) but have refrained from pushing the full ~50 patch series to avoid overloading CI/humans :) 15:27:13 How do we want to review these? They are generally non-functional changes, though I have reworked some logic (to avoid use of try-except pattern that mypy doesn't like) and added lots of asserts to narrow types (which I will eventually convert to proper exceptions). Can I just let gtema review them and rely on CI? 15:27:16 You'll see I've used ruff and ruff-format. I realise this might be somewhat controversial, but it removes significant friction (from having to manually rewrap stuff) when adding annotations at minimal inconvenience to others 15:27:35 cool, I'll take a look at these as well 15:28:08 maybe on that one: do we want to apply ruff also to keystone (and yes, we just did that with black) 15:28:10 ? 15:28:16 +1 on the ruff stuff. Cause I agree with you it removes friction and just moves things along. 15:29:57 And let's you enable a ton more lints 15:30:49 I'm good with moving keystone to ruff, how big is the effort going to be? 15:31:30 tiny - we have already auto-formatting. So here it would be just swap black with ruff in one change 15:31:40 I mean amount of code changes is going to be probably not so small, but all automatic 15:31:53 all the "issues" are already polished out 15:33:00 I can prepare the change, but I do not want to do that before we land our complex depending openapi stuff first, otherwise we are again in a pain of rebase 15:36:29 agreed, let's prioritize the openapi stuff, ruff is a nice to have for keystone 15:36:43 deal 15:36:52 #topic open discussion 15:37:01 PTG planning 15:37:24 I'm thinking about 3 hours Tues and Wed but am open to an additional 3 on Thursday if we need it 15:37:37 The bot is ignoring me right now 15:37:45 :) 15:38:10 you do not feed it, so it is angry at you 15:39:40 from my pov we would spend at least one full 3h slot talking about federation stuff 15:41:54 yeah 15:42:11 I think I'll book all three days and cancel what we don't need 15:42:19 right 15:42:30 cool, anything else for open discussion? 15:42:43 sure - I added on agenda 15:42:54 #link https://review.opendev.org/q/topic:%22passlib%22 15:42:57 farewell passlib 15:43:10 I created series of patches getting rid of it completely 15:43:40 Oh yeah, I noticed those 15:43:41 and noticed also that with sha512_crypt we would need to drop it once we start supporting py313 15:44:26 need to go look but the gates look promising, will this break backward compatability? 15:44:36 anyway - in every change I switch 1 algo and add backwards compatibility tests (to passlib) 15:45:02 in the last change I drop passlib dep and those tests as well. I assume the last change is something we may want to wait a bit 15:46:08 those unittests run 10 iterations of different inputs, cause there are some funny things happening depending on the input and I try to catch those with that. 15:46:30 unfortunately that makes those pretty slow (well, cryptography is on purpose slow) 15:46:54 oh, I missed your question 15:47:26 no - backward compatibility for now is guaranteed with those unittests that generate hash with passlib and try it with the new way 15:47:36 so users are able to login with old hashes 15:48:38 cool 15:48:42 to be honest - this is dangerous, therefore in some change I added explicit releasenote warning about dragons 15:49:10 but we can not do much about it. I tried to catch and workaround all known issues 15:49:26 yeah, that is the fear, that we break all of the users with the update, I agree we need to rip the bandaid off 15:49:35 passlib is dead 15:50:12 right, and sadly it was doing lot of weird things which we may not see immediately 15:51:36 yeah, that's a bummer 15:52:09 almost out of time so moving on to bug review 15:52:18 #topic bug review 15:52:25 #link https://bugs.launchpad.net/keystone/?orderby=-id&start=0 15:52:56 #link https://bugs.launchpad.net/keystone/+bug/2081695 15:53:02 looks like this is being worked already 15:53:33 #link https://bugs.launchpad.net/keystone/+bug/2081082 15:54:21 It's probably a good idea to add indexes to the revocation table 15:54:46 Not sure why they weren't already there 15:56:38 #link https://bugs.launchpad.net/keystone/+bug/2080542 15:57:47 that does it for keystone bugs 15:58:42 #link https://bugs.launchpad.net/python-keystoneclient/?orderby=-id&start=0 15:59:09 no new bugs for python-keystoneclient 15:59:17 #link https://bugs.launchpad.net/keystoneauth/+bugs?orderby=-id&start=0 15:59:31 keystoneauth is good 15:59:38 #link https://bugs.launchpad.net/keystonemiddleware/+bugs?orderby=-id&start=0 15:59:53 nothing for keystonemiddleware either 16:00:02 #link https://bugs.launchpad.net/pycadf/+bugs?orderby=-id&start=0 16:00:15 pycadf is good 16:00:22 #link https://bugs.launchpad.net/ldappool/+bugs?ordterby=-id&start=0 16:00:40 and ldappool is good as well 16:00:43 #topic conclusion 16:01:06 Nothing else from me, I'll publish the PTG etherpad this week 16:01:10 Thanks everyone! 16:01:13 #endmeeting