17:00:13 <knikolla> #startmeeting keystone
17:00:14 <openstack> Meeting started Tue Feb 18 17:00:13 2020 UTC and is due to finish in 60 minutes.  The chair is knikolla. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:15 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:17 <openstack> The meeting name has been set to 'keystone'
17:00:34 <knikolla> o/
17:00:40 <gagehugo> o/
17:00:44 <vishakha> o/
17:03:34 <knikolla> alright, i guess that's all of today's crowd
17:04:02 <knikolla> #topic Last week before Rocky enters Extended Maintenance
17:04:20 <knikolla> title pretty much says it all.
17:04:38 <knikolla> This week will be the last week of upstream releases for our deliverables.
17:05:01 <knikolla> There's a few more outstanding backports stuck in CI failures, but overall it doesn't look too bad.
17:05:47 <lbragstad> o/
17:06:04 <knikolla> I'll keep an eye on those and make sure they merge and then propose releases.
17:06:30 <knikolla> anything else on the topic?
17:08:05 <knikolla> #topic L1 Duty Rotation
17:08:19 <knikolla> This week it's vishakha (thank you :) )
17:08:27 <knikolla> anyone wants to take next week?
17:08:40 <vishakha> yw :)
17:09:44 <gagehugo> I can probably take next week
17:10:15 <knikolla> gagehugo: awesome, thanks!
17:10:42 <knikolla> #topic Review Requests
17:13:15 <knikolla> #link https://review.opendev.org/#/c/697444/
17:13:42 <knikolla> is an osc patch for user options, has already gone through several cycles of feedback so should be pretty much ready
17:14:06 <knikolla> #link https://review.opendev.org/#/c/708255/
17:14:49 <knikolla> fixes a CI breakage and already has a +2
17:16:57 <knikolla> lbragstad: the second one should be super quick and you're the only other core that can approve it
17:18:07 <lbragstad> knikolla ack
17:18:28 <knikolla> lbragstad: thanks! :)
17:18:39 <knikolla> #topic Open Floor
17:18:55 <vishakha> I wanted to talk regarding this test case I have to add https://review.opendev.org/#/c/704271/
17:19:36 <vishakha> I can see the following error Could not map any federated user properties to identity values. Check debug logs or the mapping used for additional details. (Feb 18 07:45:18.686096 )
17:19:52 <vishakha> because of no "openstack_groups"  are being  added due to https://review.opendev.org/#/c/588211/43/keystone/federation/idp.py L239
17:20:11 <vishakha> https://storage.gra.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_5ef/704271/9/check/keystone-dsvm-py3-functional-federation-opensuse15-k2k/5ef29bc/controller/logs/screen-keystone.txt
17:20:30 <vishakha> The user doesn't belong to any group since the code is fetching groups from https://review.opendev.org/#/c/588211/43/keystone/api/_shared/saml.py  L61
17:20:54 <vishakha> I want to add this user to a group.
17:23:00 <vishakha> Could anyone guide me here?
17:23:17 <knikolla> can you add the user to the group as part of the setup of the test?
17:24:09 <vishakha> Thanks knikolla I can give it a try.
17:24:51 <knikolla> cool. ping me on -keystone if you're having further issues.
17:25:01 <vishakha> knikolla: sure
17:25:42 <vishakha> and Regarding this bug #link https://bugs.launchpad.net/keystone/+bug/1859759
17:25:44 <openstack> Launchpad bug 1859759 in OpenStack Identity (keystone) "Keystone is unable to remove role-assignment for deleted LDAP users" [Low,Confirmed] - Assigned to Vishakha Agarwal (vishakha.agarwal)
17:26:53 <vishakha> From the code I came to the conclusion that shadows for ldap users are created in nonlocal users table? If so then I can see  the use of Nonlocal user table is only used while creating user https://github.com/openstack/keystone/blob/master/keystone/identity/shadow_backends/sql.py#L152
17:27:39 <vishakha> we do not delete any user from this table?
17:28:17 <knikolla> IIRC, we don't. There is the keystone-manage mapping_purge command for that.
17:30:01 <vishakha> So as per cmurphy comment on the bug , we need to delete shadow users from the same table in mapping_purge command?
17:31:43 <knikolla> I think it's a bit more complex than that. mapping_purge deletes all entires, regardless of if they still exist or not. That isn't an issue because the ids are predictable, so role assignments for a user will persist between mapping_purges, making it somewhat idempotent.
17:32:39 <knikolla> So it's more of a question of deleting nonexistent users and only their role assignments
17:33:40 <vishakha> okay. I think I need to look into more details.
17:33:49 <vishakha> thanks
17:35:38 <knikolla> vishakha: this is a very old patch that i abandoned a while ago with the general idea https://review.opendev.org/#/c/487579/
17:36:28 <knikolla> almost 3 years old, time flies
17:36:45 <vishakha> thanks a lot for this
17:37:21 <knikolla> you're welcome :)
17:40:04 <knikolla> alright, thanks everyone!
17:40:08 <knikolla> #endmeeting