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