| *** mhen_ is now known as mhen | 01:16 | |
| *** whoami-rajat_ is now known as whoami-rajat | 13:58 | |
| d34dh0r53 | #startmeeting keystone | 15:01 |
|---|---|---|
| opendevmeet | 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 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 15:01 |
| opendevmeet | The meeting name has been set to 'keystone' | 15:01 |
| d34dh0r53 | #topic roll call | 15:03 |
| 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], mharley, jph, gtema, cardoe | 15:03 |
| gtema | o/ | 15:03 |
| cardoe | \o | 15:05 |
| d34dh0r53 | o/ | 15:05 |
| d34dh0r53 | let's get started | 15:05 |
| d34dh0r53 | #topic review past meeting work items | 15:06 |
| d34dh0r53 | #link https://meetings.opendev.org/meetings/keystone/2024/keystone.2024-09-11-15.04.html | 15:06 |
| d34dh0r53 | no action items from last meeting | 15:06 |
| d34dh0r53 | #topic liaison updates | 15:06 |
| d34dh0r53 | nothing from VMT | 15:06 |
| d34dh0r53 | We're nearing dalmatian release date | 15:06 |
| d34dh0r53 | #topic specification | 15:07 |
| d34dh0r53 | #undo | 15:07 |
| opendevmeet | Removing item from minutes: #topic specification | 15:07 |
| d34dh0r53 | #topic specification OAuth 2.0 (hiromu) | 15:07 |
| d34dh0r53 | #link https://review.opendev.org/q/topic:bp%252Foauth2-client-credentials-ext | 15:07 |
| d34dh0r53 | #link https://review.opendev.org/q/topic:bp%252Fenhance-oauth2-interoperability | 15:07 |
| d34dh0r53 | External OAuth 2.0 Specification | 15:08 |
| d34dh0r53 | #link https://review.opendev.org/c/openstack/keystone-specs/+/861554 (merged) | 15:08 |
| d34dh0r53 | OAuth 2.0 Implementation | 15:08 |
| d34dh0r53 | #link https://review.opendev.org/q/topic:bp%252Fsupport-oauth2-mtls | 15:08 |
| d34dh0r53 | OAuth 2.0 Documentation | 15:08 |
| d34dh0r53 | #link https://review.opendev.org/c/openstack/keystone/+/838108 (merged) | 15:08 |
| d34dh0r53 | #link https://review.opendev.org/c/openstack/keystoneauth/+/838104 (merged) | 15:08 |
| d34dh0r53 | 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 |
| d34dh0r53 | next up | 15:09 |
| d34dh0r53 | #topic specification Secure RBAC (dmendiza[m]) | 15:09 |
| d34dh0r53 | #link https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#z-release-timeline_ | 15:09 |
| d34dh0r53 | 2024.1 Release Timeline | 15:09 |
| d34dh0r53 | Update oslo.policy in keystone to enforce_new_defaults=True | 15:09 |
| d34dh0r53 | Update oslo.policy in keystone to enforce_scope=True | 15:09 |
| d34dh0r53 | I don't think dmendiza is around today, so moving on | 15:11 |
| d34dh0r53 | #topic specification OpenAPI support (gtema) | 15:11 |
| d34dh0r53 | #link https://review.opendev.org/q/topic:%22openapi%22+project:openstack/keystone | 15:11 |
| d34dh0r53 | gtema: changes awaiting review | 15:12 |
| gtema | you haven't reloaded page where I added please please please | 15:12 |
| d34dh0r53 | lol | 15:13 |
| gtema | it is frustrating not to see any movement | 15:13 |
| d34dh0r53 | one sec | 15:13 |
| d34dh0r53 | I will try to get folks to review these, Grzegorz Grasza is on PTO until next week though | 15:13 |
| cardoe | wrt to OAuth 2.0, I'm using OIDC (or at least trying to) and was hoping to ask some questions there | 15:13 |
| d34dh0r53 | pertaining to the spec itself or support for your deployment cardoe ? | 15:14 |
| cardoe | Yes. :) | 15:15 |
| gtema | lol | 15:15 |
| gtema | question: A or B? Answer: yes | 15:15 |
| cardoe | Happy to wait until the agenda items are over. | 15:15 |
| cardoe | The answer is really both. | 15:15 |
| cardoe | 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 |
| cardoe | The mapping docs page is wrong from what the code expect and then the jsonschema patches alter things even further as well. | 15:16 |
| gtema | 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:16 |
| gtema | there are plenty of things done wrong afaik | 15:17 |
| cardoe | okay I'll go back to my observation corner | 15:17 |
| d34dh0r53 | 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:17 |
| gtema | 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:18 |
| d34dh0r53 | So back to openapi suport, I will review and try to get some movement on the patches | 15:19 |
| gtema | would appreciate Dave Wilde (d34dh0r53) | 15:19 |
| d34dh0r53 | next up | 15:20 |
| d34dh0r53 | #topic specification domain manager (mhen) | 15:20 |
| d34dh0r53 | #link https://review.opendev.org/q/topic:%22domain-manager%22 | 15:20 |
| d34dh0r53 | tempest core lib patch has been merged, only keystone-tempest-plugin left | 15:21 |
| d34dh0r53 | created a patchset for documentation: https://review.opendev.org/c/openstack/keystone/+/928135 | 15:21 |
| d34dh0r53 | awesome, thanks mhen_ | 15:21 |
| gtema | doc looks good, I will review offline in detail | 15:24 |
| d34dh0r53 | thanks gtema (Artem Goncharov) | 15:26 |
| d34dh0r53 | #topic specification Type annotations (stephenfin) | 15:26 |
| gtema | bunch of changes merged already | 15:26 |
| d34dh0r53 | #link https://review.opendev.org/q/project:openstack/keystoneauth+topic:typing | 15:26 |
| gtema | rest have one +2 | 15:27 |
| d34dh0r53 | 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 |
| d34dh0r53 | 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 |
| d34dh0r53 | 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 |
| d34dh0r53 | cool, I'll take a look at these as well | 15:27 |
| gtema | maybe on that one: do we want to apply ruff also to keystone (and yes, we just did that with black) | 15:28 |
| gtema | ? | 15:28 |
| cardoe | +1 on the ruff stuff. Cause I agree with you it removes friction and just moves things along. | 15:28 |
| cardoe | And let's you enable a ton more lints | 15:29 |
| d34dh0r53 | I'm good with moving keystone to ruff, how big is the effort going to be? | 15:30 |
| gtema | tiny - we have already auto-formatting. So here it would be just swap black with ruff in one change | 15:31 |
| gtema | I mean amount of code changes is going to be probably not so small, but all automatic | 15:31 |
| gtema | all the "issues" are already polished out | 15:31 |
| gtema | 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:33 |
| d34dh0r53 | agreed, let's prioritize the openapi stuff, ruff is a nice to have for keystone | 15:36 |
| gtema | deal | 15:36 |
| d34dh0r53 | #topic open discussion | 15:36 |
| d34dh0r53 | PTG planning | 15:37 |
| d34dh0r53 | I'm thinking about 3 hours Tues and Wed but am open to an additional 3 on Thursday if we need it | 15:37 |
| d34dh0r53 | The bot is ignoring me right now | 15:37 |
| gtema | :) | 15:37 |
| gtema | you do not feed it, so it is angry at you | 15:38 |
| gtema | from my pov we would spend at least one full 3h slot talking about federation stuff | 15:39 |
| d34dh0r53 | yeah | 15:41 |
| d34dh0r53 | I think I'll book all three days and cancel what we don't need | 15:42 |
| gtema | right | 15:42 |
| d34dh0r53 | cool, anything else for open discussion? | 15:42 |
| gtema | sure - I added on agenda | 15:42 |
| gtema | #link https://review.opendev.org/q/topic:%22passlib%22 | 15:42 |
| gtema | farewell passlib | 15:42 |
| gtema | I created series of patches getting rid of it completely | 15:43 |
| d34dh0r53 | Oh yeah, I noticed those | 15:43 |
| gtema | and noticed also that with sha512_crypt we would need to drop it once we start supporting py313 | 15:43 |
| d34dh0r53 | need to go look but the gates look promising, will this break backward compatability? | 15:44 |
| gtema | anyway - in every change I switch 1 algo and add backwards compatibility tests (to passlib) | 15:44 |
| gtema | 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:45 |
| gtema | 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 |
| gtema | unfortunately that makes those pretty slow (well, cryptography is on purpose slow) | 15:46 |
| gtema | oh, I missed your question | 15:46 |
| gtema | no - backward compatibility for now is guaranteed with those unittests that generate hash with passlib and try it with the new way | 15:47 |
| gtema | so users are able to login with old hashes | 15:47 |
| d34dh0r53 | cool | 15:48 |
| gtema | to be honest - this is dangerous, therefore in some change I added explicit releasenote warning about dragons | 15:48 |
| gtema | but we can not do much about it. I tried to catch and workaround all known issues | 15:49 |
| d34dh0r53 | 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 |
| d34dh0r53 | passlib is dead | 15:49 |
| gtema | right, and sadly it was doing lot of weird things which we may not see immediately | 15:50 |
| d34dh0r53 | yeah, that's a bummer | 15:51 |
| d34dh0r53 | almost out of time so moving on to bug review | 15:52 |
| d34dh0r53 | #topic bug review | 15:52 |
| d34dh0r53 | #link https://bugs.launchpad.net/keystone/?orderby=-id&start=0 | 15:52 |
| d34dh0r53 | #link https://bugs.launchpad.net/keystone/+bug/2081695 | 15:52 |
| d34dh0r53 | looks like this is being worked already | 15:53 |
| d34dh0r53 | #link https://bugs.launchpad.net/keystone/+bug/2081082 | 15:53 |
| d34dh0r53 | It's probably a good idea to add indexes to the revocation table | 15:54 |
| d34dh0r53 | Not sure why they weren't already there | 15:54 |
| d34dh0r53 | #link https://bugs.launchpad.net/keystone/+bug/2080542 | 15:56 |
| d34dh0r53 | that does it for keystone bugs | 15:57 |
| d34dh0r53 | #link https://bugs.launchpad.net/python-keystoneclient/?orderby=-id&start=0 | 15:58 |
| d34dh0r53 | no new bugs for python-keystoneclient | 15:59 |
| d34dh0r53 | #link https://bugs.launchpad.net/keystoneauth/+bugs?orderby=-id&start=0 | 15:59 |
| d34dh0r53 | keystoneauth is good | 15:59 |
| d34dh0r53 | #link https://bugs.launchpad.net/keystonemiddleware/+bugs?orderby=-id&start=0 | 15:59 |
| d34dh0r53 | nothing for keystonemiddleware either | 15:59 |
| d34dh0r53 | #link https://bugs.launchpad.net/pycadf/+bugs?orderby=-id&start=0 | 16:00 |
| d34dh0r53 | pycadf is good | 16:00 |
| d34dh0r53 | #link https://bugs.launchpad.net/ldappool/+bugs?ordterby=-id&start=0 | 16:00 |
| d34dh0r53 | and ldappool is good as well | 16:00 |
| d34dh0r53 | #topic conclusion | 16:00 |
| d34dh0r53 | Nothing else from me, I'll publish the PTG etherpad this week | 16:01 |
| d34dh0r53 | Thanks everyone! | 16:01 |
| d34dh0r53 | #endmeeting | 16:01 |
| opendevmeet | Meeting ended Wed Sep 25 16:01:13 2024 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 16:01 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/keystone/2024/keystone.2024-09-25-15.01.html | 16:01 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/keystone/2024/keystone.2024-09-25-15.01.txt | 16:01 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/keystone/2024/keystone.2024-09-25-15.01.log.html | 16:01 |
| gtema | great | 16:01 |
| gtema | thanks Dave Wilde (d34dh0r53) | 16:01 |
| cardoe | gtema: can you link me to the PTG bits? Specifically interested in the OIDC | 16:02 |
| gtema | once Dave Wilde (d34dh0r53) schedules it. I have no agenda yet, just in my head I have tons of observations and conclusions | 16:03 |
| cardoe | okay. You don't have those notes published anywhere? | 16:03 |
| gtema | cardoe - my item nr1 is to implement oidc in keystone natively without requiring mod_auth_oidc. That will save lots of problems | 16:04 |
| cardoe | well that would be good. | 16:04 |
| gtema | uhm, I have multiple notes, but they are mostly projects related. I will start sketching agenda once PTG etherpad is created | 16:04 |
| cardoe | okay. | 16:05 |
| gtema | one more thing is that oidc is useless and dangerous without provisioning/deprovisioning. This can be solved in few ways but the modern standard on that is https://en.wikipedia.org/wiki/System_for_Cross-domain_Identity_Management which I think we need to implement | 16:06 |
| gtema | cardoe - some of the last notes/analysis on federation can be seen under https://input.scs.community/scs-federation?view | 16:08 |
| cardoe | today I'm using mod_auth_oidc and mnaser's websso right now. | 16:09 |
| gtema | yeah, and vexxhost has a nice plugin for connecting KS to KeyCloak directly. That is one of the ways, but not very flexible (wrt IdP server) | 16:10 |
| gtema | in last release I added possibility to configure such plugin using API and mod_auth_oidc config can be also created dynamically (with regexp), but not all deployment tools allow you to skip need for restart | 16:11 |
| gtema | and in a public cloud you understand it is absolutely inacceptable | 16:12 |
| cardoe | Yeah that would be great. | 16:18 |
| jrosser | from an end user perspective it would be really nice to get websso into keystoneauth | 16:22 |
| jrosser | extra plugins to use the cli is a poor experience | 16:23 |
| gtema | Use of federation in Cli is by design poor experience | 16:24 |
| jrosser | is there an alternative? | 16:25 |
| cardoe | I mean there's many main tools that use OIDC with CLI. Like GitHub's CLI. | 16:25 |
| jrosser | what makes me most sad is that there are a bunch of plugins to make this work, so it's clearly something that people want/are using | 16:26 |
| cardoe | Kubernetes has it with oidc-login, which behaves the same as the websso | 16:26 |
| jrosser | there are even oidc flows specifically to support the use case, where you don't want a client id/secret | 16:29 |
| cardoe | Stock mod_oidc_auth + websso works fine for a static setup as you mentioned. | 16:29 |
| gtema | making cli use a nice experience requires totally different approach compared to what we have available now. And it is not a cli issue on it's own - it's a combination of the technologies | 16:30 |
| cardoe | I'm using OIDCResponseType "code" and have the client that mod_oidc_auth using marked as public | 16:31 |
| cardoe | I'm with jrosser. Folks want the support. Don't block good enough for perfect. | 16:36 |
| jrosser | we've just enabled websso for our hasicorp vault deployment and it also works *exactly* the same | 16:36 |
| jrosser | cli -> browser -> done | 16:37 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!