18:01:16 <stevemar> #startmeeting keystone
18:01:17 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:01:21 <openstack> The meeting name has been set to 'keystone'
18:01:23 <stevemar> agenda: https://wiki.openstack.org/wiki/Meetings/KeystoneMeeting
18:01:42 <lbragstad> stevemar o/
18:01:49 <stevemar> i'm guessing the agenda is light since most folks saw my mailing list post
18:01:50 <bknudson> hi
18:02:13 <stevemar> mitaka-1 is ending, i wanted to have a roll call on the specs, make sense?
18:02:32 <henrynash> sure
18:02:32 <stevemar> this way we don't have to file FFE at the beginning of mitaka-2
18:02:38 <lbragstad> stevemar it doesn't just make sense... it makes dollars...
18:02:39 <bknudson> what's a roll call on specs?
18:02:49 * lbragstad wins pun-of-the-day award
18:02:51 <dolphm> bknudson: basically to make sure there's someone here to champion each spec
18:02:55 <topol> o/
18:03:07 <bknudson> a spec needs a champion and 2 core reviewers to get merged
18:03:21 <stevemar> bknudson: dolphm and to make sure we have a majority of support
18:03:38 <david8hu> \o
18:03:52 * notmorgan lurks but refuses to commit to more than lurking
18:03:54 <stevemar> 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 <ayoung> Should we vote on the remaining short list to see if we are OK with them?
18:04:14 <stevemar> ayoung: there's also that
18:04:33 <stevemar> the intention is to and speed up the process in getting specs merged
18:04:50 <ayoung> stevemar, I missed the link you had with the short list
18:04:56 <ayoung> 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 <bknudson> do we have the review bandwidth to take on any more work?
18:05:24 <lbragstad> topol :)
18:05:33 <stevemar> ayoung: the ones i want to bring up are here: http://paste.openstack.org/show/480545/
18:05:43 <ayoung> https://review.openstack.org/#/c/240595/  Shadow users is, to me, the most importanat outstanding spec.
18:05:48 <stevemar> bknudson: it's more about targeting
18:05:56 <marekd> ayoung: ++
18:06:26 <ayoung> its got an array of -1s, and a +2 from stevemar
18:06:36 <topol> ayoung, I saw that...
18:06:48 <topol> made me notwant to review :-)
18:06:50 <shaleh> ayoung: ++
18:06:52 <stevemar> ayoung: i was going to set the topic and vote for each one
18:07:00 <lbragstad> i believe ron is planning on picking that spec up.. and/or respinning it
18:07:03 <bknudson> 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 <marekd> bknudson: bandwidth was good (look at the number of reviews), response time not really :(
18:07:46 <marekd> bknudson: wrt shadow users
18:07:53 <ayoung> stevemar, vote away, please
18:07:57 <stevemar> bknudson: we currently have 6 reviews targeted for all of M http://specs.openstack.org/openstack/keystone-specs/#identity-program-specifications
18:08:00 <bknudson> y, looks like the submitter has abandoned shadow users.
18:08:22 <topol> stevemar what is the vote for?
18:08:27 <breton> submitter abandoned shadow users???
18:08:36 <marekd> lbragstad: ^^ beware, you have a competitor for today's pun-of-a-day contest :P
18:08:36 <topol> FFE?
18:08:54 <marekd> breton: it was a joke
18:08:54 <henrynash> ok, let’s get to it…..8  minutes gone
18:08:57 <stevemar> topol: the vote is for "do we want this to appear in M"
18:09:02 <topol> got it
18:09:21 <stevemar> henrynash: it's the first time doing this, i expect questions
18:09:37 <stevemar> #startvote Target "Shadow users: unified identity" to Mitaka? Yes, No, Abstain
18:09:38 <openstack> Begin voting on: Target "Shadow users: unified identity" to Mitaka? Valid vote options are Yes, No, Abstain.
18:09:39 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
18:09:44 <ayoung> vote yes
18:09:46 <lbragstad> #vote yes
18:09:46 <stevemar> #vote Yes
18:09:51 <marekd> stevemar: in a shape "as is" ?
18:09:53 <ayoung> #vote Yes
18:09:55 <dstanek> #vote yes
18:09:58 <shaleh> #vote yes
18:09:58 <gyee> #vote Yes
18:09:58 <breton> #vote yes
18:10:00 <notmorgan> #vote abstain
18:10:00 <lhcheng_> #vote yes
18:10:03 <topol> #vote yes
18:10:03 <marekd> #vote Yes
18:10:05 <dolphm> #vote yes
18:10:08 <bknudson> #vote Abstain
18:10:17 <henrynash> #vote Abstain
18:10:18 <davechen1> #vote Abstain
18:10:34 <davechen1> since i didn't get a chance to take a look
18:10:35 <stevemar> 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 <ayoung> 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 <ayoung> "
18:11:12 <stevemar> ayoung: yes, i think you understand the intention i'm trying for here
18:11:12 <marekd> 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 <bknudson> 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 <stevemar> bknudson: 2 does not reflect the majority
18:11:32 <dolphm> marekd: only championing it
18:11:53 <breton> bknudson: because there will be a freeze this week and we want to know which patches not to freeze
18:11:56 <breton> I guess
18:11:57 <dstanek> bknudson: want to make sure that there is no reason not to do it
18:11:58 <ayoung> put my +2 on it.  Anyone daring enough to +A is welcome to do so
18:12:05 <topol> stevemar, is  this  a prioritization effort?
18:12:06 <stevemar> bknudson: if tis is a pointless exercise we'll find out in 48 minutes :)
18:12:23 <stevemar> dstanek: ++
18:12:29 <stevemar> topol: yes
18:12:33 <stevemar> #endvote
18:12:34 <openstack> Voted on "Target "Shadow users: unified identity" to Mitaka?" Results are
18:12:35 <openstack> Yes (11): gyee, dstanek, ayoung, marekd, shaleh, lbragstad, dolphm, topol, lhcheng_, breton, stevemar
18:12:36 <openstack> Abstain (4): henrynash, bknudson, davechen1, notmorgan
18:12:47 <stevemar> \o/
18:12:48 <marekd> allright, how about everbody take a look at https://review.openstack.org/#/c/188534 ?
18:13:19 <stevemar> marekd: the list is here: http://paste.openstack.org/show/480545/
18:13:22 <shaleh> marekd: I supprt the idea, not sold on the current solution
18:13:35 <henrynash> let’s let stevemar drive the list here
18:13:40 <stevemar> alright, next one
18:13:44 <marekd> shaleh: so, review :-)
18:13:48 <stevemar> #startvote Target "Domain Specific Roles" to Mitaka? Yes, No, Abstain
18:13:49 <openstack> Begin voting on: Target "Domain Specific Roles" to Mitaka? Valid vote options are Yes, No, Abstain.
18:13:50 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
18:13:59 <marekd> #vote yes
18:14:01 <notmorgan> #vote abstain
18:14:09 <ayoung> henrynash, do you think you can accomplish this in Mitaka?
18:14:14 <gyee> #vote on the fence
18:14:15 <openstack> gyee: on the fence is not a valid option. Valid options are Yes, No, Abstain.
18:14:18 <henrynash> ayoung: abolutely
18:14:24 <ayoung> #vote Yes
18:14:26 <raildo> #vote yes
18:14:29 <gyee> I like the idea, but not the design
18:14:32 <bknudson> #vote Abstain
18:14:34 <davechen> #vote abstain
18:14:36 <gyee> #vote abstain
18:14:36 <lbragstad> #vote abstain
18:14:43 <lhcheng> #vote abstain
18:14:43 <topol> #vote yes
18:14:48 <dstanek> #vote abstain
18:14:55 <ayoung> 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 <breton> #vote abstain
18:14:57 <notmorgan> not sure, is this vote the "design is ok as well"?
18:15:14 <notmorgan> 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 <henrynash> : #vote I’m not voting, since you shouldn;t vote for your own proposal
18:15:27 <stevemar> #vote yes
18:15:33 <htruta> #vote Yes
18:15:34 <stevemar> my vote is more of a yes-ish
18:15:50 <gyee> the design is confusing from UX standpoint
18:15:52 <stevemar> with gyee, i like the idea
18:15:55 <dolphm> #vote yes
18:15:58 <david8hu> #vote abstain
18:16:22 <dolphm> this is one of those things i get asked about on a regular basis
18:16:25 <henrynash> gyee: originally we had two different APIs, everyone said…NO…combine with imlied roles…so I dod
18:16:33 <henrynash> (did)
18:16:36 <notmorgan> henrynash: who is asking?
18:16:42 <stevemar> dolphm: can you elaborate?
18:16:56 <notmorgan> henrynash: who is the driving force behind that request?
18:16:58 <stevemar> #showvote
18:16:59 <openstack> Yes (7): ayoung, marekd, htruta, topol, dolphm, raildo, stevemar
18:17:00 <henrynash> notmorgan: for domain roles? sever al customers
18:17:00 <openstack> Abstain (9): gyee, lbragstad, notmorgan, lhcheng, bknudson, dstanek, david8hu, davechen, breton
18:17:23 <notmorgan> henrynash: like "this would be nice" or "OMG WE MUST HAVE"?
18:17:24 <dolphm> 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 <notmorgan> henrynash: i'm trying to get a read on this
18:17:35 <ayoung> henrynash, any last changes you want to make before I +A?
18:17:49 <henrynash> ayoung: no
18:17:52 <henrynash> no changes
18:17:56 <stevemar> ayoung: hold off on +A'ing until after please
18:18:02 <ayoung> too late
18:18:03 <ayoung> Heh
18:18:12 <henrynash> notmorgan: it’s someone peopel are strating to hit…as we grow our public cloud
18:18:16 <stevemar> #endvote
18:18:17 <openstack> Voted on "Target "Domain Specific Roles" to Mitaka?" Results are
18:18:18 <openstack> Yes (7): ayoung, marekd, htruta, topol, dolphm, raildo, stevemar
18:18:19 <openstack> Abstain (9): gyee, lbragstad, notmorgan, lhcheng, bknudson, dstanek, david8hu, davechen, breton
18:18:24 <gyee> we are overloading the same APIs for implied roles, but those are NOT implied roles
18:18:30 <stevemar> notmorgan: i think ti's a real problem
18:18:32 <ayoung> gyee, yes they are
18:18:33 <notmorgan> stevemar: i blocked the merge btw
18:18:40 <notmorgan> i'll unblock it after meeting
18:18:42 <gyee> they don't get included in token response
18:18:44 <ayoung> notmorgan, thanks
18:19:02 <ayoung> gyee, implied roles *are* the ones that get into the token response.
18:19:14 <ayoung> Domain specifi roles are explicit roles
18:19:19 <gyee> right, but not the domain specific roles
18:19:28 <gyee> so that's hard to explain from UX standpoint
18:19:33 <ayoung> ...actually, I just realized that they don't need to be...you could have a domain-specific-implicit-role
18:19:43 <ayoung> henrynash, ^^ make sure that we don't mess that up, OK?
18:19:43 <gyee> using the same API, but behave differently
18:19:44 <stevemar> sounds like there is still some confusion here henrynash and ayoung
18:19:47 <ayoung> Nope
18:20:06 <stevemar> #todo henrynash and ayoung to convince notmorgan and gyee in -keystone
18:20:12 <ayoung> stevemar, just a realization that there is something subtle to not mess up in henrynash 's implementation
18:20:26 <stevemar> hash it out, but not here
18:20:28 <stevemar> next one
18:20:29 <henrynash> stevemar: so with 7 cores voting yes and no NOs we aren;t done?
18:20:33 <shaleh> ayoung: we have a lot of subtle. We should work harder at explicit
18:21:03 <henrynash> that be a high bar we are setting
18:21:11 <bknudson> with 7 people signing up to get it done that should be good enough
18:21:12 <stevemar> henrynash: i'll look at the result in the meeting logs
18:21:15 <bknudson> work out the details in the reviews
18:21:54 <stevemar> bknudson: yes
18:21:58 <stevemar> next one
18:21:59 <stevemar> #startvote Target "Enable retrieval of default values of domain config options" to Mitaka? Yes, No, Abstain
18:22:00 <openstack> 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 <lbragstad> #link https://review.openstack.org/#/c/185650/
18:22:01 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
18:22:02 <gyee> I absolutely for the idea of domain-specific roles, just need to make it usable
18:22:04 <stevemar> #vote yes
18:22:07 <stevemar> i think this is an easy one
18:22:20 <bknudson> #vote Abstain
18:22:33 <marekd> #vote abstain
18:22:37 <dolphm> #vote abstain
18:22:38 <davechen> #vote abstain
18:22:39 <gyee> #vote yes
18:22:43 <lbragstad> #vote abstain
18:22:50 <notmorgan> # #vote i'dvotenobutidon'thaveagoodalternativeanswer
18:22:52 <gyee> I like templates better, but hey, baby steps right
18:23:00 <dstanek> i like the idea, but i'm not sure i like the impl described
18:23:08 <ayoung> this one mine?
18:23:13 <lhcheng> #vote abstain
18:23:15 <stevemar> ayoung: no, henrynash's
18:23:23 <david8hu> #vote abstain
18:23:31 <stevemar> getting the default configuration from /domain-config
18:23:34 <notmorgan> 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 <topol> #vote yes
18:23:39 <ayoung> #vote yes
18:24:06 <stevemar> sounds like there is work to do here
18:24:09 <stevemar> #endvote
18:24:10 <dstanek> #vote yes
18:24:10 <openstack> Voted on "Target "Enable retrieval of default values of domain config options" to Mitaka?" Results are
18:24:11 <openstack> Yes (4): gyee, ayoung, topol, stevemar
18:24:12 <openstack> Abstain (7): lbragstad, lhcheng, bknudson, marekd, david8hu, dolphm, davechen
18:24:16 <dstanek> if we can fix the API
18:24:30 <stevemar> dstanek comment on the spec with your concerns
18:24:35 <shaleh> the review is all positive currently
18:24:36 <dstanek> stevemar: will do
18:24:40 <henrynash> dstanek: yep happy to work with you
18:24:41 <ayoung> OK...if any of you abstaining cowards want to hold this up, -2 it now or live with it
18:24:44 <ayoung> :)
18:24:51 <stevemar> henrynash: you are creating as many specs as ayoung!
18:24:56 <stevemar> #startvote Target "Allow url-safe project and domain names to be optionally enforced" to Mitaka? Yes, No, Abstain
18:24:57 <openstack> 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 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
18:25:01 <lbragstad> #link https://review.openstack.org/#/c/248083/
18:25:06 <shaleh> #vote yes
18:25:07 <ayoung> stevemar, we've lived with the same broken windows for the same length of time
18:25:08 <notmorgan> ayoung: see my previous statement. i wont block it cause i really can't offer something better
18:25:10 <henrynash> one has to aim high, right?
18:25:11 <davechen> #vote yes
18:25:15 <ayoung> well, I've been here marginally longer, but...
18:25:18 <dolphm> lbragstad: thank you
18:25:28 <bknudson> #vote Abstain
18:25:30 <topol> #vote Abstain
18:25:36 <dolphm> #vote yes
18:25:38 <lhcheng> #vote yes
18:25:40 <gyee> #vote yes
18:25:42 <dstanek> #vote yes
18:25:44 <lbragstad> #vote yes
18:25:48 <notmorgan> henrynash: is unicode/utf-8 handled here?
18:25:48 <ayoung> #vote yes-but-I-am-a-coauthor
18:25:49 <openstack> ayoung: yes-but-I-am-a-coauthor is not a valid option. Valid options are Yes, No, Abstain.
18:25:52 <notmorgan> before i vote?
18:26:04 <ayoung> notmorgan, no
18:26:06 <notmorgan> then
18:26:07 <notmorgan> #vote no
18:26:14 <ayoung> notmorgan, we are saying to start just alpha-num
18:26:16 <shaleh> notmorgan: I called it out in my review
18:26:17 <marekd> #vote yes
18:26:22 <notmorgan> that's fine.
18:26:24 <ayoung> we start off strict, make less strict over time
18:26:26 <notmorgan> i'm happy to be a dissenter here
18:26:39 <breton> yay, the first one "no" for today
18:26:40 <ayoung> notmorgan, you would say yes if it accepted unicode?
18:26:41 <stevemar> notmorgan: is that your only concern
18:26:42 <stevemar> ?
18:26:49 <notmorgan> stevemar: that is my only concern
18:26:59 <stevemar> #vote yes
18:26:59 <notmorgan> many deployments use unicode/utf-8
18:27:01 <shaleh> not allowing users to use umlauts is a pretty big deal
18:27:17 <bknudson> DNS doesn't support umlauts as far as I know
18:27:18 <stevemar> damn umlauts
18:27:19 <notmorgan> and i don't want us to start on a path that relies on url-safe w/o that included
18:27:27 <shaleh> BUT, users with unicode can choose not to enable thise
18:27:30 <marekd> bknudson: i think it does support special chars
18:27:34 <notmorgan> so, interop will suck.
18:27:41 <bknudson> you'd have to do punycode or whatever.
18:27:44 <notmorgan> this is an end-user impacting thing as well.
18:27:54 <ayoung> notmorgan, we are talking about using this to create URLs
18:28:10 <ayoung> so, the end result needs to be passed, as is, into the URL
18:28:17 <notmorgan> ayoung: and afaict this is backwards incompat
18:28:25 <ayoung> an umlauted chracter can be escaped and used that way, its just not what Keystone would store
18:28:29 <ayoung> No it does not
18:28:39 <ayoung> it is a optional feature for moving forward
18:28:50 <notmorgan> except if we *have* this we will build on it
18:28:54 <ayoung> it explicitly is opt in, and for netst projects to be built into an URL scheme
18:28:59 <notmorgan> and it will become defacto-required for other things
18:29:07 <notmorgan> so, i stand by the #no until that is addressed
18:29:12 <ayoung> notmorgan, it is addressed
18:29:14 <notmorgan> like i said, i am happy to be the dissenter here
18:29:20 <dolphm> 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 <notmorgan> i wont -2 block it
18:29:23 <ayoung> the same way you would have it in an exisint URL
18:29:32 <ayoung> dolphm, same reason:
18:29:44 <ayoung> 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 <shaleh> so the user at some point will need to use %843 or the like
18:30:25 <dstanek> this reminds be of blogging software that have a name for a post and also a slug that is url safe
18:30:32 <ayoung> 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 <shaleh> dstanek: agreed
18:30:47 <notmorgan> anyway.
18:30:56 <stevemar> sounds like theres still some issues here too :(
18:30:57 <ayoung> so...a utility to make sure that a non -url safe one becoems URL safe would be fine
18:31:00 <stevemar> #endvote
18:31:01 <openstack> Voted on "Target "Allow url-safe project and domain names to be optionally enforced" to Mitaka?" Results are
18:31:02 <openstack> Yes (9): gyee, dstanek, lhcheng, davechen, marekd, shaleh, lbragstad, dolphm, stevemar
18:31:03 <openstack> Abstain (2): bknudson, topol
18:31:04 <openstack> No (1): notmorgan
18:31:09 <ayoung> but we need to ensure the post-processed value is URL safe.
18:31:31 <notmorgan> clearly addressing this for end-user interop as well as deployments moving forward is important.
18:31:37 <shaleh> notmorgan: ++
18:31:49 <stevemar> so though overwhelmingly yes, we should address the concerns in the specs
18:31:51 <shaleh> users will complain
18:31:51 <stevemar> spec*
18:31:59 <gyee> yes understood, interop is important
18:32:17 <dstanek> https://docs.djangoproject.com/en/1.8/ref/utils/#django.utils.text.slugify
18:32:23 <notmorgan> so i stand by my dissent. feel free to approve if you wish to override it.
18:32:32 <dstanek> that's the way i do it when writing similar things in django
18:32:50 <stevemar> 7 more to go!
18:32:59 <stevemar> #startvote Target "Public/Private IdPs" to Mitaka? Yes, No, Abstain
18:32:59 <shaleh> we aint gonna make it
18:32:59 <openstack> Begin voting on: Target "Public/Private IdPs" to Mitaka? Valid vote options are Yes, No, Abstain.
18:33:00 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
18:33:03 <lbragstad> #link https://review.openstack.org/#/c/209941/
18:33:09 <ayoung> #vote no
18:33:11 <marekd> #vote yes
18:33:12 <stevemar> thanks for the links lbragstad
18:33:17 <stevemar> #vote yes
18:33:18 <ayoung> I am not going to implement
18:33:23 <stevemar> pending we can get resources....
18:33:25 <marekd> ayoung: why?
18:33:36 <shaleh> I am willing to work on it, but the current spec needs a lot of love
18:33:43 <bknudson> #vote abstain
18:33:45 <ayoung> marekd, I don't have the time or the driving need to.
18:33:45 <marekd> shaleh: so go for it!
18:33:49 <gyee> #vote abstain
18:33:53 <marekd> ayoung: fair enough
18:33:53 <dolphm> #vote yes
18:33:54 <gyee> that spec needs a lot of work
18:33:55 <shaleh> I'd like to see if we can work this together with marek's proposal for SP
18:33:59 <topol> #vote abstain
18:34:01 <lhcheng> #vote abstain
18:34:04 <davechen> #vote abstain
18:34:05 <dstanek> #vote yes
18:34:05 <dolphm> there's a totally valid problem to be solved here
18:34:10 <ayoung> lets approve in backlog, and, if we get it done,  great
18:34:11 <stevemar> dolphm: yep
18:34:14 <dolphm> gyee: agree
18:34:16 <shaleh> ayoung: ++
18:34:19 <notmorgan> #vote no
18:34:19 <ayoung> agreed, which is why I did not abandon it
18:34:21 <stevemar> i'm okay with this going to backlog
18:34:22 <topol> dolphm, agree but the spec needs work
18:34:29 <notmorgan> my no is "the spec feels like it is missing a lot"
18:34:29 <henrynash> #vote no
18:34:35 <notmorgan> not because i dislike the idea
18:34:35 <dstanek> who will actually implement it?
18:34:37 <shaleh> notmorgan: you are not wrong
18:34:39 <topol> what notmorgan said
18:34:45 <henrynash> (based on spec needs much more work)
18:34:55 <ayoung> shaleh, you want to take it over, just leave me on as co-author and it is yours
18:34:57 <shaleh> dstanek: if we can get the spec hammered out I should be able to help
18:35:02 <stevemar> it's also missing API changes
18:35:04 <dolphm> whoever implements this needs to start by taking over the spec
18:35:05 <stevemar> #vote no
18:35:12 <stevemar> dolphm: yeah
18:35:20 <ayoung> 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 <lbragstad> #vote abstain
18:35:23 <shaleh> stevemar: is that no becuase the current spec sucks or no because the idea is wrong?
18:35:24 <gyee> dolphm, I think shaleh wants to volunteer :)
18:35:37 <stevemar> shaleh: the idea is pretty easy, we've had it around for a while
18:35:38 <shaleh> no, spec hammered out by Friday is not happening
18:35:45 <shaleh> simple as that
18:35:47 <breton> why do we vote for it? It's targeted to the backlog.
18:35:49 <ayoung> ok, then backlog it for now
18:35:54 <shaleh> this spec is reallty too simplistic
18:35:57 <ayoung> ++
18:36:10 <stevemar> oh shoot, i didn't mean to include backlog specs
18:36:15 <stevemar> whoops
18:36:21 <stevemar> #endvote
18:36:22 <openstack> Voted on "Target "Public/Private IdPs" to Mitaka?" Results are
18:36:23 <openstack> Yes (3): dstanek, dolphm, marekd
18:36:24 <openstack> Abstain (6): gyee, lbragstad, lhcheng, davechen, topol, bknudson
18:36:26 <openstack> No (4): henrynash, ayoung, notmorgan, stevemar
18:36:28 <shaleh> marekd: sync up with me afterwards
18:36:31 <ayoung> can we do Make keystone fully fledged SAML2 Service Provider  last
18:36:36 <stevemar> ayoung: yes
18:36:37 <ayoung> I think that will have some discussion
18:36:49 <stevemar> #startvote Target "Expand endpoint filters to service providers" to Mitaka? Yes, No, Abstain
18:36:50 <openstack> Begin voting on: Target "Expand endpoint filters to service providers" to Mitaka? Valid vote options are Yes, No, Abstain.
18:36:51 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
18:36:52 <lbragstad> #link https://review.openstack.org/#/c/188534/
18:37:12 <lbragstad> I think the idea is fine, most of my comments were nits
18:37:17 <stevemar> i'd be happy to review this one
18:37:18 <ayoung> does anyone have a strenuous objection to this one?
18:37:40 <bknudson> #vote abstain
18:37:41 <lbragstad> i don't think it needs to be it's entirely own API though
18:37:43 <stevemar> i think there is concern about the fact that 'service providers' aren't in the catalog to begin with
18:37:45 <shaleh> I am not sold on wedging it into endpoint filter
18:37:51 <marekd> lbragstad: it is not...
18:38:19 <marekd> shaleh: lol, last time stevemar advised on extending OS-EP-FILTER
18:38:20 <notmorgan> this needs to happen somehow.
18:38:23 <notmorgan> i think
18:38:25 <marekd> notmorgan: yes.
18:38:30 <shaleh> agreed
18:38:32 <notmorgan> but how, i don't really care.
18:38:37 <dstanek> shaleh: ++
18:38:38 <notmorgan> so i fthis is the best way, we do it this way
18:38:39 <ayoung> How do we list Service providers now?  Its a deliberate API call, right?
18:38:41 <lbragstad> #vote abstain
18:38:52 <marekd> ayoung: no, it's in the token response
18:38:55 <lbragstad> only because I don't have very many suggestions on how to fix it
18:38:59 <ayoung> oh..then this is the right way
18:39:15 <breton> #vote abstain
18:39:16 <henrynash> #vote yes
18:39:23 <ayoung> ah...is it becasue we consider that p[ortion of the token response "not the service catalog" that this is up for debate?
18:39:31 <marekd> ayoung: it's in the token response, not in the service catalog. that's why it's not a pure reuse of endpoint filtering, rather extension.
18:39:33 <davechen> #vote abstain
18:39:33 <stevemar> ayoung: yep
18:39:36 <topol> #vote yes
18:39:42 <ayoung> #vote yes
18:39:45 <gyee> we still have an issue to hash out
18:39:52 <shaleh> #vote yes
18:39:55 <gyee> do we care about inheritance
18:40:00 <stevemar> gyee: it may be an implementation detail
18:40:00 <lhcheng> #vote abstain
18:40:04 <gyee> that's an important one
18:40:23 <gyee> #vote yes, only if we include inheritance
18:40:24 <openstack> gyee: yes, only if we include inheritance is not a valid option. Valid options are Yes, No, Abstain.
18:40:27 <ayoung> gyee, does it effect the decisions on endpoint filtering?
18:40:27 <shaleh> marekd: I would prefer it to have its own filter system or that we expand endpoint filter to be "filter things"
18:40:39 <dolphm> #vote abstain
18:40:49 <gyee> ayoung, it does, if we don't support inheritance, that's a big UX gap
18:40:51 <stevemar> sounds like this may need some tweaking
18:41:06 <stevemar> #endvote
18:41:07 <openstack> Voted on "Target "Expand endpoint filters to service providers" to Mitaka?" Results are
18:41:09 <openstack> Yes (4): henrynash, shaleh, topol, ayoung
18:41:10 <openstack> Abstain (6): lbragstad, lhcheng, bknudson, dolphm, davechen, breton
18:41:11 <marekd> stevemar: like tweaking what?
18:41:17 <ayoung> gyee, is it something that can be solved during the dev process?
18:41:18 <gyee> SP usually tight to a domain/top level project
18:41:35 <gyee> ayoung, no, we need to be clear on the API design
18:41:39 <ayoung> gyee, but that is also the general case with Endpoint filtering
18:41:47 <stevemar> a few more to go
18:41:52 <stevemar> #startvote Target "Online schema migration" to Mitaka? Yes, No, Abstain
18:41:53 <openstack> Begin voting on: Target "Online schema migration" to Mitaka? Valid vote options are Yes, No, Abstain.
18:41:54 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
18:41:55 <stevemar> this one is interesting
18:41:59 <lbragstad> #link https://review.openstack.org/#/c/245186/
18:42:01 <marekd> #vote abstain
18:42:06 <gyee> ayoung, endpoint filter is per project, not domain
18:42:06 <xek_> I'm championing it
18:42:11 <stevemar> i like the intention and xek_ seems to have the bandwidth
18:42:14 <davechen> #vote Yes
18:42:14 <stevemar> hi xek_!
18:42:15 <shaleh> #vote abstain
18:42:19 <stevemar> #vote yes
18:42:23 <henrynash> #vote yes
18:42:37 <stevemar> it's well scoped and mostly tests that we don't shoot ourselves in the foot
18:42:40 <notmorgan> if there are enginerring resources comitted to it
18:42:43 <lbragstad> I had a lot of questions on that spec
18:42:47 <notmorgan> i'm a stong yes for this
18:42:53 <lbragstad> but it looks like a new version was pushed,
18:43:00 <notmorgan> but... i need to see commitment for the resources
18:43:01 <gyee> lbragstad, yeah, that spec still need more work
18:43:08 <ayoung> I like it, but he needs more lead time for discussion
18:43:10 <gyee> I can't comprehend most of it
18:43:11 <bknudson> #vote abstain
18:43:12 <lbragstad> if xek_ has the time, i'll be happy to review
18:43:13 <dstanek> can this actually be completed and reviewed this cycle?
18:43:15 <lbragstad> #vote yes
18:43:16 <notmorgan> stevemar: is xek_ committed to make it a thing?
18:43:21 <xek_> I have time
18:43:21 <gyee> #vote abstain
18:43:22 <lhcheng> #vote abstain
18:43:28 <ayoung> #vote no
18:43:34 <xek_> I also want to help reviewing patchsets with schema changes
18:43:34 <stevemar> notmorgan: no idea, i have no idea who xek_ is :)
18:43:39 <topol> #vote yes
18:43:40 <ayoung> and submit it to back log
18:44:01 <gyee> plus, this is not a Keystone thing, this is a OpenStack thing
18:44:05 <notmorgan> stevemar: then i'm a no
18:44:05 <stevemar> ayoung: disagree, submitter is willing to do the work
18:44:07 <ayoung> xek_, are you here?
18:44:08 <notmorgan> #vote no
18:44:10 <gyee> what good does it do we can only rolling upgrade Keystone
18:44:12 <breton> I am a little meh about it, especially for Mitaka
18:44:13 <xek_> ayoung, yes
18:44:17 <notmorgan> gyee:  it is important
18:44:18 <dstanek> stevemar: but will it be reviewed?
18:44:19 <davechen> the impl is just a testcase and the code is up for review. notmorgan
18:44:25 <notmorgan> gyee: no-downtime upgrade is good.
18:44:27 <ayoung> xek_, you have a working impl already?
18:44:28 <stevemar> dstanek: sure, i'll review it
18:44:32 <gyee> my point is this needs to work holistically
18:44:32 <xek_> breton, nova also supports it
18:44:32 <bknudson> nova and other projects already have rolling upgrade
18:44:34 <notmorgan> davechen: that isn't clear from the spec to me
18:44:40 <notmorgan> davechen: that it's really *ready to go*
18:44:43 <xek_> ayoung, yes, the unit test is in review already
18:44:45 <ayoung> #vote Yes
18:44:47 <notmorgan> so.
18:44:51 <ayoung> OK, we can do this
18:44:53 <notmorgan> i can change the vote.
18:45:03 <notmorgan> #vote yes
18:45:07 <stevemar> vote ending soon...
18:45:11 <stevemar> #endvote
18:45:12 <notmorgan> IF we have resources comitted to making it happen
18:45:13 <openstack> Voted on "Target "Online schema migration" to Mitaka?" Results are
18:45:14 <openstack> Yes (7): lbragstad, ayoung, notmorgan, davechen, topol, henrynash, stevemar
18:45:14 <notmorgan> early in this cycle
18:45:15 <openstack> Abstain (5): lhcheng, bknudson, gyee, marekd, shaleh
18:45:30 <stevemar> bknudson clearly wants no new work this cycle :)
18:45:31 <bknudson> voting yes means you're pledging resources to make it happen.
18:45:35 <xek_> notmorgan, I have the resources :)
18:45:37 <ayoung> notmorgan, yeah, that was my concern, but I think this is a good thing...
18:45:50 <stevemar> #startvote Target "Unified delegation spec" to Mitaka? Yes, No, Abstain
18:45:51 <openstack> Begin voting on: Target "Unified delegation spec" to Mitaka? Valid vote options are Yes, No, Abstain.
18:45:52 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
18:45:56 <stevemar> #vote abstain
18:45:58 <marekd> #vote abstain
18:46:00 <notmorgan> bknudson: nope. i'm voting yes as a "i'm a spec-core and think this is good"
18:46:00 <lbragstad> #link https://review.openstack.org/#/c/189816/
18:46:03 <dstanek> i'm a little worried about the cruft that will accumulate
18:46:09 <lbragstad> #vote abstain
18:46:12 <notmorgan> #vote abstain
18:46:14 <stevemar> i am woefully uneducated about this spec, and that's my fault
18:46:17 <topol> notmorgan +++
18:46:18 <notmorgan> i really don't have enough info to weigh in
18:46:18 <ayoung> I think, also, that our migrations are mature enough we should not be hitting too many column drops.  Being safe about them is sane
18:46:22 <breton> wait
18:46:23 <davechen> #vote abstain
18:46:31 <dstanek> #vote abstain
18:46:31 <breton> stevemar: it is targeted to backlog
18:46:32 <lhcheng> #vote abstain
18:46:36 <bknudson> #vote abstain
18:46:39 <stevemar> breton: thanks!
18:46:46 <ayoung> #vote Yes
18:46:52 <henrynash> #vote no
18:46:55 <topol> #vote abstain
18:47:05 <breton> #vote abstain
18:47:06 <notmorgan> just end the vote if it's backlog and lets move on
18:47:12 <breton> ++
18:47:26 <henrynash> (baed on spec needs too much work)
18:47:35 <ayoung> notmorgan, it was submitted to backlog a while back, but he's been working on it for two releases now
18:47:36 <stevemar> breton: and it's showing... looks like i'm not along in not reviewing it
18:47:36 <dolphm> #vote yes
18:47:37 <stevemar> ending vote early, it's backlogged
18:47:38 <stevemar> #endvote
18:47:39 <openstack> Voted on "Target "Unified delegation spec" to Mitaka?" Results are
18:47:40 <openstack> Yes (2): dolphm, ayoung
18:47:42 <openstack> Abstain (10): dstanek, notmorgan, lhcheng, davechen, marekd, lbragstad, topol, bknudson, breton, stevemar
18:47:43 <openstack> No (1): henrynash
18:47:48 <ayoung> amakarov, presented at the midcycle
18:47:51 <stevemar> getting some useful data out of this
18:47:56 <stevemar> thanks for putting up with it guys
18:48:02 <stevemar> #startvote Target "Spec for optional Project ID via the Project creation API." to Mitaka? Yes, No, Abstain
18:48:03 <openstack> Begin voting on: Target "Spec for optional Project ID via the Project creation API." to Mitaka? Valid vote options are Yes, No, Abstain.
18:48:04 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
18:48:12 <amakarov> ayoung, it's still in design stage
18:48:14 <dolphm> stevemar: i expect to see a pie chart on my desk tomorrow
18:48:15 <gyee> what are we voting on now?
18:48:24 <stevemar> dolphm: along with the TPS report
18:48:26 <topol> lbragstad hook us up
18:48:26 <gyee> things scroll too fast on my screen
18:48:26 <ayoung> amakarov, so do you think you can have it done in Mitaka anyway?
18:48:29 <lbragstad> #link https://review.openstack.org/#/c/241346/
18:48:32 <gyee> that or my IRC client is broken
18:48:32 <topol> :-)
18:48:34 <stevemar> topol: lol
18:48:46 <shaleh> the submitter has not been responding
18:49:05 <amakarov> ayoung, if such hurry is necessary I can focus on that, of course
18:49:09 <henrynash> #vote no
18:49:13 <stevemar> shaleh: but do we agree that this is something we should try and get into mitaka?
18:49:18 <stevemar> #vote no
18:49:18 <bknudson> #vote abstain
18:49:22 <gyee> #vote I don't know wtf I am voting
18:49:23 <openstack> gyee: I don't know wtf I am voting is not a valid option. Valid options are Yes, No, Abstain.
18:49:26 <notmorgan> the spec needs work. the idea i dislike, i think we (unfortunately) need it
18:49:29 <stevemar> gyee: lol
18:49:30 <ayoung> gyee, optional project ID
18:49:35 <topol> #vote no
18:49:37 <dolphm> #vote no
18:49:39 <dstanek> #vote no
18:49:41 <notmorgan> and i would like it to be something we can lock-down to say cloud-admin
18:49:43 <lbragstad> #vote no
18:49:47 <notmorgan> so... with that
18:49:50 <gyee> #vote no
18:49:53 <stevemar> i think it needs a more dedicated resource and thought out spec
18:49:54 <dolphm> all of hte impact sections are blank here, which is not acceptable for something so much potential for introducing bugs
18:49:55 <notmorgan> #vote no
18:49:55 <ayoung> dolphm, you were the one that initially balked at the idea.  I think it is a good idea, but don't *need* it in Mitaka
18:50:01 <notmorgan> because we need a resource on it
18:50:02 <shaleh> notmorgan: ++ to everything you said
18:50:06 <dolphm> ayoung: agree
18:50:16 <notmorgan> not because it's a bad idea.
18:50:17 <dolphm> ayoung: we just need to think through it, which this spec has not demonstrated yet
18:50:22 <stevemar> well this was helpful, i tohught there were stronger supporters for this idea
18:50:29 <stevemar> #endvote
18:50:30 <openstack> Voted on "Target "Spec for optional Project ID via the Project creation API." to Mitaka?" Results are
18:50:31 <openstack> Abstain (1): bknudson
18:50:32 <openstack> No (8): gyee, lbragstad, notmorgan, dstanek, dolphm, topol, henrynash, stevemar
18:50:34 <notmorgan> stevemar: i hate the idea. we need something like it.
18:50:39 <stevemar> 2 more! we can make it
18:50:39 <notmorgan> for at least the cloud admin.
18:50:41 <ayoung> dolphm, would really appreciate having your concerns about it in acomment on the review.
18:50:48 <ayoung> Would not be willing to go forward without that
18:50:53 <stevemar> #startvote Target "Basic API spec for managing Policy rules in a database" to Mitaka? Yes, No, Abstain
18:50:54 <openstack> Begin voting on: Target "Basic API spec for managing Policy rules in a database" to Mitaka? Valid vote options are Yes, No, Abstain.
18:50:55 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
18:50:57 <lbragstad> #link https://review.openstack.org/#/c/184903/
18:51:02 <stevemar> #vote no
18:51:05 <ayoung> #vote no
18:51:09 <henrynash> #vote no
18:51:10 <ayoung> that should not be Mitaka
18:51:13 <ayoung> it is backlog
18:51:13 <stevemar> does this even align with what we're doing?
18:51:17 <lbragstad> #vote no
18:51:20 <notmorgan> #endvote
18:51:22 <bknudson> this one depends on https://review.openstack.org/#/c/133814/23
18:51:22 <notmorgan> >>
18:51:23 <stevemar> #endvote
18:51:23 <openstack> Voted on "Target "Basic API spec for managing Policy rules in a database" to Mitaka?" Results are
18:51:24 <openstack> No (4): henrynash, lbragstad, ayoung, stevemar
18:51:26 <gyee> #vote no
18:51:27 <topol> #vote no
18:51:35 <stevemar> last one
18:51:36 <dolphm> #vote belatedly
18:51:38 <stevemar> #startvote Target "Make keystone fully fledged SAML2 Service Provider" to Mitaka? Yes, No, Abstain
18:51:39 <openstack> Begin voting on: Target "Make keystone fully fledged SAML2 Service Provider" to Mitaka? Valid vote options are Yes, No, Abstain.
18:51:41 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
18:51:44 <dolphm> #vote yes
18:51:46 <stevemar> #vote no
18:51:52 <stevemar> dolphm: why?
18:51:52 <gyee> #vote yes
18:51:58 <notmorgan> so, this is anothe rone of those we *probably* need at this point
18:52:01 <bknudson> #vote abstain
18:52:07 <davechen> #vote abstain
18:52:10 <breton> #vote abstain
18:52:11 <lhcheng> #vote abstain
18:52:15 <notmorgan> but i don't feel strongly about it.
18:52:17 <stevemar> whoa, i was not expecting any yes'es
18:52:18 <dolphm> stevemar: because it's a pain point for operators and we knew that going into icehouse
18:52:19 <notmorgan> #vote abstain
18:52:20 <ayoung> can someone voice why we need this before we stop the vote?
18:52:28 <notmorgan> actually...
18:52:30 <dolphm> operators are now feeling that pain
18:52:31 <notmorgan> #vote yes
18:52:41 <gyee> ayoung, dynamic configuration via API
18:52:50 <henrynash> #vote no
18:52:53 <marekd> #vote yes
18:52:56 <gyee> free ourselves from CMS
18:53:00 <henrynash> (but willing to be convinced)
18:53:07 <notmorgan> gyee: ok hold up
18:53:17 <topol> I could use more context on what the pain points are how this resolves them
18:53:20 <gyee> henrynash, why do we need API on per-domain config management?
18:53:26 <gyee> henrynash, same deal
18:53:30 <dolphm> henrynash: because when your domain admins each have their own idp, then you need self-service
18:53:32 <samueldmq> gyee: wasn't this the reson we didn't want dynamic policies ? keystone shouldn't do cms work ?
18:53:32 <lbragstad> 7 minutes left
18:53:43 <notmorgan> we have a baaaad ux on admin vs cms already
18:53:46 <shaleh> dolphm: ++
18:53:48 <notmorgan> is this making it better or worse?
18:53:56 <ayoung> I fear that this pushes us back toward "keystone is an identituy provider"
18:53:56 <dolphm> henrynash: are you going to bounce your keystone cluster every time one of your domain admins once to give you fresh certs?
18:53:58 <ayoung> #vote no
18:54:05 <dolphm> s/once/wants/
18:54:06 * ayoung willing to change with good argument
18:54:07 <notmorgan> ayoung: i don't think it does.
18:54:08 <stevemar> whua? we're voting on saml2 spec
18:54:29 <shaleh> shibboleth is not presenting a solid UX
18:54:34 <notmorgan> ayoung: keystone *can* provide a proxy to Identity for other things, but it doesn't make keystone an identity provider
18:54:36 <shaleh> we need a reasonable alternative
18:54:37 <notmorgan> subtle difference
18:54:48 <gyee> we don't need the entire shibd, we only use a fraction of it
18:54:48 <shaleh> this spec offers one
18:54:50 <ayoung> notmorgan, Then what does this spec mean?
18:54:51 <marekd> #vote no
18:54:56 <notmorgan> shaleh: i also don't think that is the same thing.
18:55:00 <dolphm> gyee: true
18:55:05 <lbragstad> this is still the policy vote,
18:55:06 <topol> #vote Abstain
18:55:07 <shaleh> notmorgan: agreed, but it is driving this
18:55:13 <marekd> gyee: oh, we do need whole shibd
18:55:14 <stevemar> #showvote
18:55:14 <openstack> Yes (3): gyee, dolphm, notmorgan
18:55:14 <dolphm> ayoung: that we won't depend on shib or mellon
18:55:15 <openstack> Abstain (5): lhcheng, bknudson, topol, davechen, breton
18:55:16 <openstack> No (4): henrynash, ayoung, marekd, stevemar
18:55:18 <notmorgan> shaleh: then we need to go back to the drawing board
18:55:22 <lbragstad> nevermind
18:55:28 <stevemar> marekd: you are voting no? it's your spec
18:55:29 <notmorgan> #changevote no
18:55:30 <gyee> marekd, no, do you do policy validations?
18:55:32 <notmorgan> :P
18:55:43 <topol> marekd, the self hating core
18:55:49 <shaleh> hah
18:55:53 <dstanek> marekd: voting no?
18:55:54 <lbragstad> how does everyone feel about the alternative in the spec?
18:56:02 <shaleh> there is confusion over what is the active vote apparently
18:56:05 <marekd> lbragstad: i actually think it should be enough
18:56:10 <marekd> stevemar: ^^
18:56:29 <ayoung> Am I misunderstanding what we mean by "Service provider" here?
18:56:36 <lbragstad> #link https://review.openstack.org/#/c/244694/
18:56:44 <dolphm> marekd: this is also something big enough that it might be worthwhile to pursue the implementation and demo it working *before* pursuing the spec.
18:56:54 <shaleh> dolphm: ++
18:57:02 <stevemar> dolphm: ++
18:57:02 <topol> dolphm ++
18:57:07 <marekd> dolphm: poc king of thing on my own keystone fork
18:57:10 <topol> #vote no
18:57:13 <dstanek> #vote no
18:57:21 <dolphm> marekd: poc in a gerrit review :)
18:57:26 <stevemar> #endvote
18:57:27 <openstack> Voted on "Target "Make keystone fully fledged SAML2 Service Provider" to Mitaka?" Results are
18:57:28 <openstack> Yes (3): gyee, dolphm, notmorgan
18:57:29 <openstack> Abstain (4): lhcheng, bknudson, davechen, breton
18:57:30 <openstack> No (6): dstanek, ayoung, marekd, topol, henrynash, stevemar
18:57:38 <stevemar> okay, i'll write up a summary of this
18:57:42 <gyee> marekd, we have an inhouse POC, without relay state management
18:57:45 <stevemar> i hope you guys found it useful
18:57:52 <gyee> marekd, let me write you an email later
18:58:01 <bknudson> we should do this every week
18:58:03 <marekd> stevemar: we did, but next time we should do this 1-2 weeks before the freeeze
18:58:10 <marekd> gyee: sure.
18:58:10 <topol> speed dating specs, Keystone stylke
18:58:14 <stevemar> bknudson: your sarcasm is seeping through
18:58:15 <shaleh> bknudson: we would need a 90 min meeting :-)
18:58:23 <shaleh> topol: ++
18:58:37 <stevemar> marekd: next time :)
18:58:47 <stevemar> thanks for putting up with my crazy idea
18:58:51 <dstanek> bknudson: i can see you writing an '#abstain' bot
18:58:52 <stevemar> dolphm: pie charts are coming
18:58:52 <marekd> stevemar: i am serious
18:59:00 <dolphm> stevemar: better be
18:59:12 <stevemar> thanks everyone, now review patches and specs! :)
18:59:17 <stevemar> #endmeeting