18:01:16 #startmeeting keystone 18:01:17 Meeting started Tue Dec 1 18:01:16 2015 UTC and is due to finish in 60 minutes. The chair is stevemar. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:01:18 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:01:21 The meeting name has been set to 'keystone' 18:01:23 agenda: https://wiki.openstack.org/wiki/Meetings/KeystoneMeeting 18:01:42 stevemar o/ 18:01:49 i'm guessing the agenda is light since most folks saw my mailing list post 18:01:50 hi 18:02:13 mitaka-1 is ending, i wanted to have a roll call on the specs, make sense? 18:02:32 sure 18:02:32 this way we don't have to file FFE at the beginning of mitaka-2 18:02:38 stevemar it doesn't just make sense... it makes dollars... 18:02:39 what's a roll call on specs? 18:02:49 * lbragstad wins pun-of-the-day award 18:02:51 bknudson: basically to make sure there's someone here to champion each spec 18:02:55 o/ 18:03:07 a spec needs a champion and 2 core reviewers to get merged 18:03:21 bknudson: dolphm and to make sure we have a majority of support 18:03:38 \o 18:03:52 * notmorgan lurks but refuses to commit to more than lurking 18:03:54 bknudson: 2 cores may not have the same opinion as the rest :P 18:04:00 * gyee make sure his magic 8 ball still works 18:04:04 Should we vote on the remaining short list to see if we are OK with them? 18:04:14 ayoung: there's also that 18:04:33 the intention is to and speed up the process in getting specs merged 18:04:50 stevemar, I missed the link you had with the short list 18:04:56 or shoudl we go by gerrit? 18:04:59 * topol lbragstad is someone I have huge respect for... But his puns are terrible 18:05:04 do we have the review bandwidth to take on any more work? 18:05:24 topol :) 18:05:33 ayoung: the ones i want to bring up are here: http://paste.openstack.org/show/480545/ 18:05:43 https://review.openstack.org/#/c/240595/ Shadow users is, to me, the most importanat outstanding spec. 18:05:48 bknudson: it's more about targeting 18:05:56 ayoung: ++ 18:06:26 its got an array of -1s, and a +2 from stevemar 18:06:36 ayoung, I saw that... 18:06:48 made me notwant to review :-) 18:06:50 ayoung: ++ 18:06:52 ayoung: i was going to set the topic and vote for each one 18:07:00 i believe ron is planning on picking that spec up.. and/or respinning it 18:07:03 I don't think we should be targeting to m when we don't have the review bandwidth for it to land in m 18:07:36 bknudson: bandwidth was good (look at the number of reviews), response time not really :( 18:07:46 bknudson: wrt shadow users 18:07:53 stevemar, vote away, please 18:07:57 bknudson: we currently have 6 reviews targeted for all of M http://specs.openstack.org/openstack/keystone-specs/#identity-program-specifications 18:08:00 y, looks like the submitter has abandoned shadow users. 18:08:22 stevemar what is the vote for? 18:08:27 submitter abandoned shadow users??? 18:08:36 lbragstad: ^^ beware, you have a competitor for today's pun-of-a-day contest :P 18:08:36 FFE? 18:08:54 breton: it was a joke 18:08:54 ok, let’s get to it…..8 minutes gone 18:08:57 topol: the vote is for "do we want this to appear in M" 18:09:02 got it 18:09:21 henrynash: it's the first time doing this, i expect questions 18:09:37 #startvote Target "Shadow users: unified identity" to Mitaka? Yes, No, Abstain 18:09:38 Begin voting on: Target "Shadow users: unified identity" to Mitaka? Valid vote options are Yes, No, Abstain. 18:09:39 Vote using '#vote OPTION'. Only your last vote counts. 18:09:44 vote yes 18:09:46 #vote yes 18:09:46 #vote Yes 18:09:51 stevemar: in a shape "as is" ? 18:09:53 #vote Yes 18:09:55 #vote yes 18:09:58 #vote yes 18:09:58 #vote Yes 18:09:58 #vote yes 18:10:00 #vote abstain 18:10:00 #vote yes 18:10:03 #vote yes 18:10:03 #vote Yes 18:10:05 #vote yes 18:10:08 #vote Abstain 18:10:17 #vote Abstain 18:10:18 #vote Abstain 18:10:34 since i didn't get a chance to take a look 18:10:35 marekd: not necessarily in it's current shape, but a yes means it's important to project plans and we'll help it out if it's not in good shape 18:10:49 marekd, to answer your question, I would say " if it went in as is, things would be ok, but we can still submit minro tweaks to the spec until M2 18:10:52 " 18:11:12 ayoung: yes, i think you understand the intention i'm trying for here 18:11:12 stevemar: oh, yes, so it's important. just need somebody to take care of it. dolphm, i though you were going to do it. 18:11:17 I'm not sure why the vote... all it should require is for 2 cores and owner to sign up to get it done for M. 18:11:30 bknudson: 2 does not reflect the majority 18:11:32 marekd: only championing it 18:11:53 bknudson: because there will be a freeze this week and we want to know which patches not to freeze 18:11:56 I guess 18:11:57 bknudson: want to make sure that there is no reason not to do it 18:11:58 put my +2 on it. Anyone daring enough to +A is welcome to do so 18:12:05 stevemar, is this a prioritization effort? 18:12:06 bknudson: if tis is a pointless exercise we'll find out in 48 minutes :) 18:12:23 dstanek: ++ 18:12:29 topol: yes 18:12:33 #endvote 18:12:34 Voted on "Target "Shadow users: unified identity" to Mitaka?" Results are 18:12:35 Yes (11): gyee, dstanek, ayoung, marekd, shaleh, lbragstad, dolphm, topol, lhcheng_, breton, stevemar 18:12:36 Abstain (4): henrynash, bknudson, davechen1, notmorgan 18:12:47 \o/ 18:12:48 allright, how about everbody take a look at https://review.openstack.org/#/c/188534 ? 18:13:19 marekd: the list is here: http://paste.openstack.org/show/480545/ 18:13:22 marekd: I supprt the idea, not sold on the current solution 18:13:35 let’s let stevemar drive the list here 18:13:40 alright, next one 18:13:44 shaleh: so, review :-) 18:13:48 #startvote Target "Domain Specific Roles" to Mitaka? Yes, No, Abstain 18:13:49 Begin voting on: Target "Domain Specific Roles" to Mitaka? Valid vote options are Yes, No, Abstain. 18:13:50 Vote using '#vote OPTION'. Only your last vote counts. 18:13:59 #vote yes 18:14:01 #vote abstain 18:14:09 henrynash, do you think you can accomplish this in Mitaka? 18:14:14 #vote on the fence 18:14:15 gyee: on the fence is not a valid option. Valid options are Yes, No, Abstain. 18:14:18 ayoung: abolutely 18:14:24 #vote Yes 18:14:26 #vote yes 18:14:29 I like the idea, but not the design 18:14:32 #vote Abstain 18:14:34 #vote abstain 18:14:36 #vote abstain 18:14:36 #vote abstain 18:14:43 #vote abstain 18:14:43 #vote yes 18:14:48 #vote abstain 18:14:55 gyee, I think it is a subset of what we will have eventually, and, to be honest, needs HMT to be truely useful, but will be a good step forward 18:14:56 #vote abstain 18:14:57 not sure, is this vote the "design is ok as well"? 18:15:14 cause if the idea is this is "close-ish" then i would say "vote no" if you don't like the design 18:15:15 : #vote I’m not voting, since you shouldn;t vote for your own proposal 18:15:27 #vote yes 18:15:33 #vote Yes 18:15:34 my vote is more of a yes-ish 18:15:50 the design is confusing from UX standpoint 18:15:52 with gyee, i like the idea 18:15:55 #vote yes 18:15:58 #vote abstain 18:16:22 this is one of those things i get asked about on a regular basis 18:16:25 gyee: originally we had two different APIs, everyone said…NO…combine with imlied roles…so I dod 18:16:33 (did) 18:16:36 henrynash: who is asking? 18:16:42 dolphm: can you elaborate? 18:16:56 henrynash: who is the driving force behind that request? 18:16:58 #showvote 18:16:59 Yes (7): ayoung, marekd, htruta, topol, dolphm, raildo, stevemar 18:17:00 notmorgan: for domain roles? sever al customers 18:17:00 Abstain (9): gyee, lbragstad, notmorgan, lhcheng, bknudson, dstanek, david8hu, davechen, breton 18:17:23 henrynash: like "this would be nice" or "OMG WE MUST HAVE"? 18:17:24 stevemar: i get questions about why roles aren't owned by domains, why domain administrators aren't able to write their own policy, etc 18:17:28 henrynash: i'm trying to get a read on this 18:17:35 henrynash, any last changes you want to make before I +A? 18:17:49 ayoung: no 18:17:52 no changes 18:17:56 ayoung: hold off on +A'ing until after please 18:18:02 too late 18:18:03 Heh 18:18:12 notmorgan: it’s someone peopel are strating to hit…as we grow our public cloud 18:18:16 #endvote 18:18:17 Voted on "Target "Domain Specific Roles" to Mitaka?" Results are 18:18:18 Yes (7): ayoung, marekd, htruta, topol, dolphm, raildo, stevemar 18:18:19 Abstain (9): gyee, lbragstad, notmorgan, lhcheng, bknudson, dstanek, david8hu, davechen, breton 18:18:24 we are overloading the same APIs for implied roles, but those are NOT implied roles 18:18:30 notmorgan: i think ti's a real problem 18:18:32 gyee, yes they are 18:18:33 stevemar: i blocked the merge btw 18:18:40 i'll unblock it after meeting 18:18:42 they don't get included in token response 18:18:44 notmorgan, thanks 18:19:02 gyee, implied roles *are* the ones that get into the token response. 18:19:14 Domain specifi roles are explicit roles 18:19:19 right, but not the domain specific roles 18:19:28 so that's hard to explain from UX standpoint 18:19:33 ...actually, I just realized that they don't need to be...you could have a domain-specific-implicit-role 18:19:43 henrynash, ^^ make sure that we don't mess that up, OK? 18:19:43 using the same API, but behave differently 18:19:44 sounds like there is still some confusion here henrynash and ayoung 18:19:47 Nope 18:20:06 #todo henrynash and ayoung to convince notmorgan and gyee in -keystone 18:20:12 stevemar, just a realization that there is something subtle to not mess up in henrynash 's implementation 18:20:26 hash it out, but not here 18:20:28 next one 18:20:29 stevemar: so with 7 cores voting yes and no NOs we aren;t done? 18:20:33 ayoung: we have a lot of subtle. We should work harder at explicit 18:21:03 that be a high bar we are setting 18:21:11 with 7 people signing up to get it done that should be good enough 18:21:12 henrynash: i'll look at the result in the meeting logs 18:21:15 work out the details in the reviews 18:21:54 bknudson: yes 18:21:58 next one 18:21:59 #startvote Target "Enable retrieval of default values of domain config options" to Mitaka? Yes, No, Abstain 18:22:00 Begin voting on: Target "Enable retrieval of default values of domain config options" to Mitaka? Valid vote options are Yes, No, Abstain. 18:22:01 #link https://review.openstack.org/#/c/185650/ 18:22:01 Vote using '#vote OPTION'. Only your last vote counts. 18:22:02 I absolutely for the idea of domain-specific roles, just need to make it usable 18:22:04 #vote yes 18:22:07 i think this is an easy one 18:22:20 #vote Abstain 18:22:33 #vote abstain 18:22:37 #vote abstain 18:22:38 #vote abstain 18:22:39 #vote yes 18:22:43 #vote abstain 18:22:50 # #vote i'dvotenobutidon'thaveagoodalternativeanswer 18:22:52 I like templates better, but hey, baby steps right 18:23:00 i like the idea, but i'm not sure i like the impl described 18:23:08 this one mine? 18:23:13 #vote abstain 18:23:15 ayoung: no, henrynash's 18:23:23 #vote abstain 18:23:31 getting the default configuration from /domain-config 18:23:34 like, i kinda want to vote no, but without an alternative to present... -- i can't even in good concience vote abstain 18:23:38 #vote yes 18:23:39 #vote yes 18:24:06 sounds like there is work to do here 18:24:09 #endvote 18:24:10 #vote yes 18:24:10 Voted on "Target "Enable retrieval of default values of domain config options" to Mitaka?" Results are 18:24:11 Yes (4): gyee, ayoung, topol, stevemar 18:24:12 Abstain (7): lbragstad, lhcheng, bknudson, marekd, david8hu, dolphm, davechen 18:24:16 if we can fix the API 18:24:30 dstanek comment on the spec with your concerns 18:24:35 the review is all positive currently 18:24:36 stevemar: will do 18:24:40 dstanek: yep happy to work with you 18:24:41 OK...if any of you abstaining cowards want to hold this up, -2 it now or live with it 18:24:44 :) 18:24:51 henrynash: you are creating as many specs as ayoung! 18:24:56 #startvote Target "Allow url-safe project and domain names to be optionally enforced" to Mitaka? Yes, No, Abstain 18:24:57 Begin voting on: Target "Allow url-safe project and domain names to be optionally enforced" to Mitaka? Valid vote options are Yes, No, Abstain. 18:24:58 Vote using '#vote OPTION'. Only your last vote counts. 18:25:01 #link https://review.openstack.org/#/c/248083/ 18:25:06 #vote yes 18:25:07 stevemar, we've lived with the same broken windows for the same length of time 18:25:08 ayoung: see my previous statement. i wont block it cause i really can't offer something better 18:25:10 one has to aim high, right? 18:25:11 #vote yes 18:25:15 well, I've been here marginally longer, but... 18:25:18 lbragstad: thank you 18:25:28 #vote Abstain 18:25:30 #vote Abstain 18:25:36 #vote yes 18:25:38 #vote yes 18:25:40 #vote yes 18:25:42 #vote yes 18:25:44 #vote yes 18:25:48 henrynash: is unicode/utf-8 handled here? 18:25:48 #vote yes-but-I-am-a-coauthor 18:25:49 ayoung: yes-but-I-am-a-coauthor is not a valid option. Valid options are Yes, No, Abstain. 18:25:52 before i vote? 18:26:04 notmorgan, no 18:26:06 then 18:26:07 #vote no 18:26:14 notmorgan, we are saying to start just alpha-num 18:26:16 notmorgan: I called it out in my review 18:26:17 #vote yes 18:26:22 that's fine. 18:26:24 we start off strict, make less strict over time 18:26:26 i'm happy to be a dissenter here 18:26:39 yay, the first one "no" for today 18:26:40 notmorgan, you would say yes if it accepted unicode? 18:26:41 notmorgan: is that your only concern 18:26:42 ? 18:26:49 stevemar: that is my only concern 18:26:59 #vote yes 18:26:59 many deployments use unicode/utf-8 18:27:01 not allowing users to use umlauts is a pretty big deal 18:27:17 DNS doesn't support umlauts as far as I know 18:27:18 damn umlauts 18:27:19 and i don't want us to start on a path that relies on url-safe w/o that included 18:27:27 BUT, users with unicode can choose not to enable thise 18:27:30 bknudson: i think it does support special chars 18:27:34 so, interop will suck. 18:27:41 you'd have to do punycode or whatever. 18:27:44 this is an end-user impacting thing as well. 18:27:54 notmorgan, we are talking about using this to create URLs 18:28:10 so, the end result needs to be passed, as is, into the URL 18:28:17 ayoung: and afaict this is backwards incompat 18:28:25 an umlauted chracter can be escaped and used that way, its just not what Keystone would store 18:28:29 No it does not 18:28:39 it is a optional feature for moving forward 18:28:50 except if we *have* this we will build on it 18:28:54 it explicitly is opt in, and for netst projects to be built into an URL scheme 18:28:59 and it will become defacto-required for other things 18:29:07 so, i stand by the #no until that is addressed 18:29:12 notmorgan, it is addressed 18:29:14 like i said, i am happy to be the dissenter here 18:29:20 why not just make the regex configurable, and default it to something relaxed. we can recommend a very strict regex, and people can write regex that accepts unicode if they want. 18:29:21 i wont -2 block it 18:29:23 the same way you would have it in an exisint URL 18:29:32 dolphm, same reason: 18:29:44 what gets saved has to be composable into a nesting , HTTP safe URL scheme 18:30:11 * notmorgan stands by this. but again, wont -2 or hard block it. 18:30:12 so the user at some point will need to use %843 or the like 18:30:25 this reminds be of blogging software that have a name for a post and also a slug that is url safe 18:30:32 the idea is that, in the future, we will do OS_PROJECT_DOMAIN_NAME=a/b/c/d and that becomes https://hostname/keystone/v3/domains/a/b/c/d 18:30:44 dstanek: agreed 18:30:47 anyway. 18:30:56 sounds like theres still some issues here too :( 18:30:57 so...a utility to make sure that a non -url safe one becoems URL safe would be fine 18:31:00 #endvote 18:31:01 Voted on "Target "Allow url-safe project and domain names to be optionally enforced" to Mitaka?" Results are 18:31:02 Yes (9): gyee, dstanek, lhcheng, davechen, marekd, shaleh, lbragstad, dolphm, stevemar 18:31:03 Abstain (2): bknudson, topol 18:31:04 No (1): notmorgan 18:31:09 but we need to ensure the post-processed value is URL safe. 18:31:31 clearly addressing this for end-user interop as well as deployments moving forward is important. 18:31:37 notmorgan: ++ 18:31:49 so though overwhelmingly yes, we should address the concerns in the specs 18:31:51 users will complain 18:31:51 spec* 18:31:59 yes understood, interop is important 18:32:17 https://docs.djangoproject.com/en/1.8/ref/utils/#django.utils.text.slugify 18:32:23 so i stand by my dissent. feel free to approve if you wish to override it. 18:32:32 that's the way i do it when writing similar things in django 18:32:50 7 more to go! 18:32:59 #startvote Target "Public/Private IdPs" to Mitaka? Yes, No, Abstain 18:32:59 we aint gonna make it 18:32:59 Begin voting on: Target "Public/Private IdPs" to Mitaka? Valid vote options are Yes, No, Abstain. 18:33:00 Vote using '#vote OPTION'. Only your last vote counts. 18:33:03 #link https://review.openstack.org/#/c/209941/ 18:33:09 #vote no 18:33:11 #vote yes 18:33:12 thanks for the links lbragstad 18:33:17 #vote yes 18:33:18 I am not going to implement 18:33:23 pending we can get resources.... 18:33:25 ayoung: why? 18:33:36 I am willing to work on it, but the current spec needs a lot of love 18:33:43 #vote abstain 18:33:45 marekd, I don't have the time or the driving need to. 18:33:45 shaleh: so go for it! 18:33:49 #vote abstain 18:33:53 ayoung: fair enough 18:33:53 #vote yes 18:33:54 that spec needs a lot of work 18:33:55 I'd like to see if we can work this together with marek's proposal for SP 18:33:59 #vote abstain 18:34:01 #vote abstain 18:34:04 #vote abstain 18:34:05 #vote yes 18:34:05 there's a totally valid problem to be solved here 18:34:10 lets approve in backlog, and, if we get it done, great 18:34:11 dolphm: yep 18:34:14 gyee: agree 18:34:16 ayoung: ++ 18:34:19 #vote no 18:34:19 agreed, which is why I did not abandon it 18:34:21 i'm okay with this going to backlog 18:34:22 dolphm, agree but the spec needs work 18:34:29 my no is "the spec feels like it is missing a lot" 18:34:29 #vote no 18:34:35 not because i dislike the idea 18:34:35 who will actually implement it? 18:34:37 notmorgan: you are not wrong 18:34:39 what notmorgan said 18:34:45 (based on spec needs much more work) 18:34:55 shaleh, you want to take it over, just leave me on as co-author and it is yours 18:34:57 dstanek: if we can get the spec hammered out I should be able to help 18:35:02 it's also missing API changes 18:35:04 whoever implements this needs to start by taking over the spec 18:35:05 #vote no 18:35:12 dolphm: yeah 18:35:20 if you can get it into shape by friday, and commit to implementing it in mitaka, I will gladly let it go forward 18:35:20 #vote abstain 18:35:23 stevemar: is that no becuase the current spec sucks or no because the idea is wrong? 18:35:24 dolphm, I think shaleh wants to volunteer :) 18:35:37 shaleh: the idea is pretty easy, we've had it around for a while 18:35:38 no, spec hammered out by Friday is not happening 18:35:45 simple as that 18:35:47 why do we vote for it? It's targeted to the backlog. 18:35:49 ok, then backlog it for now 18:35:54 this spec is reallty too simplistic 18:35:57 ++ 18:36:10 oh shoot, i didn't mean to include backlog specs 18:36:15 whoops 18:36:21 #endvote 18:36:22 Voted on "Target "Public/Private IdPs" to Mitaka?" Results are 18:36:23 Yes (3): dstanek, dolphm, marekd 18:36:24 Abstain (6): gyee, lbragstad, lhcheng, davechen, topol, bknudson 18:36:26 No (4): henrynash, ayoung, notmorgan, stevemar 18:36:28 marekd: sync up with me afterwards 18:36:31 can we do Make keystone fully fledged SAML2 Service Provider last 18:36:36 ayoung: yes 18:36:37 I think that will have some discussion 18:36:49 #startvote Target "Expand endpoint filters to service providers" to Mitaka? Yes, No, Abstain 18:36:50 Begin voting on: Target "Expand endpoint filters to service providers" to Mitaka? Valid vote options are Yes, No, Abstain. 18:36:51 Vote using '#vote OPTION'. Only your last vote counts. 18:36:52 #link https://review.openstack.org/#/c/188534/ 18:37:12 I think the idea is fine, most of my comments were nits 18:37:17 i'd be happy to review this one 18:37:18 does anyone have a strenuous objection to this one? 18:37:40 #vote abstain 18:37:41 i don't think it needs to be it's entirely own API though 18:37:43 i think there is concern about the fact that 'service providers' aren't in the catalog to begin with 18:37:45 I am not sold on wedging it into endpoint filter 18:37:51 lbragstad: it is not... 18:38:19 shaleh: lol, last time stevemar advised on extending OS-EP-FILTER 18:38:20 this needs to happen somehow. 18:38:23 i think 18:38:25 notmorgan: yes. 18:38:30 agreed 18:38:32 but how, i don't really care. 18:38:37 shaleh: ++ 18:38:38 so i fthis is the best way, we do it this way 18:38:39 How do we list Service providers now? Its a deliberate API call, right? 18:38:41 #vote abstain 18:38:52 ayoung: no, it's in the token response 18:38:55 only because I don't have very many suggestions on how to fix it 18:38:59