16:59:40 <knikolla> #startmeeting keystone
16:59:41 <openstack> Meeting started Tue Jul 28 16:59:40 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:42 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:59:44 <openstack> The meeting name has been set to 'keystone'
16:59:47 <cmurphy> o/
16:59:49 <knikolla> o/
17:00:59 <lbragstad> o/
17:01:06 <vishakha> o/
17:01:43 <gagehugo> o/
17:02:24 <knikolla> cool, we can get started.
17:02:29 <knikolla> #topic Review Requests
17:02:48 <knikolla> I'm way behind on reviews, I apologize.
17:08:05 <tosky> if you want to remove keystone from the list of projects which still need to clean the remaining zuul legacy jobs, please take a look at https://review.opendev.org/#/c/733801/ :)
17:08:17 <knikolla> copying from vishakha from the #openstack-keystone room
17:08:21 <knikolla> 1:03 PM <vishakha> Seems like keystone gate is broken , I pushed a fix for that #link #link https://review.opendev.org/#/c/742956/ (Keystone gate fix)
17:08:21 <knikolla> 1:03 PM <vishakha> #link https://review.opendev.org/#/c/737225/ (Targeted for Victoria-Milestone-2),
17:08:22 <knikolla> 1:05 PM <vishakha> and some other #link https://review.opendev.org/#/c/743489/  #link https://review.opendev.org/#/c/739784/
17:08:22 <knikolla> 1:05 PM <vishakha>  #link https://review.opendev.org/#/c/742233/ (NIT)
17:08:22 <knikolla> 1:05 PM <vishakha> #link https://review.opendev.org/#/c/731087/
17:09:10 <vishakha> Sorry I didnt realize I pasted on the wrong chaneel
17:10:27 <knikolla> thanks tosky, i pushed that through
17:11:02 <tosky> thank you! I will propose a backport to cover at least ussuri, but that's out of goal scope, so less priority
17:11:25 <knikolla> ok, cool
17:11:41 <knikolla> grazie
17:15:56 <knikolla> #topic Bugs
17:18:28 <knikolla> with regards to https://bugs.launchpad.net/keystone/+bug/1693498
17:18:30 <openstack> Launchpad bug 1693498 in OpenStack Identity (keystone) "Credential list API returns list of available credentials when user passes invalid name as query parameter" [Undecided,In progress] - Assigned to Vishakha Agarwal (vishakha.agarwal)
17:18:48 <vishakha> #link https://bugs.launchpad.net/keystone/+bug/1693498 As per this bug, the bug reportee expects the output to be empty list when passing wrong filters in the CURL request, but in keystone the functionality is to ignore the invalid filters in def build_driver_hints https://github.com/openstack/keystone/blob/dc68ee48160e8ad9b637f3d91b18a42dbfdf012b/keystone/server/flask/common.py#L820
17:19:25 <vishakha> which results giving the whole list.
17:19:33 <knikolla> is the report about the wrong filter query key, or the wrong value?
17:20:26 <cmurphy> i think it's about the key
17:21:12 <vishakha> Yes its about the keys "In my opinion to maintain the consistency, Credential list API should return empty list when invalid query parameter is passed"
17:21:26 <knikolla> i have concerns about suddenly switching our API behavior to return 400 on wrong key.
17:21:34 <cmurphy> knikolla: ++
17:21:47 <vishakha> We test the behavior too https://github.com/openstack/keystone/blob/master/keystone/tests/unit/test_v3_filters.py#L187
17:22:16 <knikolla> in that case i would say this is a wontfix, unless we have microversions.
17:22:22 <lbragstad> https://bugs.launchpad.net/keystone/+bug/1654084
17:22:23 <openstack> Launchpad bug 1654084 in OpenStack Identity (keystone) "Listing resources with invalid filters should result in a 400" [Wishlist,Triaged]
17:23:07 <knikolla> thanks lbragstad, that provides more context.
17:23:21 <cmurphy> https://bugs.launchpad.net/keystone/+bug/1654084/comments/7
17:23:44 <lbragstad> sounds like we can close both?
17:24:00 <cmurphy> i would add priority "wishlist" and tag "needs microversion" or whatever
17:24:03 <knikolla> we can keep it around as wishlist and tagged as need microversion
17:24:10 <cmurphy> we have a few others like that
17:24:16 <knikolla> cmurphy: ++
17:25:48 <vishakha> SHould I update these that we need microversion?
17:25:52 <cmurphy> done
17:26:02 <lbragstad> could we consolidate them?
17:26:08 <lbragstad> or do we have a reason to keep both open
17:26:13 <knikolla> we can mark as duplicate
17:26:32 <knikolla> the bug that lbragstad link provides a lot more context
17:26:37 <cmurphy> ++
17:26:57 <lbragstad> i think if we were to do this, we should do it consistently across the entire api
17:27:13 <lbragstad> and not just the the credential api
17:27:19 <knikolla> yes, and across other openstack apis
17:27:36 <knikolla> (if there is such a consistency in the first place)
17:27:37 <cmurphy> marked as duplicate
17:27:48 <knikolla> thanks cmurphy
17:29:35 <knikolla> #topic Open Floor
17:29:43 <vishakha> #link https://review.opendev.org/#/c/738190/
17:30:14 <vishakha> I wanted to discuss about this change.
17:31:54 <vishakha> As per the current behavior in keystone while listing system role assignments with filter role_id, it doesn't display the implied role assignments
17:34:32 <vishakha> and I not sure that originally if it was displaying because after the change #link https://review.opendev.org/#/c/700826, it only displays the role assignments that matches the role_id
17:36:19 <cmurphy> maybe https://bugs.launchpad.net/keystone/+bug/1858012 is a duplicate of https://bugs.launchpad.net/keystone/+bug/1846817 ? i had completely forgotten about 1858012
17:36:21 <openstack> Launchpad bug 1858012 in OpenStack Identity (keystone) "List role assignments by role ID may leak extra system assignments outside of filter" [Undecided,Fix released] - Assigned to Colleen Murphy (krinkle)
17:36:22 <openstack> Launchpad bug 1846817 in OpenStack Identity (keystone) "v3/role_assignments filtering exposes unnecessary role assignments" [Medium,In progress] - Assigned to Vishakha Agarwal (vishakha.agarwal)
17:37:56 <knikolla> ah, i see.
17:38:30 <cmurphy> lbragstad: any thoughts on whether https://bugs.launchpad.net/keystone/+bug/1846817 is still applicable? i wasn't able to reproduce the bug as i understood it from the report
17:38:31 <openstack> Launchpad bug 1846817 in OpenStack Identity (keystone) "v3/role_assignments filtering exposes unnecessary role assignments" [Medium,In progress] - Assigned to Vishakha Agarwal (vishakha.agarwal)
17:39:09 <knikolla> so one piece of the bug was the leaking of more role assignment, and the other piece is the implied roles.
17:39:25 <knikolla> i think the first one was fixed by your patch to the other bug.
17:39:28 <cmurphy> no, i don't think implied roles was ever a part of it
17:39:35 <lbragstad> checking
17:39:58 <knikolla> per bug description "If I ask keystone to filter a list of role assignments by --system all and --role member, I should only see a list with the "system-support" user and the "operator" user."
17:40:07 <knikolla> the operator user would be included becase admin implies member.
17:41:01 <cmurphy> yes but in that description operator is included, the problem is that reader is also included
17:41:31 <knikolla> which feels like the extraneous entries which your patch fixed.
17:41:43 <cmurphy> right
17:42:13 <vishakha> My only concern is do we want to display the implied roles as per the bug description?
17:42:34 <vishakha> Because till now we weren't
17:43:04 <cmurphy> vishakha: is https://review.opendev.org/700826 what changed that behavior of the implied roles?
17:43:31 <cmurphy> it is concerning that that changed somehow
17:43:41 <knikolla> we already do implied roles with the "effective" query parameter, IIRC.
17:43:57 <knikolla> i don't think it's automatic.
17:44:29 <knikolla> can you try with "&effective" and see if you get the implied roles as well?
17:44:48 <cmurphy> it seemed to have been automatic in the output given in that bug report but the behavior since seemed to have changed to exclude them
17:44:49 * lbragstad is recreating the bug now
17:45:04 <cmurphy> regardless i think behavior of implied roles is a different bug
17:45:49 <knikolla> as per our api reference "If the query parameter effective is specified, rather than simply returning a list of role assignments that have been made, the API returns a list of effective assignments at the user, project and domain level, having allowed for the effects of group membership, role inference rules as well as inheritance from the parent domain or project."
17:46:03 <knikolla> the API says that it shouldn't have been automatic.
17:46:24 <lbragstad> i don't think i can recreate https://bugs.launchpad.net/keystone/+bug/1846817
17:46:25 <openstack> Launchpad bug 1846817 in OpenStack Identity (keystone) "v3/role_assignments filtering exposes unnecessary role assignments" [Medium,In progress] - Assigned to Vishakha Agarwal (vishakha.agarwal)
17:46:42 <cmurphy> knikolla: so whatever changed changed it to be correct i guess?
17:47:01 <knikolla> i guess so
17:47:13 <knikolla> and if it works correctly with "effective", we're where we want to be.
17:47:27 <lbragstad> http://paste.openstack.org/raw/796387/
17:49:01 <knikolla> lbragstad: that looks the correct default to me.
17:49:34 <lbragstad> so - something must have fixed that
17:52:18 <vishakha> So this is the right behavior and we dont need to display the implied roles until "effective" is passed?(I still need to check the "effective" filter)
17:52:34 <knikolla> vishakha: correct.
17:53:55 <vishakha> Bug is duplicate in such case. And I can update in the comment section about the implied roles?
17:54:08 <knikolla> yes
17:54:21 <cmurphy> thanks for tracking down the other bug vishakha
17:54:41 <knikolla> yes, thank you :)
17:54:57 <vishakha> yw :)
17:56:29 <knikolla> my lunch is here, so if there's nothing else, we can have a few minutes back.
17:56:40 <lbragstad> thanks all
17:57:14 <knikolla> #endmeeting keystone