16:00:23 <cmurphy> #startmeeting keystone
16:00:24 <openstack> Meeting started Tue Apr 16 16:00:23 2019 UTC and is due to finish in 60 minutes.  The chair is cmurphy. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:25 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:29 <openstack> The meeting name has been set to 'keystone'
16:00:34 <vishakha> o/
16:00:38 <cmurphy> #link https://etherpad.openstack.org/p/keystone-weekly-meeting agenda
16:00:42 <cmurphy> hiya
16:01:05 <cmurphy> please go ahead and add things to the agenda
16:01:15 <lbragstad> o/
16:02:09 <gagehugo> o/
16:03:51 <cmurphy> #topic Summit/PTG planning
16:04:27 <cmurphy> I created a team dinner poll
16:04:34 <cmurphy> #link https://framadate.org/BHNNU9S3f9N3lasH team dinner poll
16:04:57 <cmurphy> please fill it out :)
16:05:26 <kmalloc> i wont be there =/
16:05:32 <cmurphy> :'(
16:05:36 <kmalloc> have food / drink for me!
16:06:27 <cmurphy> will do :)
16:07:17 <cmurphy> I'm looking forward to hanging out with the team, without the PTGs it feels like forever since we were last together
16:07:25 <vishakha> kmalloc:  would not be able to meet you :(
16:07:31 <lbragstad> ++
16:08:22 <gagehugo> only 2x a year now
16:09:28 <cmurphy> might want to think about midcycles again
16:09:59 <cmurphy> that's all I had on that
16:10:04 <cmurphy> #topic Cycle schedule
16:10:22 <kmalloc> a virtual midcycle would be a good thing to consider as well
16:10:26 <cmurphy> ++
16:10:37 <kmalloc> just help with the avoid travel but dedicate time with video/face-to-face work.
16:11:21 <kmalloc> high-bandwidth comms is what matters, not physical presence unless most people are all in one location.
16:11:47 <cmurphy> aligning timezones would be a little tricky though
16:11:56 <vishakha> may be remote PTG for those who cannot join?
16:12:23 <kmalloc> I'm inclined to say if we plan it out, timezones can be worked around. I'd personally have no issue doing night-work.
16:12:40 <kmalloc> since it's dedicated time(s) for this and not recurring like a weekly-meeting
16:12:57 <gagehugo> I can be flexible as well with times for this
16:13:20 <cmurphy> awesome :)
16:13:21 <kmalloc> it would be ~2-3 days of adjusted schedule at most.
16:13:43 <cmurphy> well let's get past this upcoming in-person ptg and then we can start planning out a virtual midcycle
16:13:48 <kmalloc> wfm.
16:14:13 <lbragstad> "get past" == "survive", right?
16:14:18 <gagehugo> yes
16:14:20 <cmurphy> lol yes
16:15:03 <cmurphy> regarding the milestone schedule, does anyone have feedback about the deadlines we set for last cycle? spec freeze, feature freeze, etc?
16:15:28 <cmurphy> since train is already started we kind of have to start planning that out now rather than waiting to do it at the ptg i think
16:15:31 <lbragstad> #link https://releases.openstack.org/rocky/schedule.html rocky schedule for reference
16:15:45 <lbragstad> #link https://releases.openstack.org/stein/schedule.html stein schedule for reference
16:15:55 <cmurphy> thanks lbragstad
16:16:17 <lbragstad> was the only difference between rocky and stein that we bumped feature freeze back to milestone 3?
16:17:06 <cmurphy> it looks like it
16:17:21 <cmurphy> stein was a longer cycle though, which might have been why
16:17:42 <lbragstad> yeah.. i think we were also a bit leary of another situation like we had in queens
16:18:14 <lbragstad> but zuul has stabilized since then
16:18:46 <cmurphy> it definitely wasn't as bad this time
16:19:06 * lbragstad is thankful for that
16:19:58 <lbragstad> i know a lot of what i was working on crept past feature freeze and ultimately required subsequent RCs (apologies)
16:20:29 <kmalloc> eh. it wasn't bad.
16:21:07 <cmurphy> it was useful to have those changes in, but we might want to try to avoid it next time and treat the RC period as a real freeze
16:21:19 <lbragstad> ++
16:21:50 <lbragstad> my hope is that we can clean up the remaining scope work and default roles work early in train
16:21:56 <cmurphy> ++
16:22:05 <lbragstad> so we don't have a mad rush for that kind of stuff
16:22:17 <cmurphy> what about spec proposal freeze/spec freeze? should we leave those at milestones 1 and 2 or shift them?
16:22:44 <kmalloc> i prefer that work being in Stein so we can work on in being useful in train
16:22:59 <cmurphy> ++
16:23:00 <kmalloc> if it hadn't landed, i don't think we'd be lined up for real use in the release beyond train.
16:23:17 <kmalloc> and semi-used in train. we run ~2 cycles ahead of feature use.
16:23:57 <gagehugo> if we follow the milestone then spec freeze will be june 03-07 for train
16:24:01 <lbragstad> re: spf and sf - i think exceptions for specs has been pretty rare
16:24:30 <lbragstad> specifically over the last couple releases, that could be an indication that the dates are working(?)
16:24:42 <cmurphy> that makes sense
16:25:15 <kmalloc> I think the dates work.
16:25:25 <cmurphy> gagehugo: spec proposal freeze would be that week, spec freeze wouldn't be until jul 22-26
16:25:41 <gagehugo> oh yeah, I forgot a word
16:26:09 <gagehugo> so ~1 month post PTG for spec proposals
16:26:56 <gagehugo> should be fine imo, unless there's a need for more time
16:27:32 <cmurphy> my issue was always that it feels like the spec freeze is real close to feature freeze and if you leave things to the last minute (which i do) then you're gonna be overworked at the end of the cycle
16:27:55 <cmurphy> but obviously having the spec freeze date at m-2 doesn't actually mean you can't start working on the code sooner
16:28:04 <lbragstad> ++
16:28:28 <cmurphy> so, sounds like the dates are fine but i encourage people (myself included) to start coding work early
16:29:00 <cmurphy> anything else to add on this topic?
16:29:18 <ayoung> sounds good
16:30:32 <cmurphy> speaking of specs
16:30:39 <cmurphy> #topic spec review
16:31:33 <cmurphy> we already have some specs proposed so it would be good to start looking at them in advance of the ptg
16:31:44 <cmurphy> #link https://review.openstack.org/650126 Repropose unfinished Stein specs for Train
16:31:53 <cmurphy> ^ that i think is an easy one to merge nowish
16:33:13 <cmurphy> there are quite a few more that are being worked on
16:33:22 <cmurphy> #link https://review.openstack.org/#/q/is:open+project:openstack/keystone-specs Open specs
16:34:08 <cmurphy> I linked a bunch more in the agenda, does anyone want to highlight any that are ready or need discussion?
16:34:55 <cmurphy> there are some old ones that look interesting
16:36:22 <cmurphy> ayoung: lbragstad there's a -1 on https://review.openstack.org/612099 but i think it's something we agree we want to move toward, can we get that resolved?
16:36:47 <lbragstad> yeah - i can take a look
16:38:16 <cmurphy> thanks
16:38:32 <cmurphy> there's also a bunch of cruft in the ongoing and backlog specs that we should try to clean out or promote
16:38:40 <cmurphy> #link http://specs.openstack.org/openstack/keystone-specs/specs/keystone/backlog/ Backlog
16:38:48 <cmurphy> #link http://specs.openstack.org/openstack/keystone-specs/specs/keystone/ongoing/ Ongoing
16:39:38 <cmurphy> please have a look and we can discuss them more at the ptg
16:40:13 <cmurphy> #topic open reviews
16:40:22 <cmurphy> anyone want to highlight reviews that are ready?
16:40:51 <kmalloc> https://review.openstack.org/#/c/347972/ this one is worth it
16:41:12 <cmurphy> :)
16:41:48 <cmurphy> i started going through the review queue back to front and abandoning things that weren't applicable any more and polishing the low hanging fruit
16:42:07 <lbragstad> ++
16:43:20 <kmalloc> That one doesn't join everything. btw
16:43:26 <kmalloc> but it's a good start
16:43:39 <cmurphy> kmalloc has thoughts about https://review.openstack.org/441652 updating endpoints via bootstrap, anyone else want to weight in?
16:43:45 <lbragstad> i wonder if 347972 should have a release note
16:44:21 <ayoung> Yeah.  So, I think most predictable IDs are going to work as is.  THe issue that kmalloc raises is with immutable, which is an issue for projects
16:44:35 <cmurphy> lbragstad: to highlight the performance improvement?
16:44:56 <ayoung> I think we need a unified approach to multisite.  That is going to include service catalog.
16:44:57 <lbragstad> cmurphy yeah - probably not a huge deal though
16:45:17 <cmurphy> ¯\_(ツ)_/¯
16:46:02 <ayoung> The general flow I think is going to be something like this:
16:46:14 <ayoung> we have a central set of services.  Maybe just Keystone and horizon
16:46:36 <ayoung> Keystone needs to be able to talk to the various sites, at differing levels of openstack version
16:46:54 <ayoung> so, the service catalog in the center needs to identity endpoints at the sites
16:47:01 <ayoung> but, I think only that
16:47:27 <ayoung> if IDs are the same, you can use a token from the center at the sites.  Otherwise, something like K2K would be necessary
16:48:10 <ayoung> that is the general pattern I am seeing among customers today, and all the reviews and discussions I am working on are around those use patterns. ANyone else seeing this?
16:50:21 <lbragstad> would setting a project ID be limited to system administrators?
16:50:41 <lbragstad> even if domain users are allowed to create projects namespaced to their domain, do we expect them to set IDs?
16:50:48 <kmalloc> I would like to see it as a SystemScope locked action
16:50:55 <kmalloc> to start*
16:51:17 <kmalloc> IDs are intended to be generated/managed by keystone
16:51:33 <kmalloc> but a cloud-admin might have access to the DB and could update it directly if needed
16:51:37 <cmurphy> i thought we were making project IDs predictable, not settable?
16:51:40 <kmalloc> a domain admin has no real need for that.
16:51:44 <cmurphy> domain IDs are settable now
16:51:46 <kmalloc> i would rather see IDs predictable
16:51:56 <kmalloc> than explicitly settable though*
16:51:57 <lbragstad> my concern and the concerns people expressed in the past is that this is changing the API in order to make up for database replication issues
16:52:09 <kmalloc> hence System Scope locked.
16:53:24 * lbragstad needs to go back and read the specification
16:53:49 <cmurphy> skimming https://review.openstack.org/#/c/612099/ i only see it talking about predictability
16:54:16 <kmalloc> as it should
16:54:28 <kmalloc> i was commenting that if it becomes settable, it needs to be system-scope only
16:54:57 <cmurphy> i don't think there should be a need for it to be settable, ayoung ?
16:55:11 <cmurphy> 5 minute warning
16:55:44 <lbragstad> also - it looks like projects aren't addressed in that specification
16:55:53 <lbragstad> but everything else is
16:56:51 <cmurphy> oh hmm
16:58:00 <ayoung> yep.
16:58:21 <ayoung> there are a few ways we can sync IDs.  Predictable is only one of them
16:59:00 <ayoung> explicitly settable is the other.  I can't think of another alternative
16:59:30 <lbragstad> ayoung what's the reason for projects having their own specification for this problem?
16:59:45 <ayoung> lbragstad, cuz its HARD
16:59:48 <cmurphy> project names are mutable :(
16:59:49 <lbragstad> https://review.openstack.org/#/c/612099/4/specs/keystone/ongoing/predictable-ids.rst@68
16:59:53 <lbragstad> ah
17:00:21 <cmurphy> okay let's finish this in #openstack-keystone
17:00:23 <lbragstad> i'll take a deeper look at this today
17:00:26 <cmurphy> #endmeeting