18:01:59 <morganfainberg> #startmeeting keystone
18:02:00 <openstack> Meeting started Tue Jun 10 18:01:59 2014 UTC and is due to finish in 60 minutes.  The chair is morganfainberg. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:02:01 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:02:04 <openstack> The meeting name has been set to 'keystone'
18:02:13 <morganfainberg> #topic Juno1 Milestone
18:02:29 <morganfainberg> #link https://launchpad.net/keystone/+milestone/juno-1
18:02:53 <dstanek> o/
18:02:55 <morganfainberg> Any changes that aren't gating by EOD today will be pushed toj2
18:03:13 <morganfainberg> we have 2 changes that need eyes (afaik)
18:03:25 <morganfainberg> #link https://review.openstack.org/#/c/99075/
18:03:28 <morganfainberg> #link https://review.openstack.org/#/c/74214/
18:03:37 <gyee> gating is pretty risky these days :)
18:03:43 <stevemar> i'll take a look at those today
18:03:51 <dstanek> i will too
18:03:56 <morganfainberg> gyee, thats why today is the goal, gives us 2 days?
18:03:59 <ayoung> last one is pretty solid
18:04:06 <ayoung> recommend we get it in and let people beat on it
18:04:25 <morganfainberg> lets get the spec for that one in as well
18:04:39 <stevemar> ayoung, ++ I think thats the best course of action
18:04:41 <morganfainberg> but we'll hold that topic until later in the meeting (we have a whole section on it!)
18:05:07 <morganfainberg> ok moving on, we have a bunch to cover today
18:05:13 <morganfainberg> #topic Hackathon Information
18:05:25 <morganfainberg> #link http://dolphm.com/openstack-keystone-hackathon-for-juno
18:05:26 <henrynash> for mine, teh only changes I will push in later today are moving the ID creation from controller to manager (few real lines of code to change, just lots of tetsing mechanical changes)
18:05:32 <henrynash> sorry, topic has moved on
18:05:55 <morganfainberg> henrynash, ah.
18:05:56 <morganfainberg> #link https://docs.google.com/forms/d/1TlJ2u1ucxpia0SkWbkRo-_5DmVfXEQG7GKYVLc9abfc/viewform?usp=send_form
18:06:06 <morganfainberg> i think everyone has filled out the form
18:06:25 <morganfainberg> no new info... just fill out the form if you haven't and you're going
18:06:44 <morganfainberg> see everyone in July in San Antonio
18:07:04 <stevemar> should be fun
18:07:14 <morganfainberg> henrynash, we can talk about the differences in spec vs what is in the review shortly
18:07:25 <henrynash> ok
18:07:38 <morganfainberg> #topic Spec Approval Requirements
18:07:55 <morganfainberg> dolphm isn't here, so we don't get his view on it.
18:08:20 <ayoung> morganfainberg, I'd say it needs to be  viewed by the team, with not major objections, and then at least two people go through a spec in depth
18:08:38 <ayoung> so anyone on the team can  -2  if it is really wrong
18:08:51 <ayoung> but we need a way to say "I've looked at it and nothing scares me"
18:09:05 <ayoung> which is why Iwas thinking "vote in the weekly meeting"
18:09:41 <morganfainberg> ayoung, a general thumbs up/thumbs down in the meeting and then a really in depth 2x+2 seems reasonable to me
18:10:11 <gyee> deal
18:10:19 <bknudson> let's try it
18:10:33 <morganfainberg> we should also corner dolphm later today for his input, but i think it lines up.
18:10:35 <dstanek> sounds reasonable to me
18:10:56 <morganfainberg> cool.
18:10:57 <morganfainberg> no complaints?
18:11:26 <morganfainberg> ok now moving onto the bulk of the meeting, the thumbs up/thumbs down for specifications
18:11:36 <morganfainberg> #topic Keystone Spec Approvals
18:11:42 <morganfainberg> ayoung, o/ this is all yours
18:11:54 <ayoung> OK..hoqdo we do votes here...
18:11:56 <morganfainberg> lead us through it
18:12:11 <morganfainberg> startvote i think.
18:12:25 <ayoung> First one up is
18:12:48 <ayoung> Service Token Composite Authorization
18:13:05 <morganfainberg> #link https://review.openstack.org/96315
18:13:11 <ayoung> Thanks
18:13:17 <ayoung> #startvote
18:13:18 <openstack> Only the meeting chair may start a vote.
18:13:20 <ayoung> hmmm
18:13:30 <gyee> heh
18:13:32 <morganfainberg> before we vote, any questions on the topic?
18:13:34 <dstanek> fail!
18:13:48 <bknudson> I haven't looked at it, but it looks doable to me.
18:13:58 <morganfainberg> Quick intro: this is providing a service-token (e.g. glance service user) to the auth-token middleware
18:13:59 <bknudson> from scanning through it now
18:14:11 <morganfainberg> then policy can act upon either the x-auth-token or x-service-token
18:14:14 <gyee> no major objection here
18:14:14 <bknudson> I think we discussed this on irc
18:14:25 <morganfainberg> bknudson, we did and at the summit
18:14:38 <ayoung> morganfainberg, what is policy.json going to look like for these?
18:14:39 <jamielennox> morganfainberg: i haven't gone through the spec in detail but it looks like what i remember from summit
18:14:56 <jamielennox> (so +1)
18:15:05 <morganfainberg> ayoung, TBD, but i think it will be %(service_user_id) or %(service_roles) vs %(role)
18:15:06 <dstanek> what's the 'different manner'?
18:15:33 <ayoung> morganfainberg, since you are chair, I think you have to #startvote
18:15:41 <ayoung> http://ci.openstack.org/meetbot.html#voting
18:15:41 <morganfainberg> ayoung, yeah sec
18:16:23 <bknudson> how about update the commit message to say it was discussed at meeting on 2014-06-10 and approved?
18:16:25 <morganfainberg> #startvote Service Token Composite Authorization, do we like the general approach? Yes, no
18:16:26 <openstack> Begin voting on: Service Token Composite Authorization, do we like the general approach? Valid vote options are Yes, no.
18:16:27 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
18:16:34 <bknudson> #vote Yes
18:16:43 <gyee> #vote hell yeah
18:16:43 <openstack> gyee: hell yeah is not a valid option. Valid options are Yes, no.
18:16:47 <ayoung> #vote Yes
18:16:55 <jamielennox> #vote yes
18:16:55 <morganfainberg> #vote yes
18:16:56 <henrynash> #vote yes
18:16:57 <gyee> #vote Yes
18:16:59 <stevemar> #vote yes
18:17:00 <dstanek> #vote yes
18:17:04 <morganfainberg> bknudson, i like the idea link to the summary showing approval.
18:17:33 <morganfainberg> everyone voted?
18:17:41 <stevemar> everyone but dolphm
18:17:55 <morganfainberg> o
18:17:56 <morganfainberg> #endvote
18:17:57 <openstack> Voted on "Service Token Composite Authorization, do we like the general approach?" Results are
18:17:58 <bknudson> too late dolphm, already decided
18:17:59 <openstack> Yes (8): gyee, dstanek, ayoung, morganfainberg, bknudson, jamielennox, henrynash, stevemar
18:18:12 <ayoung> OK next up
18:18:28 <jamielennox> i'll be interested to see how this one works in practice, i'm not sure how easy it'll be to craft policy that works with and without subject tokens
18:18:30 <ayoung> token versions independent from API versions
18:18:42 <morganfainberg> #link https://review.openstack.org/98464
18:18:55 <morganfainberg> this might actually be better suited for K
18:19:03 <morganfainberg> this would be what leads to the id-only tokens
18:19:11 <ayoung> So...
18:19:16 <bknudson> well, we're never going to change identity version again anyways
18:19:19 <ayoung> do we really want to do this just for Tokens?
18:19:26 <morganfainberg> it basically amkes token versions independant of the API version
18:19:27 <morganfainberg> bknudson, agree
18:19:40 <stevemar> 98464 -> seems no one has reviewed it but lance
18:19:41 <morganfainberg> ayoung, what would be the other options? for all objects (e.g. users, domains, etc)?
18:19:50 <bknudson> "microversioning"
18:19:53 <ayoung> I mean,  each of the various entities, or at least top level modules could benefit from this approach
18:19:59 <ayoung> why token more than, say, user?
18:20:09 <ayoung> er identity
18:20:26 <morganfainberg> ayoung, i think because we have a real need for limiting token size.
18:20:31 <morganfainberg> ayoung, vs a nice-to-have
18:20:40 <jamielennox> morganfainberg: this is being done as a querystring?
18:20:43 <morganfainberg> ayoung, would be my only (not so strong) argument
18:20:56 <morganfainberg> jamielennox, that was the original idea
18:21:01 <morganfainberg> default token version in config (or in the case of V2, the API controller)
18:21:07 <morganfainberg> overridable with a query string
18:21:52 <dstanek> i haven't read the spec...does it was what will vary based on the version?
18:21:55 <ayoung> accepts header?
18:22:00 <jamielennox> morganfainberg: i'm not sure that really makes sense, you would end up in a situation like /v3/auth/tokens?format=v2
18:22:09 <bknudson> y, let's figure out a way to do the microversioning
18:22:19 <bknudson> and let's not do it with a query parameter
18:22:22 <bknudson> use accepts header
18:22:25 <ayoung> OK,  I'm going to suggest we table this one until it gets more review
18:22:27 <morganfainberg> bknudson, ++ ok lets table this one and move towards micro-versioning.
18:22:46 <ayoung> next up
18:22:51 <bknudson> sounds like don't plan to do it for J anyways
18:22:56 <ayoung> api-validation blueprint
18:23:07 <morganfainberg> #link https://review.openstack.org/95957
18:23:17 <bknudson> hmm, don't see ldbragst
18:23:21 <bknudson> let me walk over
18:23:36 <ayoung> While we are waiting
18:23:54 <ayoung> please don;t have the name of the spec review begin with "add spec..."
18:23:59 <ayoung> Its like, duh
18:24:03 <ayoung> or as they say here
18:24:05 <ayoung> der
18:24:50 <bknudson> not in. I guess we've got a meeting scheduled over this one
18:25:19 <bknudson> well, I like the proposal
18:25:25 <morganfainberg> do we defer it then?
18:25:26 <morganfainberg> can vote anyway
18:25:29 <ayoung> I'm still OK with this one.  I'd like to see bknudson 's comments addressed, but the general approach is strong
18:25:33 <bknudson> this is one of the things on our security checklist for our products
18:25:55 <bknudson> only concern is breaking backwards compat
18:25:55 <morganfainberg> #startvote api-validation specification. Yes, No
18:25:55 <openstack> Unable to parse vote topic and options.
18:25:59 <dstanek> approach is good...i'm curious to see what this looks like with a fully fleshed out implementation
18:26:00 <bknudson> #vote Yes
18:26:08 <dstanek> #vote yes
18:26:10 <ayoung> try that again morganfainberg
18:26:10 <marekd> #vote yes
18:26:12 <morganfainberg> #startvote Do we accept the proposal for api-validation? Yes, No
18:26:13 <openstack> Begin voting on: Do we accept the proposal for api-validation? Valid vote options are Yes, No.
18:26:14 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
18:26:19 <ayoung> #vote yes
18:26:20 <marekd> #vote yes
18:26:22 <bknudson> #vote yes
18:26:22 <dstanek> #vote yes
18:26:26 <morganfainberg> #yote yes
18:26:43 <jamielennox> #vote yes
18:26:52 <stevemar> #vote yes
18:26:59 <henrynash> #vote yes
18:27:06 <morganfainberg> looks like everyone
18:27:07 <stevemar> i was happy with this one a few iterations ago
18:27:09 <morganfainberg> #endvote
18:27:10 <openstack> Voted on "Do we accept the proposal for api-validation?" Results are
18:27:11 <openstack> Yes (7): dstanek, ayoung, bknudson, marekd, jamielennox, henrynash, stevemar
18:27:13 <gyee> I am not comfortable voting on this one as I haven't gone through the details
18:27:25 <morganfainberg> gyee, ah, sorry missed you
18:27:30 * morganfainberg grumbles and learns to count
18:27:35 <bknudson> are we voting on the details or on the general approach?
18:27:42 <morganfainberg> general approach
18:27:44 <ayoung> next up was Cross Backend Unique Identifiers for User and Group Entities but I don't see it
18:27:48 <ayoung> did it merge?
18:27:52 <bknudson> I don't like the ugly error message, but other than that think it's a good idea
18:27:55 <morganfainberg> details are for the review
18:27:58 <bknudson> uniuque IDs merged
18:28:23 <bknudson> first spec!
18:28:25 <morganfainberg> henrynash, any updates on the spec vs what is up for the review?
18:28:26 <morganfainberg> before we move on?
18:28:32 <ayoung> gyee, OK...-1 the spec and up it to +1 or 2 when you are comforatable
18:29:00 <gyee> ayoung, thanks, I'll definitely review it today
18:29:01 <henrynash> morganfainberg: no, the only differences from the version posted right now and the spec are listed in limiations
18:29:06 <morganfainberg> ok
18:29:07 <henrynash> of the commit message
18:29:12 <ayoung> can we use bugs for spec bugs?
18:29:24 <ayoung> Like :spec for X says foo but should say bar.
18:29:38 <morganfainberg> ayoung, i'd just propose the change to the spec.
18:29:49 <ayoung> morganfainberg, fair enough
18:29:55 <morganfainberg> unless the spec is fully implemented, then bugs are probably the right approach
18:29:58 <ayoung> next up
18:30:08 <ayoung> r V3 extension advertisement
18:30:17 <bknudson> hey!
18:30:23 <ayoung> #link https://review.openstack.org/95973
18:30:24 <bknudson> any qs?
18:30:25 <morganfainberg> #link https://review.openstack.org/95973
18:30:31 <stevemar> ++++
18:30:32 <morganfainberg> i'm happy with it as is.
18:30:39 <stevemar> very happy with it as is
18:30:40 <bknudson> got a request from dolphm to have the router intercept the GET / request
18:30:46 <gyee> this is a no-brainer
18:30:48 <bknudson> so that's the approach proposed
18:30:55 <morganfainberg> bknudson, yeah that works.
18:30:57 <bknudson> rather than having the controller register
18:30:59 <ayoung> bknudson, ":	.. code-block:: javascript"
18:31:13 <morganfainberg> #startvote Accept V3 Extension Advertisement spec? yes, no
18:31:14 <openstack> Begin voting on: Accept V3 Extension Advertisement spec? Valid vote options are yes, no.
18:31:15 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
18:31:15 <jamielennox> bknudson: you don't intend to advertise these from GET / just /v3?
18:31:16 <bknudson> like is done with admin & public
18:31:18 <ayoung> #vote yes
18:31:23 <bknudson> jamielennox: right, just GET /v3.
18:31:25 <morganfainberg> #vote yes
18:31:27 <henrynash> #vote yes
18:31:29 <dstanek> #vote yes
18:31:31 <gyee> #vote yes
18:31:38 <stevemar> #vote yes
18:31:41 <jamielennox> #vote yes
18:32:06 <stevemar> ayoung, calling it javascript might just be a limitation of sphinx
18:32:12 <morganfainberg> marekd, you want to weigh in?
18:32:17 <marekd> haven't read it - don't wait :/
18:32:20 <bknudson> jamielennox: it would be tricky to have it work with GET / since the controllers don't get to see those.
18:32:26 <morganfainberg> marekd, ok
18:32:30 <morganfainberg> #endvote
18:32:31 <openstack> Voted on "Accept V3 Extension Advertisement spec?" Results are
18:32:32 <openstack> yes (7): gyee, dstanek, ayoung, morganfainberg, jamielennox, henrynash, stevemar
18:32:36 <jamielennox> bknudson: there has been the assumption until now that the information provided at /v3 is a subset of what is provided at /, it means if i hit the version control at / i don't have to do /v3
18:32:49 <ayoung> Web Authentication for SAML federated Keystone
18:32:59 <morganfainberg> #link https://review.openstack.org/96867
18:33:13 <marekd> ppl have some concerns here...
18:33:13 <stevemar> lots of questions on this one still
18:33:15 <bknudson> jamielennox: maybe there's a way to do it that I haven't thought of
18:33:17 <marekd> stevemar: ++
18:33:22 <ayoung> This one I would say is not quite full baked yet
18:33:34 <morganfainberg> should we table this one then?
18:33:45 <jamielennox> bknudson: i'm not saying the assumption is correct but its going to be a bit of a pain to do both
18:33:56 <ayoung> Its on the right track, but I think it might actually require some input from Horizon folks
18:33:58 <morganfainberg> ayoung, after this mind commenting on the specs that we table saying as much?
18:34:06 <ayoung> ++
18:34:08 <stevemar> yeah, so far no input from any horizon folks
18:34:25 <morganfainberg> reasonable to ask horizon to weigh in on this
18:34:38 <marekd> and what about addind a 'static webpage' tied directly to Keystone?
18:34:39 <ayoung> Table?
18:34:57 <morganfainberg> #action ayoung to comment on tabled specification reviews (why and what was decided)
18:34:59 <ayoung> Next up non-persistent-tokens
18:35:09 <morganfainberg> #link https://review.openstack.org/95976
18:35:28 <jamielennox> table, at the very least it should be an extension
18:35:36 <bknudson> I looked over this one and no real issues with it. Could use more details but I think it's workable
18:35:37 <morganfainberg> jamielennox, ++
18:35:41 <ayoung> bknudson, I assume your comments are detail oriented, not show stoppers?
18:35:53 <ayoung> any of them worth noting?
18:36:11 <bknudson> there was a question about whether it's discoverable or not
18:36:13 <morganfainberg> a lot of the work on this one is scaffolding so we can make the token presistence redundant
18:36:27 <ayoung> bknudson, I would say "no"
18:36:29 <bknudson> also it might be a good idea to split out the token object from persistent tokens
18:36:37 <ayoung> at least, I see no reason to make it discoverabl
18:36:42 <morganfainberg> bknudson, that is the data model bit.
18:36:45 <ayoung> the keystone server can validate using PKI
18:36:58 <morganfainberg> bknudson, it should be more explicit then.
18:37:28 <morganfainberg> any questions on the persistence of tokens spec?
18:37:34 <morganfainberg> erm non-persistence?
18:37:39 <ayoung> Note that this depends on widespread consumtion of revocation evetns
18:37:40 <ayoung> events
18:37:46 <ayoung> which is still WIP
18:38:02 <ayoung> but I don't think there is any question to the validity of the approach
18:38:04 <bknudson> is there a spec for remaining revocation events work?
18:38:19 <ayoung> bknudson, let me check
18:38:26 <gyee> morganfainberg, you may want the security folks to chime in on that one
18:38:30 <ayoung> not a new spec, but an old BP I think
18:38:57 <morganfainberg> gyee, ++ i'll add securityimpact
18:38:58 <bknudson> ok, I thought at this point we require specs.
18:39:03 <morganfainberg> bknudson, we do
18:39:06 <ayoung> https://blueprints.launchpad.net/python-keystoneclient/+spec/revocation-event-api
18:39:09 <dstanek> i haven't thought about this one enough to vote on it
18:39:30 <ayoung> but that does not indicate Auth Token middleware...I'll work up a spec for the Auth Token work.
18:39:37 <morganfainberg> ok
18:39:56 <morganfainberg> well lets quick vote, i'll add a 3rd option going forward, table
18:40:06 <morganfainberg> #startvote Accept Non-Persistence of tokens Spec? Yes, No, Table
18:40:06 <openstack> Begin voting on: Accept Non-Persistence of tokens Spec? Valid vote options are Yes, No, Table.
18:40:07 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
18:40:12 <bknudson> #vote table
18:40:13 <ayoung> #vote yes
18:40:19 <dstanek> #vote table
18:40:26 * morganfainberg abstains.
18:40:36 <gyee> #vote table
18:40:45 <jamielennox> #vote i love the approach but i think it's too soon
18:40:46 <openstack> jamielennox: i love the approach but i think it's too soon is not a valid option. Valid options are Yes, No, Table.
18:40:54 <jamielennox> :(
18:40:58 <jamielennox> #vote table
18:41:03 <marekd> #vote table
18:41:15 <henrynash> #vote yes
18:41:16 <ayoung> Are we really not happy with the spec?
18:41:26 <ayoung> It has dependencies, but the approach is right
18:41:29 <morganfainberg> ayoung, i think we need the revocations evtents spec
18:41:33 <morganfainberg> before we can accept this one
18:41:44 <ayoung> why?
18:41:52 <gyee> ayoung, I am not sure if we fully flush out the implications yet
18:41:55 <morganfainberg> w/o the dependencies, we can't implement this completely
18:42:03 <ayoung> We need Auth token middleware to accept them, but the logic cor that is well established
18:42:10 <ayoung> cor -> for
18:42:23 <ayoung> the API spec is up for review
18:42:31 <ayoung> and the events are part of the server
18:42:40 <jamielennox> also morganfainberg is lining up a lot of work for himself
18:42:54 <ayoung> so, no, I don't think we *need* it, but it can't hurt to have it laid out
18:42:56 <morganfainberg> ayoung, sure, i think if that spec was accepted then this one could be. lets revisit next week if its an issue i'll gut the persistence part and make it only the scaffolding work.
18:43:02 <ayoung> ++
18:43:06 <morganfainberg> #endvote
18:43:07 <openstack> Voted on "Accept Non-Persistence of tokens Spec?" Results are
18:43:08 <openstack> Table (5): bknudson, dstanek, gyee, marekd, jamielennox
18:43:10 <openstack> Yes (2): henrynash, ayoung
18:43:25 <ayoung> audit support for federation
18:43:26 <morganfainberg> tabled till next week, might require reduction in scope for J
18:43:38 <morganfainberg> #link https://review.openstack.org/97581
18:43:42 <bknudson> have not looked at this one
18:43:57 <stevemar> it's got a few issues with it
18:44:00 <morganfainberg> i think this one is fairly straightforward
18:44:06 <morganfainberg> but the issues are all in details not approach
18:44:13 <stevemar> i think i might upload a new version soon if topol doesn't get around to it
18:44:17 <gyee> yeah, this one seem like a no-brainer
18:44:23 <bknudson> I assume it's using and extending the current auditing
18:44:27 <morganfainberg> bknudson, yes
18:44:29 <stevemar> bknudson, yep
18:44:30 <bknudson> rather than starting something new
18:44:31 <ayoung> I would like to see some sort of test listener
18:44:33 <morganfainberg> bknudson, jsut expanding to federation work.
18:44:55 <ayoung> something that a Keystone admin could run to confirm that the events are being emitted
18:45:03 <stevemar> as it stands only events that call auth controller are logged
18:45:04 <morganfainberg> i think we can vote on this one, remember the vote is general approach
18:45:11 <bknudson> we've got a request to enable notifications by default
18:45:23 <stevemar> something that seems worth doing
18:45:24 <ayoung> And the red blocks from whitespace burn my eyes
18:45:26 <morganfainberg> bknudson, right.
18:45:36 <stevemar> ayoung, i'll upload a new version today :)
18:45:37 <morganfainberg> #startvote Audit Notifications for Federation? Yes, No, Table
18:45:37 <openstack> Begin voting on: Audit Notifications for Federation? Valid vote options are Yes, No, Table.
18:45:37 <dstanek> I don't see a lot of info in the proposed changes section
18:45:39 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
18:45:41 <bknudson> #vote yes
18:45:42 <stevemar> #vote yes
18:45:43 <morganfainberg> #vote yes
18:45:45 <ayoung> #vote yes
18:45:47 <marekd> #vote yes
18:45:51 <gyee> #vote yes
18:45:59 <henrynash> #vote table
18:46:12 <morganfainberg> dstanek, i think it's a small amount of changes
18:46:25 <henrynash> #vote yes
18:46:25 <morganfainberg> dstanek, it's really about adding a decorator i think.
18:46:31 <dstanek> #vote no - i have no idea what's actually changing :-(
18:46:32 <openstack> dstanek: no - i have no idea what's actually changing :-( is not a valid option. Valid options are Yes, No, Table.
18:46:53 <dstanek> #vote table
18:46:55 <morganfainberg> dstanek, try again :P
18:47:01 <morganfainberg> anyone want to switch to table?
18:47:03 <jamielennox> #vote yes
18:47:04 <dstanek> i'd love to know more before voting
18:47:09 <morganfainberg> going in 3
18:47:25 <morganfainberg> #endvote
18:47:26 <openstack> Voted on "Audit Notifications for Federation?" Results are
18:47:27 <openstack> Table (1): dstanek
18:47:28 <openstack> Yes (8): gyee, ayoung, morganfainberg, bknudson, marekd, jamielennox, henrynash, stevemar
18:47:34 <gyee> dstanek, no peer pressure here :)
18:47:37 <jamielennox> dstanek: but i agree, given that i know we want to do auditing i don't learn much from the spec
18:47:43 <morganfainberg> i think this yes is contigent on using the same notifiers as we currently use
18:47:50 <ayoung> dstanek, -1 the review and comment on what you want to see, please
18:47:51 <bknudson> henrynash voted for all 3
18:47:59 <dstanek> ayoung: of course
18:48:09 <henrynash> bknudson: well, I dint vote no
18:48:09 <morganfainberg> ok, next up?
18:48:12 <ayoung> Next up JSON Home
18:48:18 <ayoung> #link https://review.openstack.org/#/c/97359/
18:48:27 <bknudson> if the spec turns out to be a disaster hopefully the Yes vote here isn't binding
18:48:32 <morganfainberg> i'll be honest i haven't looked at it
18:48:42 <morganfainberg> bknudson, nah yes isn't binding
18:48:43 <bknudson> btw, I just wrote this up because it's interesting
18:48:52 <ayoung> bknudson, Yes means "I have no serious objections"
18:49:06 <bknudson> wasn't planning to even work on it unless I had some time.
18:49:22 <bknudson> also, someone might say do this rather than the v3 extension advertisement
18:49:26 <morganfainberg> #startvote JSON Home Spec? Yes, No, Table
18:49:27 <openstack> Begin voting on: JSON Home Spec? Valid vote options are Yes, No, Table.
18:49:27 <ayoung> Oooh
18:49:28 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
18:49:32 <dstanek> i think this is great
18:49:39 <dstanek> #vote yes
18:49:55 * morganfainberg has to abstain because i haven't read it in depth
18:49:56 <morganfainberg> or at all
18:50:04 <gyee> so JSON home will eventually deprecate the current scheme?
18:50:07 <ayoung> morganfainberg, then vote table
18:50:11 <morganfainberg> #vote table
18:50:27 <jamielennox> bknudson: did you find any libraries that could deal with jsonhome?
18:50:31 <bknudson> gyee: there is really no current scheme
18:50:43 <bknudson> jamielennox: I didn't look for a library
18:50:48 <gyee> bknudson, current version discovery I mean
18:51:05 <bknudson> gyee: right, it would cover current version discovery
18:51:15 <jamielennox> bknudson: it's not all that well defined but there is definetly a current scheme and it's at least similar across most openstack services
18:51:17 <bknudson> so hopefully we'd deprecate the current way
18:51:25 <ayoung> #vote table
18:51:37 <ayoung> Lets get the library and some more eyes on this before we say OK
18:51:45 <jamielennox> #vote table
18:51:51 <bknudson> jamielennox: there was a project that was using it... marconi maybe
18:52:15 <henrynash> #vote yes
18:52:25 <jamielennox> bknudson: yea, marconi was what i was thinking - but honestly i think if i was TC an incubation requirement would be to use a similar format to everyone else
18:52:29 <gyee> bknudson, did we discuss this at one of the cross-project sessions?
18:52:33 <jamielennox> (whatever that is)
18:52:39 <bknudson> they'll both work
18:52:59 <bknudson> gyee: I don't think it was discussed, there's been some mailing list discussion
18:53:04 <gyee> #vote yes
18:53:10 <gyee> anything for consistency
18:53:27 <morganfainberg> anyone else?
18:53:28 <gyee> next up, pagination!
18:53:33 <morganfainberg> in 3
18:53:43 <morganfainberg> #endvote
18:53:44 <openstack> Voted on "JSON Home Spec?" Results are
18:53:45 <openstack> Table (3): ayoung, morganfainberg, jamielennox
18:53:46 <openstack> Yes (3): henrynash, gyee, dstanek
18:53:55 <bknudson> a tie!
18:53:56 <morganfainberg> Even keel
18:54:04 <dstanek> i'm getting better at this voting thing
18:54:08 <morganfainberg> dstanek, hehe
18:54:26 <morganfainberg> lets look into a library, with a library i'm a yes
18:54:32 <ayoung> Lets try to revisit this one next week.
18:54:38 <morganfainberg> ayoung, ++
18:54:39 <ayoung> Next up Session tokens
18:54:49 <ayoung> OIK...little bit of background
18:54:58 <ayoung> Horizon does unspeakable things with tokens
18:55:06 <ayoung> well, everyone does, byut horizon particularly
18:55:21 <ayoung> Horizon really needs sessions, not tokens, to maintain a cache of the userid and password
18:55:36 <ayoung> if we do a session, the rules would be different than they are for tokens:
18:55:39 <bknudson> horizon must have sessions
18:55:42 <bknudson> it's part of django
18:55:52 <ayoung> bknudson, yeah, but not in its connection with Keystone
18:55:55 <ayoung> so
18:55:56 <morganfainberg> bknudson, right now they use the keystone token (effectively) as the session
18:56:02 <ayoung> Horizon doesn't hold on to password
18:56:02 <morganfainberg> bknudson, and store that in ... the session object
18:56:17 <ayoung> it uses a keystone token, and passes one scoped token to keystone to get another scoped differently
18:56:21 <ayoung> this is kida wrong
18:56:41 <ayoung> least privilege says "got from unscoped to scoped only"
18:57:05 <ayoung> but also, if we shorted the token lifespan any shorter, we are going to be kicking people out of horizon even when they are actively using it
18:57:14 <jamielennox> #link https://review.openstack.org/#/c/96648/
18:57:16 <ayoung> a session should last about 10 minutes
18:57:26 <morganfainberg> (configurable)
18:57:31 <morganfainberg> and can be extended
18:57:35 <ayoung> yes
18:57:51 <ayoung> if the user actively contacts the server, the session shsoulkd be extended
18:57:56 <bknudson> I don't see how a session token is going to work with pki... the doc has the expiration time
18:58:12 <morganfainberg> 2 minutes.
18:58:25 <ayoung> bknudson, it has to be done via keystone
18:58:37 <ayoung> handthe old session back, get a new one, or some comparable mechanism
18:58:40 <dstanek> what can you do with a session token? just exchange it for a scoped token?
18:58:41 <bknudson> it's only unscoped?
18:58:49 <ayoung> correct
18:58:53 <ayoung> to both of you
18:58:56 <morganfainberg> #startvote Session Tokens Spec? yes, no, table
18:58:57 <openstack> Begin voting on: Session Tokens Spec? Valid vote options are yes, no, table.
18:58:58 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
18:59:01 <morganfainberg> keep talking just gettnig the vote going.
18:59:12 <morganfainberg> personally, i like the idea and would love to see it
18:59:26 <morganfainberg> and the general principle is sound
18:59:27 <morganfainberg> imo
18:59:28 <morganfainberg> #vote yes
18:59:42 * ayoung abstains
18:59:51 <gyee> #vote table
19:00:04 <bknudson> #vote table
19:00:14 <bknudson> Haven't looked at it.
19:00:20 <bknudson> also, we're out of time
19:00:26 <morganfainberg> we're at the end, feel free to table and we can circle back
19:00:30 <gyee> like non-persistence one, we need more in-depth study on the impact as it fundamentally changed how Horizon operates
19:00:40 <ayoung> close out the vote before we close the meeting, please
19:00:41 <morganfainberg> ok lets circle back on this one.
19:00:44 <jamielennox> i want more information
19:00:44 <morganfainberg> #endvote
19:00:45 <openstack> Voted on "Session Tokens Spec?" Results are
19:00:46 <openstack> table (2): gyee, bknudson
19:00:47 <openstack> yes (1): morganfainberg
19:00:56 <morganfainberg> #endmeeting