16:01:37 #startmeeting keystone 16:01:38 Meeting started Tue Feb 5 16:01:37 2019 UTC and is due to finish in 60 minutes. The chair is lbragstad. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:01:39 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:01:41 The meeting name has been set to 'keystone' 16:01:51 cmurphy thanks for covering 16:01:54 #link https://etherpad.openstack.org/p/keystone-weekly-meeting 16:01:56 agenda ^ 16:02:24 relatively short schedule today 16:02:36 o/ 16:02:43 o/ 16:02:45 o/ 16:02:57 o/ 16:04:21 #topic Previous action items 16:04:30 i think the only thing we had from last week was the technical vision statement 16:04:40 #link https://etherpad.openstack.org/p/keystone-technical-vision-notes 16:05:01 I think that was my action but I don't think I'll get to it until a little closer to ptg 16:05:10 sounds good 16:05:26 ++ 16:05:28 it is redundant to have this on the weekly meeting? 16:05:49 i don't want to keep bugging you if we know it's not going to happen until we get closer to the PTG 16:05:56 yeah i don't think i need a weekly reminder 16:05:59 ack 16:06:00 it's on my trello board 16:06:21 that wraps up action items then 16:06:32 #topic reviews that need attention 16:06:40 does anyone have reviews they need eyes on? 16:07:14 I want to call attention to imus's (outreachy intern) patch https://review.openstack.org/630301 esp kmalloc 16:07:22 * kmalloc nods. 16:07:28 it's on my short list. 16:07:36 i've seen the iterations on it 16:07:39 it's been looking good. 16:07:59 i figured today was where it was going to get full review from me. 16:08:11 oh - nice 16:09:07 I also would like some passing "does this look ok" eyes on https://review.openstack.org/#/c/605043/ it's something we are working on a functional test for 16:09:18 but i really would like feedback early if we need to change interfaces on 16:09:35 it will greatly improve SDK and some consumers of SDK. 16:10:03 * cmurphy adds to reading list 16:10:11 added 16:10:17 i think i forgot about it since there is a -2 16:10:32 yeah the -2 is very much procedureal 16:11:08 we need a functional test, it's not been straight forward because rate-limiting is never straightforward, especially multi-threaded ratlimiting 16:11:37 if we're ok with the interface, we'll get that test up and running so we can land it 16:12:48 any other patches we want to draw attention to? 16:13:51 i still have a bunch up - https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:master+topic:implement-default-roles 16:13:58 but i appreciate everyone that's been taking time to review those 16:14:01 i know it's a lot 16:14:30 cmurphy: +2/+A on imus's patch 16:14:35 cmurphy: it's good. 16:14:44 https://review.openstack.org/#/c/614549/14 could use some eyes, too (but all the prerequisite patches merged) 16:14:52 kmalloc: woot 16:15:38 cmurphy: i also just fixed the minor pep8 issue on the followup patch, it might be ready to land as well. 16:15:45 cmurphy: on my list to review today too. 16:15:53 kmalloc: um read the comments on that one, it should have been abandoned 16:16:10 it's due to a git learning experience 16:16:27 ah 16:16:29 nvm 16:17:12 cmurphy: abandoned then. 16:19:29 anything else review-wise? 16:20:57 i would like to note that some of the scope work might force us to relook at https://review.openstack.org/#/c/624794/ 16:21:24 i stumbled across that a couple months ago in order to get some of the new system scope policies to work with tempest 16:21:58 (tempest has a setting where if a token is domain-scoped, it assumes the user is a cloud administrator) 16:22:47 my question is if we should continue reinforcing that idea if gmann is already working on system-scope support in tempest auth clients 16:23:18 probably not, we should probably have tempest do it properly 16:23:25 ++ 16:23:38 i don't think i understood why that assumption was made 16:23:59 so i want to make sure i understand why the fence was put up before we rip it down 16:24:26 it could have been something related to the original approach with is_admin_project? but it's not clear to me if that's the case 16:25:16 either way - i wanted to float it by the group so that you're aware of it if you're reviewing https://review.openstack.org/#/c/605485/18 16:26:06 #topic open discussion 16:26:11 floor is open 16:26:28 I'm on vacation tomorrow-sunday, probably not 100% afk but won't plan on being around much 16:26:50 enjoy the time off cmurphy 16:27:07 somewhat related to reviews: just a reminder that the gate has been super flaky 16:27:17 cmurphy: don't come around if you're on vacation ;) enjoy time off 16:27:27 cmurphy: it's not that we don't want you here, you deserve time off! 16:27:36 have a great time cmurphy 16:28:51 For https://bugs.launchpad.net/keystone/+bug/1601910, as this is invalid now. 16:28:52 Launchpad bug 1601910 in OpenStack Identity (keystone) "drop support for EPHEMERAL user type in mapping" [Medium,In progress] - Assigned to Vishakha Agarwal (vishakha.agarwal) 16:29:10 based on comment #12, i would say so 16:29:33 Shouldn't we update the document too? 16:29:38 but i'm curious why it was opened in the first place, if the original reporter had an idea for removing ephemeral that we're not seeing 16:30:07 As user_type is not set anywhere? 16:30:16 kmalloc: ^ 16:30:47 uhm. 16:30:53 i don't remember the context there :P 16:30:57 even reading the comments. 16:31:20 i *think* it was just "drop ephemeral users in favor of shadow users* 100% 16:31:55 so uh, sure, close it invalid? 16:31:58 if type is ephemeral does that cause the shadow user not to be created? 16:32:17 i think so 16:32:23 or that was the intent 16:32:27 hmm 16:32:59 answer hazy, ask again later 16:33:28 the down side is shadow users leave records in the db. 16:33:35 if you have a lot of churn, it could bloat the db 16:33:47 (please don't have a lot of churn in your identity system) 16:34:20 realistically we should just drop ephemeral users and promote everything to the shadow user implementation (or new form) 16:34:24 it should not be api breaking 16:34:30 this is housekeeping internal to keystone 16:34:39 well - the mapping would break, right? 16:34:50 okay i think i was thinking that "ephemeral" users will shadow users as opposed to local users which are actually in the local_user db 16:34:56 ah 16:34:59 maybe that's it? 16:35:34 unfortunately i've stacked a long vacation on top of a "haven't touched this code in forever"... so I am guessing at intent... i should stop guessingh 16:35:57 because ephemeral is set in the mapping, so if we remove that then we're changing the behavior of the mapping if a deployment is using an ephemeral mapping? 16:36:09 sounds like in either case we may want to keep support for ephemeral users 16:36:23 ok 16:36:45 ok . So I think I need not to touch this thing 16:37:10 i think this ties in with the whole shadow user deep dive we want to do 16:38:42 anything else for open discussion? 16:38:52 lbragstad: ++ def. part of the shadow user deep dive 16:39:04 * kmalloc wishes Ron, Steve, and dstanek were still working on this 16:39:21 yeah, me too 16:40:10 looks like that's about it for today 16:40:18 i appreciate everyone being here 16:40:33 reminder that office hours starts in about 20 minutes if you're around 16:40:40 thanks! 16:40:43 #endmeeting