| *** mhen_ is now known as mhen | 01:13 | |
| opendevreview | Matúš Jenča proposed openstack/keystonemiddleware master: Support Redis and Redis Sentinel Cache https://review.opendev.org/c/openstack/keystonemiddleware/+/915872 | 08:35 |
|---|---|---|
| opendevreview | Takashi Kajinami proposed openstack/keystone master: Remove tempest plugin directory https://review.opendev.org/c/openstack/keystone/+/916052 | 09:23 |
| opendevreview | Markus Hentsch proposed openstack/keystone-specs master: Add identity spec for domain-manager role https://review.opendev.org/c/openstack/keystone-specs/+/903172 | 12:44 |
| opendevreview | Markus Hentsch proposed openstack/keystone-specs master: Add identity spec for domain-manager role https://review.opendev.org/c/openstack/keystone-specs/+/903172 | 12:47 |
| opendevreview | Markus Hentsch proposed openstack/keystone-specs master: Add identity spec for domain-manager role https://review.opendev.org/c/openstack/keystone-specs/+/903172 | 12:49 |
| opendevreview | Markus Hentsch proposed openstack/keystone-specs master: Add identity spec for Domain Manager persona https://review.opendev.org/c/openstack/keystone-specs/+/903172 | 12:54 |
| dmendiza[m] | 🙋 | 15:02 |
| mhen | \o/ | 15:02 |
| dmendiza[m] | d34dh0r53 👋 | 15:03 |
| gtema | isn't it 1 hour too late or is my clock wrong? | 15:03 |
| blarnath | o | 15:03 |
| bbobrov | ah the sweet post-clock-change moments | 15:04 |
| dmendiza[m] | gtema: possibly? 🤔 My work calendar has an entry for now. | 15:04 |
| dmendiza[m] | But that could be wrong. | 15:04 |
| * dmendiza[m] checks the officiall listing | 15:04 | |
| mhen | https://meetings.opendev.org/#Keystone_Team_Meeting | 15:04 |
| mhen | it says 15 UTC | 15:04 |
| mhen | and web search says that is right now | 15:04 |
| dmendiza[m] | #link https://meetings.opendev.org/#Keystone_Team_Meeting | 15:04 |
| dmendiza[m] | JINX! | 15:04 |
| *** blarnath is now known as d34dh0r53 | 15:04 | |
| d34dh0r53 | freaking nickserv | 15:05 |
| gtema | hmm, ok | 15:05 |
| d34dh0r53 | sorry | 15:05 |
| d34dh0r53 | #startmeeting keystone | 15:05 |
| opendevmeet | Meeting started Wed Apr 17 15:05:21 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 | #topic roll call | 15:05 |
| xek | o/ | 15:05 |
| mhen | o/ | 15:05 |
| dmendiza[m] | 🙋♂️ | 15:05 |
| d34dh0r53 | admiyo, bbobrov, crisloma, d34dh0r53, dpar, dstanek, hrybacki, knikolla[m], lbragstad, lwanderley, kmalloc, rodrigods, samueldmq, ruan_he, wxy, sonuk, vishakha, Ajay, rafaelwe, xek, gmann, zaitcev, reqa, dmendiza[m], mharley, jph, gtema | 15:05 |
| bbobrov | \o | 15:06 |
| d34dh0r53 | o/ | 15:06 |
| d34dh0r53 | #topic review past meeting work items | 15:06 |
| d34dh0r53 | no updates from me | 15:07 |
| d34dh0r53 | #action d34dh0r53 Look into adding/restoring a known issues section to our documentation | 15:07 |
| d34dh0r53 | #action d34dh0r53 add https://bugs.launchpad.net/keystone/+bug/1305950 to the known issues section of our documentation | 15:08 |
| d34dh0r53 | next up | 15:08 |
| d34dh0r53 | #topic liaison updates | 15:08 |
| d34dh0r53 | nothing from VMT | 15:08 |
| d34dh0r53 | nor releases | 15:08 |
| d34dh0r53 | moving on to specifications | 15:09 |
| d34dh0r53 | #topic specification OAuth 2.0 (hiromu) | 15:09 |
| d34dh0r53 | #link https://review.opendev.org/q/topic:bp%252Foauth2-client-credentials-ext | 15:09 |
| d34dh0r53 | #link https://review.opendev.org/q/topic:bp%252Fenhance-oauth2-interoperability | 15:09 |
| d34dh0r53 | External OAuth 2.0 Specification | 15:09 |
| d34dh0r53 | #link https://review.opendev.org/c/openstack/keystone-specs/+/861554 | 15:09 |
| d34dh0r53 | OAuth 2.0 Implementation | 15:09 |
| d34dh0r53 | #link https://review.opendev.org/q/topic:bp%252Fsupport-oauth2-mtls | 15:09 |
| d34dh0r53 | OAuth 2.0 Documentation | 15:09 |
| d34dh0r53 | #link https://review.opendev.org/c/openstack/keystone/+/838108 | 15:09 |
| d34dh0r53 | #link https://review.opendev.org/c/openstack/keystoneauth/+/838104 | 15:09 |
| d34dh0r53 | did anyone see hiromu or anyone from Tacker at the PTG? | 15:10 |
| d34dh0r53 | Tacker did not have a session that I saw | 15:10 |
| d34dh0r53 | welp, if you see hiromu or anyone from Tacker online have them ping me | 15:12 |
| d34dh0r53 | next up | 15:12 |
| d34dh0r53 | #topic specification Secure RBAC (dmendiza[m]) | 15:12 |
| d34dh0r53 | #link https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#z-release-timeline_ | 15:12 |
| d34dh0r53 | 2024.1 Release Timeline | 15:12 |
| d34dh0r53 | Update oslo.policy in keystone to enforce_new_defaults=True | 15:12 |
| d34dh0r53 | Update oslo.policy in keystone to enforce_scope=True | 15:12 |
| d34dh0r53 | #link https://review.opendev.org/c/openstack/keystone/+/902730 (Merged) | 15:12 |
| d34dh0r53 | #link https://review.opendev.org/c/openstack/keystone-tempest-plugin/+/903713 (Merged) | 15:13 |
| d34dh0r53 | #link ttps://review.opendev.org/c/openstack/tempest/+/912489 | 15:13 |
| dmendiza[m] | Things are looking good | 15:13 |
| dmendiza[m] | most of the patches I've submitted have merged | 15:13 |
| dmendiza[m] | I want to say we are again enforcing the SRBAC job in Keystone which is great | 15:13 |
| dmendiza[m] | The only outstanding patch I have is for Tempest where I enable SRBAC on Keystone | 15:14 |
| dmendiza[m] | #link https://review.opendev.org/c/openstack/tempest/+/912489 | 15:14 |
| d34dh0r53 | I just reviewed that one | 15:14 |
| dmendiza[m] | Got one +2 for now (thanks gmann!) | 15:14 |
| dmendiza[m] | d34dh0r53: thanks! | 15:14 |
| d34dh0r53 | I need to figure out the correct way to release keystone-tempest-plugin | 15:14 |
| dmendiza[m] | That's all for now | 15:14 |
| d34dh0r53 | thanks dmendiza[m] | 15:14 |
| dmendiza[m] | I still have not caught up on SRBAC PTG things | 15:14 |
| d34dh0r53 | next up | 15:14 |
| dmendiza[m] | so maybe more next week | 15:14 |
| d34dh0r53 | #topic specification Improve federated users management (gtema) | 15:15 |
| d34dh0r53 | #link https://review.opendev.org/c/openstack/keystone-specs/+/748748 - waiting for reviews | 15:15 |
| gtema | I am stuck in a conflict with the spec author | 15:15 |
| gtema | I think the proposed API change is dangerous and error prone while he apparently not sees the problem | 15:16 |
| gtema | apparently someone from cores need to step up to decide | 15:17 |
| d34dh0r53 | yeah, reading the thread now | 15:19 |
| d34dh0r53 | we'll discuss this in the reviewathon this Friday | 15:20 |
| bbobrov | do i understand correctly, that the author proposes to get projects and assignments as a json from an IdP? | 15:20 |
| gtema | yes | 15:20 |
| gtema | but the point is HOW | 15:21 |
| gtema | there is "projects" field | 15:21 |
| gtema | and he proposes adding projects_json field which will be string and merged in Keystone | 15:21 |
| gtema | INSTEAD of making "projects" field being oneOf: [object, string] | 15:21 |
| d34dh0r53 | I'm going to defer this to the reviewathon, I'd really like to hear the other cores opinion on this one | 15:25 |
| gtema | ok, thks. Just for reference: all OpenStack apis are relying on polymorphism | 15:26 |
| gtema | and here it is proposed to go back to "counter_str" and "counter_int" style | 15:26 |
| d34dh0r53 | that's a good point | 15:27 |
| gtema | and especially splitting user data between static config on the Keystone side and data coming from external IdP and merge it is especially dangerous | 15:27 |
| gtema | purpose of the changes in the ephemeral users mgmt is to have 1 system (external IdP) responsible for the data | 15:28 |
| gtema | splitting it feels like a knife in the back during the security audits | 15:29 |
| gtema | ok, we can go on | 15:30 |
| d34dh0r53 | food for thought | 15:31 |
| d34dh0r53 | moving on | 15:31 |
| d34dh0r53 | #topic specification OpenAPI support (gtema) | 15:32 |
| d34dh0r53 | #link https://review.opendev.org/c/openstack/keystone-specs/+/910584 | 15:32 |
| gtema | i checked, stephenfin linked my spec for PTG, so we are really talking about singe thing and single spec | 15:32 |
| d34dh0r53 | ack, this spec is the only one now, correct? | 15:33 |
| gtema | right | 15:33 |
| d34dh0r53 | cool | 15:33 |
| gtema | means: spec is there and needs reviews | 15:34 |
| d34dh0r53 | will do | 15:34 |
| gtema | thks | 15:35 |
| d34dh0r53 | np | 15:35 |
| d34dh0r53 | #topic open discussion | 15:35 |
| d34dh0r53 | passlib update | 15:35 |
| d34dh0r53 | The maintainer responded to the bug, and one of the top priorities is to fix the bcrypt version bug | 15:35 |
| d34dh0r53 | #link https://foss.heptapod.net/python-libs/passlib/-/issues/190 | 15:35 |
| d34dh0r53 | Targeted to 1.7.5 | 15:35 |
| d34dh0r53 | I pinged on the bug again last week for an update on 1.7.5 and we still don't have one | 15:36 |
| d34dh0r53 | The maintainer really needs to hand over the reigns to someone | 15:36 |
| gtema | yupp | 15:36 |
| d34dh0r53 | I'll continue to ping in the issue | 15:37 |
| bbobrov | internet_infrastructure_and_overworked_maintainer.jpg | 15:37 |
| d34dh0r53 | domain manager (mhen) | 15:37 |
| d34dh0r53 | https://review.opendev.org/c/openstack/keystone-specs/+/903172 | 15:37 |
| d34dh0r53 | addressed review comments | 15:37 |
| d34dh0r53 | rebased on 2024.1, renamed to domain-manager-persona (from "...-role") | 15:37 |
| mhen | as mentioned in the PTG this one needs new reviews | 15:38 |
| mhen | I rebased it and also cleaned up existing comments | 15:38 |
| d34dh0r53 | ack, I didn't look but it failed some checks | 15:38 |
| gtema | today I looked at it and I feel like it again talks about ...-role | 15:38 |
| mhen | wait ... did I mess up? | 15:39 |
| gtema | i think so | 15:39 |
| gtema | the file got renamed, but the content tells different | 15:39 |
| mhen | oh shoot | 15:39 |
| mhen | thanks for bringing this up | 15:39 |
| mhen | something got rolled back during my git-review commands it seems | 15:40 |
| gtema | sure | 15:40 |
| mhen | will clear this up asap | 15:40 |
| mhen | yea sorry about that, I will fix it - we can move on | 15:41 |
| d34dh0r53 | thank you mhen | 15:42 |
| d34dh0r53 | next up | 15:42 |
| d34dh0r53 | domain list scoping fix (mhen) | 15:42 |
| d34dh0r53 | the main fix was merged a while ago: https://review.opendev.org/c/openstack/keystone/+/900028 | 15:42 |
| d34dh0r53 | Q: is https://review.opendev.org/c/openstack/keystone-tempest-plugin/+/900545 still applicable? | 15:42 |
| d34dh0r53 | it would have been a necessary adjustment to the tempest tests after the above merge but tests have been restructured in the meantime (mentioned at PTG) | 15:42 |
| d34dh0r53 | this is a question for dmendiza[m] | 15:42 |
| d34dh0r53 | he might not be around, I still need to talk with him about the next topic so I'll raise this as well | 15:45 |
| d34dh0r53 | policy API and OS-ENDPOINT-POLICY | 15:45 |
| d34dh0r53 | policy API is deprecated | 15:45 |
| d34dh0r53 | OS-ENDPOINT-POLICY depends on it | 15:45 |
| d34dh0r53 | what is the status? | 15:45 |
| d34dh0r53 | as I mentioned dmendiza[m] and I need to talk about this question, I'll have a meeting with him this afternoon | 15:45 |
| bbobrov | all right! | 15:46 |
| d34dh0r53 | Enforcing scope in keystone breaks heat (and probably magnum) (tkajinam) | 15:46 |
| d34dh0r53 | https://bugs.launchpad.net/keystone/+bug/2059780 | 15:46 |
| d34dh0r53 | https://review.opendev.org/c/openstack/keystone/+/914759 | 15:46 |
| tkajinam | I'm unsure if this was covered in the past meeting, but I wanted to make sure you are aware of this problem since you were talking about enforcing scope by default | 15:46 |
| tkajinam | I started testing heat with new defaults/scope enforcement enabled in all services and this is the first problem I'm hitting now. I suspect there can be a few more domain admin rules we have to fix but I'll test the scenario further to catch these | 15:47 |
| tkajinam | fyi. This is the problem I raised during the RBAC session during the last ptg, in case you were there. | 15:49 |
| d34dh0r53 | thank you for the awareness tkajinam | 15:49 |
| d34dh0r53 | I missed the RBAC session | 15:49 |
| d34dh0r53 | unfortunately, really kicking myself for missing that | 15:49 |
| opendevreview | Markus Hentsch proposed openstack/keystone-specs master: Add identity spec for Domain Manager persona https://review.opendev.org/c/openstack/keystone-specs/+/903172 | 15:49 |
| tkajinam | no problem :-) | 15:50 |
| d34dh0r53 | I've added dmendiza[m] as a reviewer | 15:50 |
| d34dh0r53 | moving on for the sake of time | 15:51 |
| d34dh0r53 | #topic bug review | 15:51 |
| d34dh0r53 | #link https://bugs.launchpad.net/keystone/?orderby=-id&start=0 | 15:51 |
| d34dh0r53 | looks like a new bug about password length notifications | 15:52 |
| d34dh0r53 | #link https://bugs.launchpad.net/keystone/+bug/2061922 | 15:52 |
| bbobrov | that is a cover bug for my spec | 15:52 |
| bbobrov | oh | 15:53 |
| bbobrov | no | 15:53 |
| bbobrov | sorry | 15:53 |
| bbobrov | disregard that | 15:53 |
| d34dh0r53 | ahh, ok | 15:54 |
| d34dh0r53 | this one is | 15:54 |
| d34dh0r53 | #link https://bugs.launchpad.net/keystone/+bug/2060972 | 15:54 |
| bbobrov | re https://bugs.launchpad.net/keystone/+bug/2061922 - the uncertainty around these numbers and password length is one of the factors preventing me from upgrading from Zed | 15:54 |
| d34dh0r53 | noted, I'll make sure it's consistent and correct | 15:55 |
| d34dh0r53 | finally in keystone | 15:57 |
| d34dh0r53 | #link https://bugs.launchpad.net/keystone/+bug/2060452 | 15:57 |
| d34dh0r53 | it's being worked and will need reviews | 15:57 |
| d34dh0r53 | next up | 15:58 |
| d34dh0r53 | #link https://bugs.launchpad.net/python-keystoneclient/?orderby=-id&start=0 | 15:58 |
| d34dh0r53 | no new bugs there | 15:58 |
| d34dh0r53 | #link https://bugs.launchpad.net/keystoneauth/+bugs?orderby=-id&start=0 | 15:58 |
| d34dh0r53 | keystoneauth has no new bugs | 15:58 |
| d34dh0r53 | keystonemiddleware is also good | 15:59 |
| d34dh0r53 | #link https://bugs.launchpad.net/keystonemiddleware/+bugs?orderby=-id&start=0 | 15:59 |
| d34dh0r53 | sorry, link would be helpful for middleware ;) | 15:59 |
| d34dh0r53 | #link https://bugs.launchpad.net/pycadf/+bugs?orderby=-id&start=0 | 15:59 |
| d34dh0r53 | nothing new for pycadf | 15:59 |
| d34dh0r53 | #link https://bugs.launchpad.net/ldappool/+bugs?orderby=-id&start=0 | 16:00 |
| d34dh0r53 | ldappool is also good | 16:00 |
| d34dh0r53 | that does it for bug review | 16:00 |
| d34dh0r53 | #topic conclusion | 16:00 |
| d34dh0r53 | Good to see folks at the PTG and I'm looking forward to this cycle | 16:00 |
| d34dh0r53 | Reviewathon on Friday, please let me know if you'd like a calendar invite | 16:01 |
| d34dh0r53 | That's it for me, anything else? | 16:01 |
| d34dh0r53 | Thanks folks! | 16:01 |
| d34dh0r53 | #endmeeting | 16:01 |
| opendevmeet | Meeting ended Wed Apr 17 16:01:47 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-04-17-15.05.html | 16:01 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/keystone/2024/keystone.2024-04-17-15.05.txt | 16:01 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/keystone/2024/keystone.2024-04-17-15.05.log.html | 16:01 |
| bbobrov | i have a small post-meeting note then | 16:01 |
| bbobrov | I would like to say that it is rather unfortunate that https://review.opendev.org/c/openstack/keystone/+/900028 got merged. | 16:01 |
| bbobrov | I am a domain admin of D-A. I would like to give a user from domain D-B a role assignment on my domain D-A. How do i now find out the user id from domain D-B, if i cannot find out the id of domain D-B? D-B now does not show up in the list. | 16:02 |
| bbobrov | In our deployment domain list and their ids are basically public, anybody can read them. | 16:02 |
| bbobrov | The change basically enforces new defaults and enforces scoping rules, completely ignoring the 2 options that control that. | 16:02 |
| bbobrov | (the API stability got broken, which is what i mentioned in the review) | 16:03 |
| bbobrov | I will open a bugreport about it. | 16:03 |
| tkajinam | bbobrov, I'm not too sure (though I'm not an expert about these scope thing) if that is a bug. You are attempting cross domain operation which may be allowed for system scope in the initial design | 16:05 |
| gtema | in a bigger public cloud you should not be able to see foreign domain | 16:06 |
| tkajinam | bbobrov, if you want to allow the domain admin of D-A to do that operation then the admin may need at least reader role for domain B | 16:06 |
| tkajinam | First use domain B scope to list that user and switch domain A scope to add role. that is a valid (and *appropriate*) method I think | 16:07 |
| gtema | +1 | 16:07 |
| bbobrov | tkajinam: i agree with you. And i agree that that should have been implemented differently initially. But the behavior is there, and i depend on it. Because there is a promise of API stability. | 16:07 |
| tkajinam | we didn | 16:08 |
| tkajinam | we didn't intend to keep all single policy behaviors when we introduced SRBAC concept. We deprecated the legacy policy rules so that we can change the behavior | 16:08 |
| bbobrov | tkajinam: enforcement of scopes happens via enforce_scope=True, which is still False even upstream, and big downstream clouds will live with it =False for much-much longer | 16:09 |
| tkajinam | we, though, eventually decided to keep behavior of project admin, since project admin as cloud admin was something too many operators have relied on | 16:09 |
| bbobrov | gtema: i am not an operator of a big public cloud, i am an operator of a big old private cloud. | 16:09 |
| gtema | bbobrov, I understand. I am telling you the public cloud pov and requirements coming from there | 16:11 |
| bbobrov | gtema: and i am telling you about requirements coming from another place | 16:12 |
| gtema | :) | 16:12 |
| tkajinam | bbobrov, I wonder if you can use project admin then ? it's less smart but I guess it would work | 16:12 |
| tkajinam | as project admin is retaining the permission to manage the whole cloud resources, even whole domain | 16:13 |
| tkajinam | hmm maybe not, if you don't want to limit the effect to keystone | 16:13 |
| tkajinam | s/don't//g | 16:14 |
| tkajinam | gmann, ^^^ fyi... strict domain scope is killing one usage inf the field, it seems | 16:14 |
| tkajinam | I don't know why this is raised at the real last timing of several years of SRBAC work but this is how software used in the field works, I guess | 16:15 |
| bbobrov | tkajinam: a (usual) project admin cannot make domain assignments. There is an actual person, who is a domain admin, and might have no project-level assignments. | 16:15 |
| bbobrov | it is not like i am putting on one hat or another. | 16:16 |
| tkajinam | I could be wrong but the latest keystone may allow role assignments between user and domain since https://review.opendev.org/c/openstack/keystone/+/902730 | 16:17 |
| tkajinam | allow project admin to manage domain-level role assignments, I mean | 16:18 |
| gmann | bbobrov: tkajinam: but scope things are something keystone want to make it strict wit new RBAC. I think plan will be to keep the enforce_scope as false until you are migrating tokens as per new RBAC and later once migration is done then we can remove enforce_scope itself | 17:06 |
| gmann | this is whole idea of SRBAC to have more secure permission by default | 17:07 |
| bbobrov | gmann: i understand that. When it is done and ready and has a release note and stuff like that. The merged change is silent and changes the behavior _now_. | 17:57 |
| bbobrov | (i still do not understand how to allow the domain admin perform the actions i described earlier, without making them switch the context for python-openstackclient) | 18:01 |
| opendevreview | Takashi Kajinami proposed openstack/keystone master: Allow domain admin to view roles https://review.opendev.org/c/openstack/keystone/+/914759 | 18:17 |
| opendevreview | Takashi Kajinami proposed openstack/keystone master: Allow domain users to manage credentials https://review.opendev.org/c/openstack/keystone/+/916130 | 18:17 |
| gmann | bbobrov: I see your point. dmendiza[m] might help you on releasenotes etc and keeping backward compatibility for some time | 18:36 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!