17:00:14 <cmurphy> #startmeeting keystone
17:00:15 <openstack> Meeting started Tue Jan 28 17:00:14 2020 UTC and is due to finish in 60 minutes.  The chair is cmurphy. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:16 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:18 <openstack> The meeting name has been set to 'keystone'
17:00:25 <vishakha> o/
17:00:29 <gagehugo> o/
17:00:30 <cmurphy> #link https://etherpad.openstack.org/p/keystone-weekly-meeting agenda
17:00:39 <knikolla> o/
17:01:31 * lbragstad is double-booked for meeting
17:03:07 <cmurphy> #topic Reminder: spec freeze in 2 weeks
17:03:44 <cmurphy> reminder that the spec freeze is coming up and feature propoal freeze isn't far behind
17:03:59 <cmurphy> we haven't moved forward on any of the open specs
17:04:20 <vishakha> I Checked the gate job keystone-dsvm-grenade-multinode do checks rolling upgrade
17:04:52 <knikolla> i’ll review the open specs this afternoon
17:04:52 <vishakha> But adding this to gate will slow down it
17:05:28 <cmurphy> vishakha: so it *does* do rolling upgrades? i thought it didn't?
17:05:47 <cmurphy> knikolla: https://review.opendev.org/698951 has some questions from gyee
17:06:11 <cmurphy> lbragstad: gagehugo please review https://review.opendev.org/698951 and https://review.opendev.org/698950
17:06:30 <vishakha> According to the script https://github.com/openstack/grenade/blob/master/projects/10_keystone/upgrade.sh
17:06:35 <knikolla> cool. will respond in the review :)
17:06:47 <vishakha> it perfroms keystone-manage db-sync
17:07:02 <cmurphy> vishakha: it needs to do db_sync expand, migrate, and contract in separate stages
17:07:10 <cmurphy> db_sync all in one go is not a rolling upgrade
17:07:34 <cmurphy> vishakha: i will try to find you some documentation to help
17:07:46 <gagehugo> cmurphy: done
17:07:59 <cmurphy> thanks gagehugo
17:09:38 <cmurphy> any other questions or comments on that topic? vishakha i'll find docs after the meeting
17:09:57 <vishakha> cmurphy: Doesn't the code goes for https://github.com/openstack/keystone/blob/d8b49d802fa2dcfda97067b54b94a57ab2a35ee6/keystone/common/sql/upgrades.py#L226
17:10:15 <vishakha> when no parameter s are passed in keystone-manage db_sync
17:12:08 <cmurphy> vishakha: a rolling upgrade is when you have a highly-available active-active keystone deployment and each keystone server is upgraded one at a time so that the effect for end users is there is no downtime, the consequence of orchestrating it like this is the database schema can't change all at once since the keystone servers are running different versions of the code at any given time
17:12:53 <vishakha> cmurphy: Thanks. I will take another look
17:13:02 <cmurphy> cool
17:13:37 <cmurphy> #topic l1 duty rotation
17:14:00 <cmurphy> last week was vishakha, vishakha any interesting bugs or support requests to discuss?
17:14:31 <vishakha> There wasn't many bugs last week.
17:14:35 <vishakha> #link https://bugs.launchpad.net/keystone/+bug/1860478
17:14:36 <openstack> Launchpad bug 1860478 in OpenStack Identity (keystone) "fetching role assignments should handle domain IDs in addition to project IDs " [Low,Triaged]
17:14:46 <vishakha> I saw the discussion regarding this on irc
17:15:32 <vishakha> After seeing the logs the , fixing project parameter not to take domain  be a valid fix?
17:15:48 <vishakha> *domain_id
17:16:03 <vishakha> I was thinking to resolve this
17:18:34 <cmurphy> it's part of the roles api and it's ambiguous whether changing the behavior could be construed as a bugfix or a breaking change, so we were leaning toward making the role assignment api better able to handle the issue instead of changing the roles api
17:19:46 <vishakha> So the functionality of passing a domain id in to the project parameter can be considered as right behaviour?
17:20:54 <cmurphy> imo it's technically correct because a domain is a type of project, it's also very longstanding behavior so it would be risky to change it
17:21:04 <vishakha> okay
17:21:12 <vishakha> makes sense
17:21:34 <cmurphy> i think that's where we arrived in the irc discussion, still open for debate though :)
17:22:14 <vishakha> #https://bugs.launchpad.net/keystone/+bug/1859759
17:22:14 <openstack> Launchpad bug 1859759 in OpenStack Identity (keystone) "Keystone is unable to remove role-assignment for deleted LDAP users" [Undecided,Incomplete]
17:22:33 <vishakha> seems like this is keystoneclient side issue as per the comments
17:24:56 <cmurphy> looks like it, if curl is doing the right thing
17:25:46 <vishakha> I will add bug in keystoneclient for it.
17:26:33 <vishakha> *openstackclient
17:26:46 <cmurphy> vishakha: if possible it would be good to reproduce the issue yourself to make sure
17:27:43 <vishakha> yes after reproducing it.
17:28:27 <cmurphy> gagehugo: is up for this week, i can take the week after
17:28:36 <gagehugo> yup
17:29:31 <cmurphy> sweet
17:29:37 <cmurphy> #topic review requests
17:29:53 <cmurphy> looks like some requests from vishakha and gagehugo
17:30:11 <cmurphy> i will take another look at the openstack_groups one today, it was looking good last time i checked
17:30:36 <knikolla> I have a quiet afternoon, so I will take a look as well.
17:30:51 <cmurphy> perfect
17:31:13 <cmurphy> that one is https://review.opendev.org/588211
17:31:26 <cmurphy> knikolla: can you also review https://review.opendev.org/#/c/699013/ please?
17:32:25 <knikolla> Sure. I’m not too familiar with the cadf part of the codebase, but never too late to learn.
17:32:40 <cmurphy> ++
17:32:47 <cmurphy> any other review requests?
17:34:15 <cmurphy> #topic open floor
17:34:19 <cmurphy> anything else to discuss?
17:34:53 <vishakha> #link https://review.opendev.org/#/c/702374/
17:35:16 <vishakha> cmurphy: I saw other projects dropping this too.
17:36:00 <cmurphy> vishakha: okay lgtm
17:36:15 <vishakha> cmurphy:  Thanks
17:37:54 <cmurphy> okay thanks everyone
17:37:56 <cmurphy> #endmeeting