18:02:44 #startmeeting keystone 18:02:45 Meeting started Tue Apr 14 18:02:44 2015 UTC and is due to finish in 60 minutes. The chair is morganfainberg. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:02:46 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:02:48 The meeting name has been set to 'keystone' 18:02:52 laaaaaaaaaaaaagggggggggggggg 18:03:15 Ok going to do a rollcall vote, please respond if you're here for the keystone meeting. after 2-3 meetings will prune the ping list 18:03:21 morganfainberg, I hear they have much faster wireless in the Cafes in NYC 18:03:33 #startvote Rollcall? here 18:03:34 Begin voting on: Rollcall? Valid vote options are here. 18:03:35 Vote using '#vote OPTION'. Only your last vote counts. 18:03:40 #vote here 18:03:41 #vote here 18:03:41 #vote here 18:03:45 #vote here 18:03:46 #vote here 18:03:47 #vote here 18:03:50 #vote here 18:03:51 #vote here 18:03:56 this is like the PTL vote where there was only one option 18:03:56 #vote not_here 18:03:56 stevemar: not_here is not a valid option. Valid options are here. 18:04:02 #vote here 18:04:02 #vote here 18:04:04 #vote here 18:04:14 bknudson, nothing stopped you from running for PTL ;) 18:04:16 #vote no lo contendere 18:04:17 ayoung: no lo contendere is not a valid option. Valid options are here. 18:04:21 #vote here 18:04:23 #vote here 18:04:27 #vote for Hilary 18:04:28 gyee: for Hilary is not a valid option. Valid options are here. 18:04:32 LOL 18:04:33 #vote here 18:04:33 sheeet 18:04:47 #vote here 18:04:47 20 more seconds. 18:04:49 #vote for Pedro 18:04:50 ayoung: for Pedro is not a valid option. Valid options are here. 18:04:52 #vote here 18:04:54 vote monster-raving-looney-party 18:04:59 #vote here 18:05:01 #vote here 18:05:16 henrynash, this is Keystone. That would just be redundant. 18:05:30 #endvote 18:05:30 Voted on "Rollcall?" Results are 18:05:31 here (17): rodrigods, davechen, gyee, lbragstad, ayoung, morganfainberg, lhcheng, bknudson, ajayaa, dstanek, dolphm, topol, joesavak, amakarov, henrynash, raildo, stevemar 18:05:37 (see: http://www.omrlp.com) 18:05:39 boom, new list! 18:05:45 we'll do that the next couple meetings and then prune the list down. 18:06:17 #topic RC2 opens for patches tomorrow 18:06:19 morganfainberg, is the new list going to be the union or intersection? 18:06:30 henrynash, theyd get my vote 18:06:36 ayoung, new list will be union of all around for all 3 rollcalls 18:06:47 first patches will have to be ones to get it working. 18:06:47 anyway, RC2 opens tomorrow 18:06:49 ayoung: must be present to win 18:07:02 w00t! 18:07:04 we have ~5-6 bugs 18:07:11 i don't think we have a lot more to add. 18:07:13 looking good 18:07:24 morganfainberg, is all the web sso stuff in? 18:07:34 Let me check the blacklist one...I thought that made it 18:07:35 ayoung, if it isn't we can't backport it. 18:07:49 ayoung, i'm 99% sure that landed. 18:07:54 morganfainberg, yeah, I think the issue is other projects, not Keystone server 18:08:01 ayoung: yeah, that is in master and tagged for rc 18:08:15 blacklist in mapping rules? 18:08:19 rodrigods, yeah 18:08:22 :( 18:08:23 rodrigods, I'll link 18:08:29 it should be in rc 18:08:46 anyway 18:08:49 ayoung: oops nvm, thought it was the remote_id mapping. 18:08:51 we can evaluate it if it isn't in rc1 18:09:05 lhcheng, ah, I knew there was one... 18:09:06 but i think it had dependency issues 18:09:17 or one of them did and needed to push to L 18:09:19 morganfainberg, yeah, remote_id mapping needs backport 18:09:29 ayoung, that one was icky iirc 18:09:31 anyway 18:09:37 remote_id mapping hasn't support in OSC 18:09:43 saw someone complaining about it 18:09:44 9b11d13856034e3a2cf6ab1f6ca80a6965818d17 18:09:44 please tag bugs w/ the kilo-rc-potential flag 18:09:53 if it should be in RC [and is a legitimate blocker] 18:10:07 there was also the bug nkinder fixed ... 18:10:10 if it is questionable if it should block RC ask me, ask dolphm, 18:10:40 dolphm, hah you don't get off the hook! >.> 18:10:46 bug: #1440185 18:10:48 bug 1440185 in Keystone "Identity provider create fails if remote_id is not set" [High,Fix released] https://launchpad.net/bugs/1440185 - Assigned to Nathan Kinder (nkinder) 18:10:49 /hugs 18:11:04 ayoung, fixed released = in rc 18:11:12 yep...just doing the due dilligence 18:11:16 ayoung, would be fix commited otherwise :) 18:11:27 we put too much effort into websso to have it be broken due to an unmerged patch now 18:11:39 ok moving on 18:11:45 #topic Keystone middleware to "named" release model 18:11:50 as much as I like Semver 18:11:59 we are locked to the requirements of the process ksm runs in 18:12:04 among other things 18:12:15 we should move ksm to the named release model 18:12:32 i'll put this to a vote though. 18:12:35 ayoung: doa 1.2.0 released yesterday - that includes the websso patch 18:12:38 and/or open for discussion 18:12:38 we could try to expand the supported requirements. 18:12:45 schawing!\ 18:13:07 lhcheng, and Horizon had all the fixes in rc 1 as well, right? 18:13:11 although that will be difficult if it depends on keystoneclient features. 18:13:11 bknudson, the issue is semver + global-requirements = really really odd mixes of can/does/doesn't work 18:13:25 ayoung: yes 18:13:28 morganfainberg, so: https://bugs.launchpad.net/keystone/+bug/1441827 can't be backported? 18:13:29 Launchpad bug 1441827 in Keystone "Cannot set per protocol remote_id_attribute" [High,Fix committed] - Assigned to Lin Hua Cheng (lin-hua-cheng) 18:13:30 the named release is fine with ksc since it still locks to the version. 18:13:32 It means our docs are wrong 18:13:41 ayoung, we will evaluate any bug. 18:14:15 morganfainberg: switching to named versions would mean we could start deprecating in release + 2 at least 18:14:15 ayoung, is it legitimately a release blocker? or is it a "would be nice to have" 18:14:16 morganfainberg, its currently targetted at L1 18:14:21 jamielennox, correct. 18:14:36 jamielennox: i like that 18:14:38 ayoung, lets look at it tomorrow with the other bugs. 18:14:53 I think we can already deprecate things since we've got stable branches now. 18:15:04 morganfainberg, so I shouldtag ita s rc2 if I think it should be backported? 18:15:04 for keystonemiddleware and keystoneclient 18:15:15 ayoung, yes. 18:15:37 bknudson, client is a bit different since the CLI and interfaces are used outside of openstack 18:15:45 bknudson, but ksm is all private interfaces 18:15:51 OK...it has that 18:15:58 bknudson, lets start with KSM since it's easier and attack client separately 18:16:09 bknudson, before we deprecate in client i want to do the keystoneauth split anyway 18:16:32 split keystoneauth? 18:16:47 gyee: session and auth plugins into there own library 18:16:49 gyee, session, discovery, plugins into their own repo. auth != interfacing with keystone's API 18:17:05 and really trim requirements down for it 18:17:06 k, make sense 18:17:24 so, for KSM, anyone feel strongly against moving it to the named release cycle? 18:17:31 is openstack sdk going to use keystoneauth? 18:17:32 I think they would be oslo common right? 18:17:33 this would be for Liberty and beyond. 18:17:37 since auth is shared 18:17:53 named release cycle makes sense for ksm. 18:17:53 kilo will stick with semver cause we're already here. 18:18:21 and we have lots of test rekejiggering to do if we do named/milestone releases 18:18:28 s/test/gate job/ 18:18:57 ok quick vote 18:19:29 #startvote Move keystonemiddleware to "named" release cycle? yes,no,i-dislike-polls 18:19:30 Begin voting on: Move keystonemiddleware to "named" release cycle? Valid vote options are yes, no, i-dislike-polls. 18:19:31 Vote using '#vote OPTION'. Only your last vote counts. 18:19:44 fair warning, that last option is a yes. 18:19:45 #vote i-dislike-polls 18:19:49 #vote yes 18:19:56 #vote yes 18:19:58 #vote yes 18:20:00 #vote no-strong-opinion 18:20:01 #vote yes 18:20:01 dolphm: no-strong-opinion is not a valid option. Valid options are yes, no, i-dislike-polls. 18:20:17 #vote yes 18:20:17 #vote i-dislike-polls 18:20:17 #vote yes 18:20:24 tbh, i would be fine either way 18:20:24 #vote i-dislike-polls 18:20:33 #vote i-dislike-polls 18:20:33 #vote yes 18:20:34 dstanek: ++ 18:20:43 same here 18:20:43 #vote yes 18:20:46 dolphm, dstanek, no strong opinion = lets go with the easier/less confusing path 18:20:58 which i think is named releases 18:20:59 #vote yes 18:21:05 15 more s 18:21:13 does dolphm mean he is a strong no or no opinion? 18:21:21 #vote yes 18:21:36 topol, eats shoots and leaves or eats, shoots, and leaves? 18:21:42 #endvote 18:21:43 Voted on "Move keystonemiddleware to "named" release cycle?" Results are 18:21:45 i-dislike-polls (4): lbragstad, rodrigods, dstanek, dolphm 18:21:45 topol: strong no opinion 18:21:46 yes (10): joesavak, gyee, ayoung, morganfainberg, lhcheng, davechen, jamielennox, amakarov, bknudson, topol 18:21:57 let's eat grandma 18:22:08 #action in liberty keystone middleware moves to "named" release 18:22:18 i kinda wish everything was semver, but 18:22:29 dolphm, yah 18:22:34 yah, what happened to keystone semver? 18:22:45 sem ver in portuguese: without seeing 18:22:52 bknudson, i am worried about a bag of worms that scares the hell out of me at the moment 18:23:02 bknudson, waiting for some fallout from big tent to make any proposals 18:23:05 now I'm scared. 18:23:11 haha 18:23:27 bknudson, it's more how much bikeshedding do i want to deal with over something that has minimal impact at the moment 18:23:40 bknudson, shouldn't affect anyone measurably otherwise 18:24:00 too late for voting "here" ? :( 18:24:14 and right now, my tolerance for that kind of bike shedding is pretty low (after release i'll be more open to dealing with that) 18:24:27 htruta, which way would you have voted? 18:24:28 htruta, just make sure you make the poll at the meeting for being on the ping list 18:24:46 morganfainberg: was there more than one choice? 18:24:56 dolphm, for rollcall? oh no 18:24:57 :) 18:25:07 abstain? 18:25:09 htruta, we'll do a few more rollcall votes 18:25:13 * dolphm votes htruta is here 18:25:24 before we trim any lists 18:25:27 morganfainberg, ayoung: cool 18:25:28 and i see you're here 18:25:29 :) 18:25:47 thanks, dolphm lol 18:25:47 delegated single-factor authentication. 18:25:49 the next few topics are related 18:26:01 #topic Spec proposal freeze L1, feature freeze L2 18:26:14 this is in line with making the summit what our midcycle has been 18:26:20 push specs through 18:26:26 address design decisions 18:26:38 and give ourselves a lot more runway for code to land in Liberty 18:26:41 Our batle cry is "check my spec or I'll wring your neck!" 18:26:45 especially being a slightly shorter cycle 18:26:49 morganfainberg: we don't have hard dates for L1 and L2 yet do we? 18:26:56 ayoung: ha! 18:27:07 lbragstad: not yet 18:27:14 lbragstad: there's some proposed dates on the ML 18:27:15 lbragstad, i think we have firm but not confirmed dates 18:27:29 most are around the last milestone with question marks iirc 18:27:37 lbragstad: unless someone has a reason to object to the proposed dates 18:27:49 dolphm: morganfainberg makes sense 18:28:10 proposed sched: ( i looked it up so think y'all may be too): 18:28:10 liberty-1: June 25th 18:28:10 liberty-2: July 30th 18:28:10 liberty-3: September 3rd 18:28:10 final release: October 15th 18:28:32 The goal here is to keep the "new" API impacting features to a short ~5 item list. 18:28:46 so things like Reseller, Policy refactor, tokenless auth 18:28:57 all on the proposed list. 18:29:11 but i want to keep this list small so we can focus on stability, performance, and testing 18:29:14 and can we lay on this an approximate mid-cyle date (want to make sure I’m not moving house again)? 18:29:24 myabe around 2nd week of July? 18:29:31 henrynash, i am hopeing we can avoid a midcycle 18:29:34 henrynash, to be honest 18:29:39 an in-person one that is 18:29:42 really? 18:29:46 will we be doing a midcycle meetup (as I make reservations to travel to Austin next week..) 18:29:54 I'll just have to hang out on the riverwalk for no reason. 18:30:17 I heard Vegas have better conference rooms 18:30:22 Westford 18:30:23 i'd rather people travel to other midcycles and focus on getting initiatives like "openstack working with V2 disabled" 18:30:25 I vote for a midcycle 18:30:30 there's pretty good saxophone music down there... 18:30:32 than travel. 18:30:39 gyee, or in Rio, in Brazil :D 18:30:57 ++ for Rio 18:31:03 but if everyone wants a mid cycle, i'll start doing the legwork to get space 18:31:10 because i'd like to start that now 18:31:16 Midcycle at henrynash 's new house! 18:31:30 perhaps midcycle topic for next meeting? We can combine with horizon/oslo groups? 18:31:36 ok,,,,,sure….by the coast…yep, lay it on 18:31:42 Im scared not to do one in person. Those are quite productive 18:31:48 joesavak, that would be cool 18:31:57 joesavak, sure. lets do PDX, SEA, or California though :P 18:32:11 joesavak, to be fair i am aiming to *not* do it in SAT if we do it. 18:32:13 good w/me 18:32:15 morganfainberg, let's get you to NYC 18:32:30 Boston could also be on the list. 18:32:34 ++ 18:32:38 so sounds like people like midcycles. 18:32:40 We could certainly host 18:32:45 ok i'll start finding a venue 18:32:48 i'll put a ML topic out 18:32:48 morganfainberg: ftr, the hp chelsea office worked out well for us :) 18:32:49 they are very useful 18:32:57 hawaii is still US 18:33:02 we will talk more next week on it 18:33:04 I know that other teams have had midcycyles here 18:33:07 Boston++ 18:33:10 but we'll confirm it all before the summit if at all possible 18:33:14 jamielennox: ++ 18:33:18 + Austin 18:33:29 amolock, sorry i veto texas for this one for keystone 18:33:33 anywhere that I can get sponsored to go :) 18:33:37 amolock, we've done texas the last few times. 18:33:47 because it's the best 18:33:48 rodrigods, and i'll make sure to get the right letters in place for you guys to come up. 18:33:56 :D 18:33:58 rodrigods, remind me on that though ok? 18:33:58 morganfainberg, as strange as it sounds to say it, I bet we could get space at the Microsoft NERD center in Cambridge 18:34:00 Boston or Westford? There *is* a difference 18:34:04 morganfainberg, ++ thanks! 18:34:22 topol, next meeting we will go more in detail 18:34:27 and line up options. 18:34:32 i'll send out some emails this week. 18:34:37 so i have some options. 18:34:49 anyway. 18:35:00 #action morganfainberg schedule midcycle arrangements 18:35:59 #link https://etherpad.openstack.org/p/keystone-liberty-priority-specs 18:36:16 please fill out this etherpad so we can confirm our ~5ish features for next cycle 18:36:19 sow e can get to work on specs 18:36:26 this is for "new" API impacting features 18:36:41 REST API? 18:36:42 tests, ABI definitions, tech debt paydown, performance, etc 18:36:44 drop dead date for this? 18:36:47 those are separate 18:36:51 morganfainberg: what about specs that focus on refactoring and cleanup? 18:36:53 bknudson, yes REST API. 18:37:34 morganfainberg, sometimes there are features that need to be split into more than one spec 18:37:54 HMT, for example: hmt, improvements and recursive deletion 18:38:10 rodrigods, reseller is "new" 18:38:29 rodrigods, recursive deletion would be minor or part of reseller 18:38:32 for example 18:38:39 ++ 18:39:16 morganfainberg, and we intend to create a spec for dual scoped token 18:39:33 just keep in mind i really want to keep the feature count low this cycle 18:39:41 morganfainberg, so we keep this part of reseller? 18:39:45 so we can really really make the rest of the stuff we have solid 18:39:56 raildo, i think it's fair to say it's part of the reseller spec or subordinate to reseller 18:40:10 morganfainberg, ok 18:40:12 raildo, it's primary use would be in a reseller context, right? 18:40:57 we will circle up on this next meeting and get some direction 18:41:05 please tag "new" features that are small as (minor) 18:41:07 morganfainberg, yes, but we need to create a new spec to discuss this (or discuss at the summt and we can create just a BP) 18:41:14 as the person with the pink text has done 18:41:50 I'm assuming that all the Service Federation will be off in its own Stackforge project, so the focus should be on Keystone features (if any) absolutely needed to enable it. 18:41:59 geoffarnold, yeah 18:42:17 geoffarnold, it may live under keystone long term, but i'd like that to be outside of the main tree 18:42:23 tempted to move token constraints under dynamic policy 18:42:28 geoffarnold, you have a wiki/link for service federation? 18:42:29 Me too. For asynchrony 18:42:36 geoffarnold, focus on doing that "well" vs in the context of "within keystone's process space" 18:42:42 they are aseparate, but it would be on policy to enforce....that make sense? 18:42:42 amakarov, add your spec there! 18:42:45 Coming in a day or two 18:42:50 amakarov, maybe in the second session 18:43:01 rodrigods, ok 18:43:09 Remind me... is IdP per domain currently in? 18:43:19 geoffarnold, uhm.. 18:43:28 geoffarnold, i think so 18:43:41 this will be circled up on next meeting. 18:43:55 geoffarnold, we can look to be sure between now and then. 18:43:57 If it's not API-settable, I'll be pushing that. Thanks 18:43:57 geoffarnold, what do you mean? We can do it in the mapping file 18:44:03 2 more topics 18:44:10 got to keep it moving :) 18:44:20 offline then 18:44:32 #topic Summit sessions 18:45:24 Keystone (fishbowl) 4 (hacksessions) 8 (½-day friday meetups) 2 18:45:29 this is our current allocation 18:45:43 so, full day friday? 18:45:45 i'm asking for 1 more fishbowl...but there is 1 left.. so we probably wont get it 18:45:47 dolphm, yes 18:46:01 this is why i wanted to push so hard for keystone's summit to be more like our midcycle 18:46:09 we have a lot of time for this stuff this time around :) 18:46:20 morganfainberg, we are going to need both 18:46:30 i also tried to keep our pre-set allocations light so we can get to other sessions with other projects 18:46:56 especially with the feature freeze, we need the midcycyle to approave essential features 18:47:00 making sure other projects don't go off into the weeds with identity/auth/etc is an important part of what we do. 18:47:19 ayoung, the other reason to move FF to L-2 is that if something slips, we have all of L3 to catchup 18:47:40 ayoung, but we wont be piling every feature in on L-3 like we did with kilo 18:47:45 ++ 18:47:49 with no extra runway 18:47:51 which projects moved to using Keystone V3 this cycle? 18:48:35 topol, the goal is all projects work with v2 disabled 18:48:57 we can worry about other V3 support things after that is achieved 18:49:01 morganfainberg, we need to beat up the puppet and ansible guys on that, too 18:49:01 cool 18:49:11 remove the requirement for auth in all the projects, and you can run with v2 disabled. ; ) 18:49:15 ayoung, 1st step: devstack works that way. 18:49:21 I'm proposing a Federation session as part of the Cross-project area. We can use some of that to discuss reseller, which may take pressure off our Keystone sessions. If you'd like this, please add to https://docs.google.com/spreadsheets/d/1vCTZBJKCMZ2xBhglnuK3ciKo3E8UMFo5S5lmIAYMCSE/edit#gid=827503418 18:49:37 geoffarnold, ++ 18:50:01 joesavak, i want to move auth endpoints to /auth not //auth 18:50:11 joesavak, there is a lot of detial i disucssed with jamielennox on this already 18:50:29 joesavak, and just wire up the auth endpoints in the backend for compat 18:50:30 joesavak, anyway 18:50:39 joesavak, for later design discussions 18:50:53 ah, interesting - yeah - want to dig in more there 18:50:54 last topic 18:51:06 #topic NoSql backend 18:51:06 geoffarnold, and if you want, we can discuss later the reseller part for this design session 18:51:22 ajayaa, o/ 18:51:25 oh not here 18:51:28 #undo 18:51:28 Removing item from minutes: 18:51:31 Didn't we just remove all the nosql backends? 18:51:34 I'm -1 on any new backends. 18:51:42 I assume this is an identity backend. 18:51:45 morganfainberg, what about Redis? :) 18:51:50 bknudson, yah was going to ask for more info 18:51:51 no swift backend then? :) 18:51:52 bknudson, anyway 18:52:10 amakarov, i'd like all backend to eventually move out of the main tree 18:52:15 so we have clear dependency graphs 18:52:21 but different discussion 18:52:24 amakarov, identity-no. Token-no. Others---show me the money 18:52:35 heh 18:52:35 #topic Open Discussion 18:52:39 8mins left 18:52:51 identity should be frozen as is...primarily sql, LDAP goes awayover time 18:53:00 tokens become ephemeral thanks to fernet 18:53:08 revocations....welll, maybe there... 18:53:13 catalog? 18:53:17 ayoung, i actually see identity CRUD moving to it's own process with a conductor like interface to direct access. 18:53:30 morganfainberg, and I don't disagree 18:53:37 ayoung, that way if someone wants to really double down on the CRUD interfaces for identity we let them. 18:53:43 * topol you'll have to pry LDAP from my cold dead Keystone hands :-) 18:53:53 topol, conductor-like interface would provide that 18:53:54