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