16:59:23 #startmeeting keystone 16:59:24 Meeting started Tue Jul 21 16:59:23 2020 UTC and is due to finish in 60 minutes. The chair is knikolla. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:59:25 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:59:27 The meeting name has been set to 'keystone' 16:59:30 o/ 16:59:40 o/ 17:00:08 Hi 17:03:31 i'll give it a few more minutes in hope of having some form of quorum. 17:06:00 o/ 17:09:30 o/o/ 17:09:55 seems like we have enough attendance to proceed :) 17:10:21 #topic Review Requests 17:11:29 #link https://review.opendev.org/#/c/737225/ This patch closes bug targeted for victoria miltstone 2 17:12:49 #link https://review.opendev.org/#/c/739784/ , that closes-bug #link https://bugs.launchpad.net/keystone/+bug/1886017 need one more approval 17:12:50 Launchpad bug 1886017 in OpenStack Identity (keystone) ""allow expired" feature is broken against json web token" [Medium,In progress] - Assigned to Vishakha Agarwal (vishakha.agarwal) 17:13:11 and a small one #link https://review.opendev.org/#/c/742233/ 17:13:54 thanks, added to my to-do list. i had somehow missed the first one. 17:16:15 #topic Bugs 17:16:37 last week we talked about https://review.opendev.org/#/c/731087/ 17:16:40 #link https://review.opendev.org/#/c/731087/, we discussed this in the last meeting but did not come to any conclusion. There were two approaches for this one, to update the operators about deleting stale role in release note or to go for upgrade check 17:17:39 i think the upgrade check method was problematic in not working within the same release, but requiring an upgrade. 17:17:51 so i thought we were okay with a release note. 17:18:06 and apparently there was a precedent. 17:19:15 Yes there was. Since all are okay to update release notes with a SQL query to remove stale role assignments 17:19:32 I will update the patch set. 17:20:17 Thanks knikolla 17:22:27 #topic Keystone project hierarchy manual validation 17:22:36 whoami-rajat__: o/ 17:22:42 Hi everyone 17:23:10 I've some doubts regarding the hierarchical multi tenancy spec 17:23:38 So currently cinder quotas validate the project in the following manner 17:23:53 1) if context project is immediate parent of the target project 17:24:11 2) context project is the root of the subtree for which the target project is a part of 17:24:27 #link https://github.com/openstack/cinder/blob/master/cinder/api/contrib/quotas.py#L91-L110 17:25:12 so my questions are, is the sub project part of keystone still promoted/used or replaced by a better solution 17:25:36 second, if it's still used, is our method of validation mentioned above right? 17:26:24 looking at the code 17:28:21 also (if my question doesn't sound too dumb), what does is_admin_project signify? I've seen that being true in all the combinations of project and users 17:30:02 is_admin_project was a previous attempt to solve the issue with admin on a project being admin everywhere, but we've deprecated that approach in favor of system scope for admin operations. 17:31:35 ack. would be great to know if any project has used that feature for authorization 17:31:49 whoami-rajat__: you mean the admin project or the new system scoping? 17:32:05 system scoping 17:32:25 nova has implemented it, but it's not enabled by default. keystone as well, but likewise, it's not enabled by default. 17:33:04 ok. would refer nova for the same. 17:33:25 in https://github.com/openstack/cinder/blob/be4a682890e6c5aeee0f34891a80bfbe2aab7c6a/cinder/api/contrib/quotas.py#L95 i'm not sure why you're checking if the scoped project has a parent (first half of the conditional) 17:34:24 knikolla: if it has a parent means it's not the root of the tree, and it should be the immediate parent of the target project 17:34:46 ah, got it. 17:34:57 if it is the root it doesn't matter if it's not the immediate parent of the target. 17:35:18 yep, that's my understanding of this validation check 17:35:56 i don't think any other project has validation checks in place to allow operations only on the immediate parent (or root) 17:36:07 so this is something new to me. 17:36:28 oh 17:36:43 i thought this was the purpose of hierarchical projects 17:36:58 i think we envisioned these sort of operations to be performed by the domain admin. 17:37:35 lbragstad, gagehugo: correct me if i'm wrong on ^ 17:38:26 just for some more context, we're developing a new feature which will enable default types for each project. so this is the only validation in place in cinder 17:38:50 to set, get or delete default types for a project 17:39:16 If there's a better way to authorize this, would be great to know that 17:39:58 https://docs.openstack.org/keystone/latest/admin/service-api-protection.html 17:40:39 this is how we envisioned the different permission levels that people may require 17:40:57 in particular Domain Administrators 17:41:54 all this info exists in the context right? 17:42:18 oslo.context knows how to represent systme-scoped tokens, yes 17:42:36 yes, a project has a domain_id, and the token would have either system-scope (for global admin) or domain-scope on that domain (for domain admin) 17:44:16 I've one context dict that i took out while debugging the code 17:44:18 http://paste.openstack.org/show/796184/ 17:44:42 'project_domain_id': 'default' 17:45:07 but ideally, you should use oslo.policy for the policy checking and not really need to do this in code manually 17:45:50 yes, we use context.authorize but i guess it just authorizes the user is an admin or owner or ... depending on the policy in code 17:46:30 https://github.com/openstack/cinder/blob/master/cinder/api/contrib/quotas.py#L171-L172 17:48:04 or maybe I've some limited understanding of the policies 17:49:50 there is a popup team to help address this openstack-wide https://wiki.openstack.org/wiki/Consistent_and_Secure_Default_Policies_Popup_Team 17:50:11 not sure if raildo is around 17:50:24 knikolla, o/ 17:51:22 Hi, about these oslo.limit review : https://review.opendev.org/#/c/733881/ then https://review.opendev.org/#/c/726929/, do we have any status ? 17:51:45 knikolla: yeah Brian is the cinder liaison but has the same doubts as me :D 17:51:52 knikolla: anyway, thanks a lot for all the information 17:52:08 i will go through it and let you know if i have more doubts? 17:52:33 whoami-rajat__: of course, this is definitely a longer discussion than just this meeting and should be tracked in an etherpad. 17:52:44 whoami-rajat__, we can talk about that on #openstack-keystone after the meeting, if you want to 17:53:48 knikolla: raildo Thanks but it is very late here in India, 23:23 , can we discuss this tomorrow? 17:54:09 whoami-rajat__, for sure, just ping me whenever you see me online :) 17:54:29 raildo: sure, thanks a lot :) 17:56:29 alistarle: i can have a look at them, but they're not my area of expertise. I'd defer to either lbragstad or cmurphy on them. 17:56:58 Good, I think at least the first one is pretty staightforward, and it is a requirement for the second, which is a requirement for glance integration :D 17:58:15 whoami-rajat__ if you need help with the policy work or understanding it, just let me know 17:58:55 thanks lbragstad , sure :) 17:58:55 whoami-rajat__ i'd be happy to set aside some time and organize a high-bandwidth meeting if necessary 17:59:31 i think Brian would be interested in that as well 17:59:37 we used to have a weekly meeting just for policy stuff around 2 years ago. 18:00:09 alright, we're out of time, off to #openstack-keystone. 18:00:11 thanks all 18:00:19 #endmeeting