| *** mhen_ is now known as mhen | 01:58 | |
| opendevreview | Takashi Kajinami proposed openstack/oslo.limit master: Declare Python 3.12 support https://review.opendev.org/c/openstack/oslo.limit/+/931928 | 13:41 |
|---|---|---|
| opendevreview | Takashi Kajinami proposed openstack/oslo.policy master: Declare Python 3.12 support https://review.opendev.org/c/openstack/oslo.policy/+/931932 | 13:43 |
| opendevreview | Artem Goncharov proposed openstack/keystone master: Ruff the code https://review.opendev.org/c/openstack/keystone/+/931959 | 14:36 |
| opendevreview | Artem Goncharov proposed openstack/keystone master: Ruff the code https://review.opendev.org/c/openstack/keystone/+/931959 | 14:37 |
| d34dh0r53 | #startmeeting keystone | 15:05 |
| 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 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 15:05 |
| opendevmeet | The meeting name has been set to 'keystone' | 15:05 |
| d34dh0r53 | Reminder: This meeting takes place under the OpenInfra Foundation Code of Conduct | 15:05 |
| d34dh0r53 | #link https://openinfra.dev/legal/code-of-conduct | 15:05 |
| d34dh0r53 | #topic roll call | 15:05 |
| 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 |
| gtema | o/ | 15:05 |
| cardoe | o/ | 15:06 |
| jph | o/ | 15:06 |
| d34dh0r53 | o/ | 15:06 |
| d34dh0r53 | #topic review past meeting work items | 15:07 |
| d34dh0r53 | #link https://meetings.opendev.org/meetings/keystone/2024/keystone.2024-10-02-15.00.html | 15:08 |
| xek | o/ | 15:08 |
| d34dh0r53 | only one | 15:08 |
| d34dh0r53 | reviewathon discuss and hopefully perform the removal of passlib https://review.opendev.org/q/topic:%22passlib%22 | 15:08 |
| 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:08 |
| gtema | I do not have strong preference | 15:09 |
| gtema | maybe lets rip it off now to detect problems earlier | 15:09 |
| d34dh0r53 | sounds good, I'll push the button after this meeting | 15:12 |
| gtema | perfect, thanks | 15:12 |
| d34dh0r53 | #topic liaison updates | 15:12 |
| d34dh0r53 | nothing from VMT or releases | 15:13 |
| d34dh0r53 | #topic specification OAuth 2.0 (hiromu) | 15:13 |
| d34dh0r53 | #link https://review.opendev.org/q/topic:bp%252Foauth2-client-credentials-ext | 15:13 |
| d34dh0r53 | #link https://review.opendev.org/q/topic:bp%252Fenhance-oauth2-interoperability | 15:13 |
| d34dh0r53 | External OAuth 2.0 Specification | 15:13 |
| d34dh0r53 | #link https://review.opendev.org/c/openstack/keystone-specs/+/861554 (merged) | 15:13 |
| d34dh0r53 | OAuth 2.0 Implementation | 15:14 |
| d34dh0r53 | #link https://review.opendev.org/q/topic:bp%252Fsupport-oauth2-mtls | 15:14 |
| d34dh0r53 | OAuth 2.0 Documentation | 15:14 |
| d34dh0r53 | #link https://review.opendev.org/c/openstack/keystone/+/838108 (merged) | 15:14 |
| d34dh0r53 | #link https://review.opendev.org/c/openstack/keystoneauth/+/838104 (merged) | 15:14 |
| d34dh0r53 | no updates this week | 15:15 |
| d34dh0r53 | #topic specification Secure RBAC (dmendiza[m]) | 15:15 |
| d34dh0r53 | #link https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#z-release-timeline_ | 15:15 |
| d34dh0r53 | 2024.1 Release Timeline | 15:15 |
| d34dh0r53 | Update oslo.policy in keystone to enforce_new_defaults=True | 15:15 |
| d34dh0r53 | Update oslo.policy in keystone to enforce_scope=True | 15:15 |
| d34dh0r53 | dmendiza: is on PTO for the rest of the week | 15:15 |
| d34dh0r53 | next up | 15:15 |
| d34dh0r53 | #topic specification OpenAPI support (gtema) | 15:15 |
| d34dh0r53 | #link https://review.opendev.org/q/topic:%22openapi%22+project:openstack/keystone | 15:15 |
| d34dh0r53 | https://review.opendev.org/c/openstack/keystone/+/925020 could now also land to ease api-ref work | 15:16 |
| d34dh0r53 | gtema: api-ref work started | 15:16 |
| gtema | under api-ref work I mean start rendering generated openapi as api-ref | 15:16 |
| d34dh0r53 | ahh, cool | 15:16 |
| 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 |
| gtema | bootstrap upgrade breaks current os-api-ref | 15:17 |
| gtema | and my sphinx plugin also needs openapi first, so api-ref job would first need to generate openapi doc | 15:17 |
| 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 |
| gtema | maybe my friday I will have some changes with depends-on (like 5-6 dependent changes ;-) to demo overall flow | 15:18 |
| gtema | s/my/by/ | 15:19 |
| d34dh0r53 | okay, cool, ping me for reviews | 15:19 |
| gtema | sure, is somebody here also owning core reviewers in openstackdocstheme/os-api-ref projects? | 15:20 |
| d34dh0r53 | I don't know | 15:20 |
| gtema | ok | 15:20 |
| gtema | that's it for now on openapi | 15:21 |
| d34dh0r53 | thanks gtema (Artem Goncharov) | 15:22 |
| d34dh0r53 | next up | 15:22 |
| d34dh0r53 | #topic specification domain manager (mhen) | 15:22 |
| d34dh0r53 | #link https://review.opendev.org/q/topic:%22domain-manager%22 | 15:22 |
| d34dh0r53 | tempest core lib patch has been merged, only keystone-tempest-plugin left | 15:23 |
| d34dh0r53 | created a patchset for documentation: https://review.opendev.org/c/openstack/keystone/+/928135 | 15:23 |
| d34dh0r53 | mhen_: are you around? | 15:24 |
| d34dh0r53 | ok, cores, please review the tempest plugin and docs patch for this | 15:26 |
| d34dh0r53 | moving on | 15:26 |
| d34dh0r53 | #topic specification Type annotations (stephenfin) | 15:26 |
| d34dh0r53 | #link https://review.opendev.org/q/project:openstack/keystoneauth+topic:typing | 15:26 |
| 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:26 |
| gtema | I reviewed some portion of those today | 15:27 |
| gtema | this is not trivial, so take your time | 15:27 |
| d34dh0r53 | indeed, I need to spend some time reviewing them | 15:27 |
| 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 |
| gtema | on the topic: we were discussing ruff-ing the keystone | 15:28 |
| d34dh0r53 | ack, thanks stephenfin | 15:28 |
| gtema | today I pushed https://review.opendev.org/c/openstack/keystone/+/931959 - and as you see it's mega huge | 15:28 |
| d34dh0r53 | I'm good with ruff-ing the keystone | 15:28 |
| gtema | sadly here reformatted stuff started immediately violating hackings | 15:28 |
| stephenfin | gtema: Don't forget to add a .git-blame-ignore-revs file once you're done | 15:29 |
| gtema | so I needed to give a lovely human touch to lots of files | 15:29 |
| gtema | yes, sure | 15:29 |
| gtema | sad that bandit coverage under ruff is not too configurable | 15:30 |
| 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 |
| gtema | otherwise I would have switched to that as well | 15:30 |
| gtema | stephenfin - in the unreleased hacking or where? | 15:30 |
| stephenfin | https://github.com/openstack/openstacksdk/blob/master/tox.ini#L143-L151 | 15:31 |
| stephenfin | The 'select' option is the important one | 15:31 |
| gtema | ah this way, ok | 15:31 |
| gtema | well, I anyway already touched plenty of files and addressed the E501, so it's bit too late ;-) | 15:32 |
| stephenfin | you know for next time :) | 15:32 |
| gtema | sure | 15:32 |
| * stephenfin goes back to lurking | 15:32 | |
| d34dh0r53 | thanks stephenfin | 15:34 |
| d34dh0r53 | #topic open discussion | 15:34 |
| noonedeadpunk | I have https://review.opendev.org/c/openstack/keystone/+/930589 to talk to | 15:34 |
| d34dh0r53 | I don't have anything, we already talked about saying bye-bye to passlib | 15:34 |
| 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 |
| * d34dh0r53 looking at noonedeadpunk 's patch | 15:35 | |
| noonedeadpunk | so scope looks quite big | 15:35 |
| noonedeadpunk | (at least for me) | 15:35 |
| noonedeadpunk | the issue was introduced with sqlalchemy 2 patches iirc | 15:36 |
| d34dh0r53 | hmm, there are currently no unit tests with keystone-manage, but maybe a zuul job that checks this would suffice | 15:38 |
| noonedeadpunk | arte there upgrade jobs existing? | 15:39 |
| d34dh0r53 | I thought so, but I'm not seeing any | 15:39 |
| noonedeadpunk | as I don't see anything like that either | 15:39 |
| noonedeadpunk | I _think_ last time keystone had an upgrade job - it was an OSA job | 15:39 |
| d34dh0r53 | That could be what I'm thinking about | 15:40 |
| noonedeadpunk | ofc I can work on adding it again :) | 15:40 |
| d34dh0r53 | https://github.com/openstack/keystone/blob/f7ffacb7ad2d09da01b00cf50192a5c2b2d899a1/.zuul.yaml#L68 | 15:40 |
| 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 |
| noonedeadpunk | but I guess you might be in favor of grenade | 15:40 |
| noonedeadpunk | I can revive that testing fwiw | 15:41 |
| d34dh0r53 | noonedeadpunk: yeah, let's revive that testing, it should suffice for your keystone-manage patch. | 15:41 |
| noonedeadpunk | but the problem with the patch, is that command now reports "ok" whenever you ask it if migrations needed | 15:42 |
| noonedeadpunk | and upgrade job is jsut checking for the return code | 15:42 |
| d34dh0r53 | because it's comparing the same thing | 15:42 |
| noonedeadpunk | so it's not catching the issue | 15:42 |
| noonedeadpunk | yeah | 15:42 |
| d34dh0r53 | yeah | 15:42 |
| noonedeadpunk | so this specific issue won't be catched by such job | 15:43 |
| 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 |
| noonedeadpunk | ++ | 15:43 |
| noonedeadpunk | upgrade job is on me | 15:43 |
| d34dh0r53 | to your question cardoe , I'm not 100% sure | 15:44 |
| d34dh0r53 | that's a question for dmendiza or mhen_ but neither of them are around | 15:44 |
| 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 |
| gtema | the best answer - try it out. My guess - it will not work | 15:45 |
| gtema | point of concern is that domain is not returned in list_projects and neither the opposite | 15:46 |
| gtema | so for grant inheriting to work there must be explicit logic which I have never seen | 15:47 |
| 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 |
| noonedeadpunk | I don't think it will work either.... | 15:47 |
| cardoe | Without having to explicitly give them permission to each project. | 15:47 |
| noonedeadpunk | you can add them to group? | 15:47 |
| cardoe | I guess I could grant a group permission to each project. yeah that would be fine. | 15:48 |
| noonedeadpunk | but also - giving admin permissions to the project will give a global admin to all projects | 15:48 |
| noonedeadpunk | and all domains | 15:48 |
| cardoe | well I said "admin" but wasn't referring to keystone admin role but humans. giving them "member" on the projects | 15:49 |
| noonedeadpunk | ah, I guess I misread | 15:49 |
| noonedeadpunk | ++ | 15:49 |
| gtema | noonedeadpunk - for that we have now domain manager - to not need granting admin for users | 15:49 |
| noonedeadpunk | oh, yes, I already use them in one place | 15:49 |
| noonedeadpunk | though Horizon still needs to be patched... | 15:49 |
| cardoe | It's so they can do stuff like baremetal service to upgrade firmware and such on machines. | 15:49 |
| noonedeadpunk | as it doesn;t like manager with domain only assignment | 15:50 |
| 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 |
| gtema | user | 15:50 |
| noonedeadpunk | `inherited_to_projects` - oh, nice | 15:51 |
| cardoe | So it works when I make sub-projects and parent it to a project | 15:51 |
| cardoe | then have that project be a domain | 15:51 |
| cardoe | But maybe that call will work straight away. Thank you gtema. | 15:51 |
| gtema | it looks you do not need any other stuff, you grant directly on the domain | 15:52 |
| gtema | but - test whether it does what you need | 15:52 |
| cardoe | yeah will do thank you. | 15:52 |
| d34dh0r53 | moving on for time, let us know how it works cardoe | 15:52 |
| 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:52 |
| d34dh0r53 | yeah, I would be very interested in that car | 15:53 |
| d34dh0r53 | oops cardoe | 15:53 |
| noonedeadpunk | well, I'd say it's a bit weird one... | 15:53 |
| noonedeadpunk | As basically it neglects all benefits of OIDC | 15:53 |
| noonedeadpunk | since you can't re-use token issued by oidc provider, nor you can use 2fa in oidc | 15:54 |
| gtema | no it doesn't, but other issue is that without token caching it doesn't bring you anything | 15:54 |
| cardoe | So today the upstream version caches the token on disk just like kubelogin does. | 15:55 |
| noonedeadpunk | I think it does... As OIDC most usable is to have single interface and flow for authentication between different services | 15:55 |
| cardoe | https://github.com/int128/kubelogin | 15:55 |
| gtema | if you explicitly enable caching in the config and it has so may cornercases | 15:55 |
| noonedeadpunk | and what you do with keystoneauth-websso is hardly interoperable with other services, unless you just disable half of keycloack | 15:56 |
| noonedeadpunk | dunno | 15:56 |
| gtema | this is a yet another case of half-knowledge on the complexity of federated logins :) | 15:56 |
| noonedeadpunk | yeah, could be easily | 15:57 |
| gtema | that is why I placed topic on PTG for a much deeper discussion | 15:57 |
| noonedeadpunk | actually.... | 15:57 |
| noonedeadpunk | I think I'm mixing this up with some other repo | 15:57 |
| cardoe | So I don't disagree it'd be nice to have deeper integration federation | 15:57 |
| cardoe | https://github.com/vexxhost/keystone-keycloak-backend is the backend that Vexxhost uses. | 15:58 |
| noonedeadpunk | oh, yes, I was all time talking about that ^ | 15:58 |
| noonedeadpunk | lol | 15:58 |
| cardoe | I'm not talking about the backend | 15:58 |
| cardoe | I'm talking about https://github.com/vexxhost/keystoneauth-websso | 15:58 |
| noonedeadpunk | ++ | 15:58 |
| noonedeadpunk | ok, sure, sorry | 15: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:58 |
| * noonedeadpunk need to take some rest | 15:59 | |
| cardoe | Which causes my browser window to open and go to my OIDC provider | 15:59 |
| cardoe | and then it redirects me back to http://localhost:9999 | 15:59 |
| noonedeadpunk | that's actualy nice | 15:59 |
| cardoe | and websso is listening on that port and it gets the id_token back | 15:59 |
| gtema | yes cardoe, it works, works great, but it doesn't cover all crazy usecases of federation | 16:00 |
| cardoe | It's called websso cause it's implemented how horizon works afaik. | 16:00 |
| cardoe | gtema: agreed it's not perfect | 16:00 |
| noonedeadpunk | but maybe it's possible to work on that collaboratively to make it better | 16:00 |
| gtema | it works only for keycloak, that's one of the structural issues | 16:01 |
| 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 |
| cardoe | gtema: nope. I use it with Azure and GitHub today. | 16:01 |
| gtema | cardoe - question for driver or the cliauth plugin? | 16:01 |
| noonedeadpunk | ut also I can recall slightly different path in keystone code for okta vs keycloack | 16:01 |
| cardoe | for the cliauth piece | 16:01 |
| noonedeadpunk | so adding compatability is normal evolvment | 16:02 |
| gtema | ah ok. I meant that the backend is keycloak only | 16:02 |
| cardoe | pip install python-openstackclient keystoneauth-websso locally on my machine | 16:02 |
| 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 |
| d34dh0r53 | #endmeeting | 16:02 |
| opendevmeet | Meeting ended Wed Oct 9 16:02:47 2024 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 16:02 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/keystone/2024/keystone.2024-10-09-15.05.html | 16:02 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/keystone/2024/keystone.2024-10-09-15.05.txt | 16:02 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/keystone/2024/keystone.2024-10-09-15.05.log.html | 16:02 |
| noonedeadpunk | thanks d34dh0r53! | 16:02 |
| cardoe | d34dh0r53: thanks. sorry for blowing up the schedule. :/ | 16:03 |
| d34dh0r53 | not at all cardoe , this is why we have the open discussion time | 16:03 |
| cardoe | So in my clouds.yaml I've got auth_type: v3websso \n identity_provider: github \n protocol: openid \n auth_url: https://mycloud.cardoe.com | 16:04 |
| gtema | I have no problems with the getting the plugin in except that future improvements of federation in KS may break it | 16:05 |
| cardoe | And when I run any openstack CLI command if my token is expired or I don't have one my browser window opens and takes me to GitHub.com to login (if I'm not already logged in) and then approve the app. Once I approve I get redirected to http://localhost:9999 and it tells me I can close the browser tab. | 16:05 |
| cardoe | I go back to my shell and the command worked. | 16:05 |
| gtema | don't forget that it requires special treatment of the keystone.conf | 16:08 |
| gtema | this is what eventually not all CSPs are happy with and/or not with the exact value for the callback | 16:08 |
| cardoe | I'm all for future improvements. So happy to fix it up or even deprecate it. | 16:08 |
| gtema | sure, but you should not hurry merging some new functionality when you know that you are going to do major rework here and ready for deprecation of that freshly added functionality | 16:09 |
| gtema | we have a huge problem across OpenStack in needing to support every buggy feature we accidentally introduced for backwards compatibility reasons | 16:10 |
| cardoe | I understand. | 16:13 |
| cardoe | I'm just trying to find a way to do OIDC auth that functions today and I ran across that plugin. I've learned that 3 operators use it so it seemed like there was a demand for something like that. | 16:14 |
| gtema | I totally get it. But my big big ask: do not hurry things in the identity, it's a terribly sensitive and dangerous area where with a tiny change you can introduce huge vulnerabilities. It requires very deep knowledge | 16:16 |
| cardoe | Sure. I understand. It's been an out of tree plugin for a while. https://github.com/IFCA-Advanced-Computing/keystoneauth-oidc that's where vexxhost's copy started from. | 16:19 |
| gtema | I know the history of it | 16:19 |
| opendevreview | Merged openstack/oslo.limit master: Declare Python 3.12 support https://review.opendev.org/c/openstack/oslo.limit/+/931928 | 16:32 |
| opendevreview | Merged openstack/oslo.policy master: Declare Python 3.12 support https://review.opendev.org/c/openstack/oslo.policy/+/931932 | 16:40 |
| opendevreview | Artem Goncharov proposed openstack/keystone master: Ruff the code https://review.opendev.org/c/openstack/keystone/+/931959 | 17:01 |
| opendevreview | Antonia Gaete proposed openstack/keystone master: Add JSON schema to `trust` and validation decorators to trust resource. https://review.opendev.org/c/openstack/keystone/+/930361 | 17:16 |
| opendevreview | Antonia Gaete proposed openstack/keystone master: Add JSON Schema to `endpoint groups` and validation decorators to endpoint groups resource. https://review.opendev.org/c/openstack/keystone/+/929686 | 18:06 |
| opendevreview | Antonia Gaete proposed openstack/keystone master: WIP: Add JSON Schema to `endpoint groups` and validation decorators to endpoint groups resource. https://review.opendev.org/c/openstack/keystone/+/929686 | 18:06 |
| opendevreview | Merged openstack/oslo.policy master: Remove fallback to DEFAULT section https://review.opendev.org/c/openstack/oslo.policy/+/908315 | 18:09 |
| opendevreview | Antonia Gaete proposed openstack/keystone master: Add JSON Schema to `endpoints` and validation decorators to endpoints resource. https://review.opendev.org/c/openstack/keystone/+/927856 | 18:24 |
| opendevreview | Antonia Gaete proposed openstack/keystone master: Add JSON Schema to `endpoint groups` and validation decorators to endpoint groups resource. https://review.opendev.org/c/openstack/keystone/+/929686 | 18:27 |
| opendevreview | Oria Weng proposed openstack/keystone master: Add JSON schema to `limits` https://review.opendev.org/c/openstack/keystone/+/931528 | 19:29 |
| cardoe | so fwiw, noonedeadpunk and gtema "openstack --debug role add --group <group> --inherited --domain <domain> <role>" seems to confirm that https://docs.openstack.org/api-ref/identity/v3/#assign-role-to-group-on-projects-owned-by-a-domain is called. | 23:39 |
| cardoe | I think my issue is that my user had manager on a domain but it wasn't inherited. So when member was inherited it wasn't working. At least that's my guess because I wiped everything and it's working consistently. | 23:41 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!