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