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