16:00:00 #startmeeting keystone 16:00:05 Meeting started Tue Dec 11 16:00:00 2018 UTC and is due to finish in 60 minutes. The chair is lbragstad. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:06 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:08 The meeting name has been set to 'keystone' 16:00:18 #link https://etherpad.openstack.org/p/keystone-weekly-meeting 16:00:19 o/ 16:00:49 o/ 16:02:00 we'll give folks a few more minutes to join 16:02:32 * kmalloc snoozes. 16:02:40 * kmalloc keeps hitting the snooze button. 16:02:50 * kmalloc waits for meeting to get going. 16:03:03 o/ i'm in another meeting this hour :( 16:03:10 cmurphy: boo-urns 16:04:03 2x meetings = 2x fun 16:04:22 o/ 16:04:30 gagehugo: i hear you like meetings in your meetings.... 16:04:47 alright - we have a pretty light agenda anyway, so we can get started 16:04:59 #topic Previous Action Items 16:05:16 o/ 16:05:18 last week we talked about documenting the admin role deletion discussion we talked about 16:05:23 i guess that was me 16:05:26 i haven't done that yet 16:05:37 ack 16:05:58 fwiw - i've never really kept track of action items from previous meetings, explicitly 16:06:03 so this is kinda new for me, too 16:07:32 cmurphy feel free to ping if you need a hand 16:07:54 lbragstad: if you have free cycles feel free to take it ;) otherwise i'll get to it soonish 16:08:42 i'll put a reminder on my calendar for the end of the week 16:09:06 hopefully i can chew threw some of my work by then and free up some cycles 16:09:38 if you haven't taken a crack at it by friday-ish, i'll see what i can at least get started in review 16:10:01 anything else on this? I assume nothing really changed in the last week 16:10:13 not from me 16:10:21 ack - moving on then 16:10:26 #topic Release Schedule 16:10:39 as noted in the friday newsletter 16:10:50 #info we're just under a month away from specification freeze 16:11:06 and a couple weeks after that we have feature proposal freeze 16:11:37 just a friendly psa if your name is on something feature-wise and it still isn't in review 16:12:08 keep in mind zuul and gate resources could very well be a big factor this cycle 16:12:33 #link https://releases.openstack.org/stein/schedule.html 16:12:46 on spec freeze 16:12:48 #link https://review.openstack.org/#/c/624162/ 16:13:07 that was highlighted as something we should implement scaffolding for - resource options outside of user 16:13:14 ok 16:13:39 it proposes no new options just implementing the underlying support so we can add Resource Options to projects/domains/roles/etc 16:14:05 so - this isn't going to impact anything externally, yet 16:14:15 it will add the resource_options key in the responses 16:14:20 but it will be an empty list 16:14:26 no external impact beyond that 16:14:45 functionally - it should be the same 16:14:49 yep. 16:15:02 it's going to be a big set of DB migrations 16:15:29 and some minor code that mirrors the user bits and some empty "here is where Resource Options go" files. 16:16:13 i don't think we have a formal process of approving/socialize specifications after specification proposal freeze (unlike spec freeze) 16:16:29 does the team have thoughts on how we handle those cases? 16:16:34 yeh we usually ask for an exception 16:16:49 the only reason i proposed this as a spec vs strictly a bug was for the comment bits 16:16:59 however this is a little odd since it's no functional changes 16:17:12 i can see it being a feature, so a spec makes sense 16:17:18 yeah. 16:17:25 i think that's a within-team thing, not something we have to ask someone else for 16:17:34 i don't think many other teams even have spec proposal freeze 16:17:40 right. sorry was more we ask for a spec-exception from the team :P 16:17:48 e.g. from ourselves 16:17:50 we haven't hit that deadline, yet 16:17:56 yeah so i think it's on lbragstad to make the final call :) 16:18:01 hehe 16:18:03 yup 16:18:09 i can go both ways... here's my perspective 16:18:21 it's a formal deadline and we bother adding it to a formal release schedule 16:18:34 which makes me feel like we should formally use exceptions 16:18:45 the reason for this spec was based upon convos @ the summit 16:18:59 on the other hand... we really just use it to push people to not wait until the last minute 16:19:12 otherwise it might not have been bubbled up for any number of cycles 16:19:15 how much work is this going to be to implement? 16:19:21 mostly DB migrations 16:19:26 adding tables 16:19:33 and some sql-model joins to load 16:19:46 my worry is that we have a ton of work on our plate already and it would be nice if we keep some focus 16:19:47 most of the code exists for users, it's just replicating the pattern for the other resource types 16:20:03 this can be deferred 16:20:08 it is proposed for comment. 16:20:23 kmalloc maybe backlog if we can't get to it this cycle? 16:20:33 i would hate to lose the context from the summit 16:20:35 eh, i'll just repropose it for next cycle 16:20:41 it'll sit open. 16:20:53 that works, too 16:20:56 i largely view the backlog as a place where specs go to die 16:21:00 at the meoment 16:21:12 s/meoment/meowment/moment 16:21:43 and we *just* gave cmurphy an action to write a backlogged spec :) 16:21:48 :P 16:21:49 sorry 16:22:00 really the backlog is bad atm and needs to be cleaned up 16:22:00 we put the jwt spec in the backlog and it is still alive 16:22:08 it's the exception 16:22:13 really 16:22:28 * kmalloc is going from past experience 16:22:41 yeah - maintaining the backlog is a process thing that sometimes gets forgotten 16:22:53 maybe we should make it a regular thing at the ptg 16:23:01 i would support that 16:23:02 go through the list and promote or kill 16:23:07 ^ that's what i always envisioned 16:23:29 we always have a pretty good idea of what we're going to be doing, but specs linger 16:23:40 or do a kill-spec pass at spec-freeze 16:23:43 each cycle 16:23:47 i'd love it if we just addressed them before we got on the plane to go home 16:24:09 it's less important to promote, it is important to determine if the specs should be killed 16:24:15 so i would almost do a promote @ the ptgf 16:24:18 (but people sometimes have to leave early, things come up, networks deteriorate, etc...) 16:24:21 and kill at some other point in the cycle 16:24:44 that way we are worried about defining the work for the next cycle @ ptg/summit 16:25:17 and we can play cleanup like we do say office hours one day... or bug triage. create a list of lingering non-promoted specs and do a pass of "kill-or-consider for next cycle" 16:25:31 kill is more "comment on a review to delete spec from backlog, imo" 16:25:41 promote may or may not happen even if we keep it 16:25:49 * kmalloc gets off soapbox. 16:26:10 ok - i think we'll just need to make sure we schedule time to do a couple things on this front at the next PTG 16:26:24 first is probably cleaning things up 16:27:01 second would be making sure try and leave the Train PTG with a better idea of what we plan to do for that release - represented by the specs repo 16:27:11 third - refine the process and make sure we stick to it? 16:27:36 sounds like a decent plan 16:27:51 wfm 16:28:04 cool 16:28:13 anyone else have anything related to this? 16:28:53 #topic Outstanding Reviews 16:29:11 last week we brought up a bunch of reviews that needed eyes 16:29:17 the only two that didn't merge were 16:29:26 #link https://review.openstack.org/#/c/604201/ 16:29:34 #link https://review.openstack.org/#/c/615384/ 16:29:41 and 16:29:42 #link https://review.openstack.org/#/c/605043/ 16:29:51 i'm suffering off-by-one errors today 16:30:07 615384 is ready now 16:30:18 thanks cmurphy 16:30:27 does anyone have reviews that need attention? 16:30:42 the ksa one just needs eyes to make sure people are happy with it 16:30:50 it wont land until the SDK functional test is green 16:31:09 yeah - i saw that 16:31:16 the -2 is to hold it until SDK is ready 16:31:31 please ignore the -2 on that front. real review of the code would be appreciated 16:31:34 #link https://review.openstack.org/#/c/604926/ 16:31:38 right? ^ 16:31:45 barring the functional test, it's pretty good. 16:31:58 yeah 16:32:00 that one 16:32:08 ok - i'll keep tabs on it 16:32:42 i'll take a closer look at the ksa patch once the functional tests are squared away for sure 16:32:57 right now looking at the KSA code would be good. 16:33:19 because the functional tests may or may not change it, but if there is something you don't like about it... it's doing semaphore/shared state work 16:33:29 we should address that before a ton goes into the functional tests 16:33:40 as the functional tests are based upon the interface defined in the KSA patch 16:34:04 i'm kinda wondering if the process of functional testing will make improvements on that front or not 16:34:11 i don't think so 16:34:36 ok 16:34:38 it will be minor if anything 16:35:07 barring a major issue. but we've done iterations on the semaphore code. 16:35:21 i think we have shaken out the worst of the "the interface doesn't work" bits. 16:35:27 or "can't work" 16:35:34 sounds good 16:35:56 does anyone else have things up for review that need attention? 16:36:48 * lbragstad raises his hand sheepishly 16:36:57 y'all are probably gonna hate me for a while... but 16:37:08 i wont. 16:37:13 i'm going to be on vacation :P 16:37:36 * kmalloc announces vacation starting next week and will be back middle-ish of January. 16:38:00 #link https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:master+topic:implement-default-roles 16:38:08 it's a lot - but there are a few easier series in there (endpoints, services, regions) 16:38:18 and likely will have another week off between january 14 and fed 15. 16:38:21 feb* 16:38:24 kmalloc ack 16:38:42 i also have some code up for jwt that'd i would like to get some eyes on https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:master+topic:bp/json-web-tokens 16:38:53 (specifically the certs and whatnot) 16:38:54 i'll be doing what i can to review it... you reviewed the flask stuff 16:39:08 :) 16:39:10 but... once vacation hits i really need to unplug 16:39:26 so i might check in and say hi, but the plan is to not look at openstack stuff for almost a month 16:40:16 lbragstad: also...unless you hit ~100 patches ... it isn't as bad as flask conversion :P 16:40:19 fwiw - the implement-default-roles patches are broken into linear series 16:40:21 and we all suffered through that 16:41:00 they usually start by implementing system reader -> system member -> system admin -> domain users -> project users 16:43:01 if anyone has questions on that stuff, just let me know 16:43:04 oh. i'm doing a final pass on JWT spec 16:43:11 if nothing looks bad i'm +1ing it 16:43:13 +A. 16:43:20 unless someone else wants another pass at it 16:43:20 cool - sounds good 16:43:32 but warning, that is at the top of my list today. sooooooo 16:43:33 i think the big thing was that we wanted to double check with simo 16:43:35 speak now 16:43:49 yeah i think really the configurable crypto was the big deal 16:43:53 and multi-crypto support 16:43:55 for rotation 16:44:00 and hrybacki got feedback from him that i added in a follow-on 16:44:03 yeah 16:44:17 crypto-agility is important. 16:44:21 o/ -- thanks lbragstad 16:44:26 but straight forward as an add-on 16:44:30 hrybacki no problem 16:45:04 alright - looks like we're safe to move on 16:45:08 #topic open discussion 16:45:31 floor is open if anyone has anything 16:47:26 alright - thanks for coming 16:47:38 reminder we have office hours in 15 minutes if you're available 16:47:55 o/ 16:47:57 #endmeeting