18:02:01 #startmeeting keystone 18:02:02 Meeting started Tue Jun 3 18:02:01 2014 UTC and is due to finish in 60 minutes. The chair is dolphm. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:02:03 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:02:05 The meeting name has been set to 'keystone' 18:02:11 #topic keystone-specs 18:02:32 #info Add openstack/keystone-specs to your Watched Projects in gerrit, and start reviewing! 18:02:45 o/ 18:02:57 Please review! Lets get specs approved! 18:03:03 so I think we're getting close to J1 18:03:16 should we be getting things in for J1 rather than looking at specs for j2? 18:03:16 bknudson, June 12 18:03:27 #info All featurey/blueprinty/wishlisty changes will require an approved keystone-specs doc after juno-1 ends (June 12) 18:03:38 I don't know what we want to get into j1 18:03:44 probably compressed tokens 18:03:48 bknudson, if things are slated for J1 those are priority *cough* compressed tokens 18:03:57 love keystone-specs. love the structure and organization 18:04:08 #topic Juno-1 (June 12) 18:04:11 topol: ++ 18:04:12 #link https://launchpad.net/keystone/+milestone/juno-1 18:04:17 bknudson, otherwise, it should be focused on specs so once J2 opens we can get moving. 18:04:30 bknudson: multi-domain uuids 18:04:34 our juno-1 target list is fairly short, but compressed tokens is certainly at the top of the list 18:04:38 ah, also "Document v2 to v3 API migration strategy" 18:04:41 compressed tokens and revocation events are the two things left over from Icehouse. But Revocation events are client only 18:04:45 i'd like to see them be the default in devstack before we check that box as done 18:05:16 dolphm, we need to ensure everyone has updated minimum reqs to 0.9.0 of KSC 18:05:22 dolphm, compressed tokens as default? 18:05:23 dolphm, but it's doable 18:05:25 bknudson: i consider this to be a first step toward having a migration strategy (mostly the last section) https://review.openstack.org/#/c/96242/ 18:05:25 dolphm, devstack default to compressed tokens? 18:05:29 stevemar: yes 18:05:31 morganfainberg: ++ 18:05:33 ayoung: yes 18:05:36 dolphm, is there a patch? 18:05:43 stevemar, Proof of concept only 18:05:50 needs to get through unit tests etc 18:05:54 i mean a devstack patch 18:05:59 #link https://review.openstack.org/#/c/91145/ 18:06:09 stevemar: we don't even expose them in keystone yet^ 18:06:17 stevemar once it passes out unit tests we can open the devstack review 18:06:19 the current poc makes compressed tokens the default provider 18:06:29 bknudson, true 18:06:30 bknudson, thanks 18:06:36 bknudson, I can remove that. 18:06:51 ayoung, bknudson, i'm fine with that but i think we should make the default switch explicit if we're changing that. 18:07:09 morganfainberg, nah, lets get it in, then make things use it buy default 18:07:14 by 18:07:16 and i think keystone should switch the default, not have a devstack "option" 18:07:26 morganfainberg, two patches, then? 18:07:27 ayoung, ++ we change not devstack changing. 18:07:35 devstack already has an option to set the token provider 18:07:43 so you can switch to uuid easily 18:07:47 ayoung, yeah, make sure it works, and then we work on flipping the switch. 18:07:56 morganfainberg I think devstack options are very helpful. Changing devstack config without them is a pain 18:08:04 KEYSTONE_TOKEN_FORMAT=UUID 18:08:13 is someone on the devstack team aware of the impending change? 18:08:16 ayoung, in case we need to juggle things around in other projects. we then aren't holding up support of compressed tokens because some project X is balking at it 18:08:21 ayoung, for some reasons 18:08:25 bknudson, ++ 18:08:27 lets get the PKIZ provider merged non-default, then people can test with devstack, and we can have the discussion about what to do after that 18:08:38 ayoung: works for me. 18:08:39 devstack release on its own shcedule. is there really a dependency here? 18:08:47 bknudson, i'm sorry i meant in devstack-gate, different thant devstack 18:08:50 devstack releases? 18:09:14 oh, he meant the devstack-gate???\ 18:09:17 yeah. 18:09:30 morganfainberg: a new d-g job? 18:09:32 :-) 18:09:52 btw, devstack does have stable/ releases, so I think they follow the regular openstack releases 18:10:09 stable branches 18:10:24 yeah... it's a branch, not so much a release 18:10:27 they don't release it, like as a pip download 18:10:46 bknudson, no, just don't want to have to add options to dsg project to support flipping things around like this up front - argue if we need it as part of the matrix stuff after it "works" and we make it default on 18:10:57 anyway, is there anything else to land in j1? this is the last reasonable chance to get attention on something new 18:11:11 dolphm, yeah... 18:11:15 the sql migratiosn for extensions 18:11:17 topol, devstack-gate is the QA project that controls how tempest nodes etc (devstack) nodes are configured in check/gate 18:11:23 dolphm: I’m tyring to land the multi-domain UUIDs 18:11:23 ayoung: link? 18:11:27 might be nice to get https://review.openstack.org/#/c/70630/ in 18:11:30 #link https://review.openstack.org/#/c/96326/ 18:11:38 ayoung: henrynash: target the bp's to j1 18:11:48 dolphm: ahh. oops 18:12:06 bknudson, ++ on the templated catalog v3 18:12:07 dolphm, I wrote that as a POC, but there is no BP or anything...it was a response to people complaining about the migrations not being run 18:12:10 ++ templated 18:12:15 I guess there is no reason it can't wait til J2 18:12:25 ayoung, lets push that to j2. 18:12:33 no need to "rush" that. 18:12:37 morganfainberg, ++ 18:12:48 morganfainberg, it does have a bug report associate with it, which is how I was addressing it 18:13:00 I don't know if it calls for a BP, dolphm 's call 18:13:01 bknudson: ++ 18:13:09 ayoung: bug is fine for that i think 18:13:16 dolphm, https://bugs.launchpad.net/keystone/+bug/1324260 18:13:17 Launchpad bug 1324260 in keystone "Always migrate the the db for extensions instead of conditionally" [Medium,In progress] 18:13:18 ayoung: i assumed you were referring to a bp 18:13:19 ayoung, i would say it's a bug. it's inconsistent schemas not massive overhaul 18:13:45 so the general rule I've been going with is "if it is a default extension, it should be migrated by default" 18:13:59 but we've not had any default extensions that require migrations until fairly recently 18:14:18 new schemas for new extensions do not get migrated by default. 18:14:22 Hence the explicit list 18:14:50 ec2_extension_v3 s3_extension simple_cert_extension 18:14:54 are the default extensions 18:15:18 bknudson, and those don't have migrations 18:15:24 right 18:15:26 from a deployment standpoint, i just want to voice how crappy it is that to "enable" an extension i need to explicitly migrate it 18:15:35 but now oauth, endpoint_filter are promoted 18:15:38 erm explicitly do a DB migration 18:15:40 "default extensions" doesn't sound right, if they are enabled by default they are not extensions :) 18:16:03 gyee_, yes they are 18:16:10 gyee_, they are not part of the core API 18:16:20 they are endpoints enabled in keystone by default 18:16:26 ayoung, I mean if they are enabled by default, they need to be core 18:16:29 ayoung, and hence the whole OpenStack arguemnt on why extensions suck (or not suck) 18:16:30 simple as that 18:16:31 so for Juno 18:16:33 ['endpoint_filter', 'federation', 'oauth1', 'revoke'] 18:16:40 bknudson: and trusts is so default it's hardcoded 18:16:57 dolphm, trusts is not even in contrib 18:17:09 dolphm: trusts isn't an extension by some definitions 18:17:14 and it's migrations are part of common repo 18:17:24 bknudson: it's implementation is not an extension, it is defined as an API extension 18:17:42 I'll have to make sure I handle it correctly in the v3 extensions advertisment 18:17:48 making trusts an extension was a last minute decision. It would have been done cleaner if it wasn't suggested 2 weeks after code freeze 18:18:01 but that horse is dead 18:18:24 ayoung, there are ways to revite that horse... but not in scope of this conversation 18:18:28 revive* 18:18:38 give it water 18:19:02 morganfainberg, I'd be OK with that: we really need to integrate all of the delegation mechanisms into one core api 18:19:29 ayoung, yeah, mark that for Kilo 18:19:30 ayoung, i totally agree 18:19:38 * ayoung whistles 18:19:40 kilo? 18:19:47 henrynash, K release 18:19:51 Oh, one other patch I want for J1 18:19:52 henrynash, as of yet unnamed 18:19:54 K release 18:19:58 ah, just checking 18:20:01 https://review.openstack.org/#/c/95989/ 18:20:08 #link https://review.openstack.org/#/c/95989/ 18:20:14 Kerberos as an extension name: 18:20:26 er method name 18:20:44 let's move on since we're way out of scope for j1 talk :) 18:20:50 #topic Juno hackathon 18:20:51 it means that we have a consistant way to say "this is Kerberos" whether we go with "external" or Jose's approach 18:20:57 #link http://dolphm.com/openstack-keystone-hackathon-for-juno 18:21:10 dolphm, is ^^ OK as is? 18:21:16 woo geekdom! 18:21:17 I finally got acknowledgement on the location: 112 East Pecan, San Antonio, Texas 78205 18:21:26 modulo jamielennox 's comments? 18:21:26 so for sure at Geekdom 18:21:31 it's middle of downtown in a Geekdom event space 18:21:33 * morganfainberg needs to go get approval for this trip now. 18:21:39 so, book any hotel downtown! 18:21:50 oh right, do we have hard dates? 18:21:56 morgafainberg, shouldn't be a problem for you :) 18:21:59 I was looking at hotels last night 18:22:03 which is the preferred Hotel? 18:22:05 stevemar: July 9-11 18:22:07 geeks road trip…excellent! 18:22:45 #link https://www.google.com/maps/search/hotels+near+Geekdom+san+antonio+tx/@29.4285235,-98.4919432,17z/data=!3m1!4b1 18:22:50 I think Holiday Inn San Antonio Riverwalk 217 N St Mary's St is nearby, and affordable 18:23:37 what was wrong with valencia? 18:23:39 i suggested Hotel Valencia http://www.hotelvalencia-riverwalk.com/ only because rackspace has a preferred rate there that everyone *should* be able to take advantage of; it's also about 2 blocks from geekdom 18:23:40 henrynash, bknudson lbragstad topol - the one i mention is in our policy 18:23:49 gyee_, waiting on corp CC to arrive and then need to poke some people to get the sign off, but i'm sure it'll be easy 18:23:52 topol, we're not at the "Mall" this time around 18:23:59 stevemar: the man’s way ahead of me 18:24:07 i'm told you just have to call to make the reservation, and tell them you're in town to visit rackspace 18:24:11 stevemar we can get an exception if valencia is optimal. yes I know we are at geekdom 18:24:29 but if that works for everyone and we dont need an exception thats fine too 18:25:14 I'll get a rental car so we have one if we need it 18:25:48 topol, neverlost! 18:25:54 * morganfainberg ducks 18:26:01 topol: you might need a rental bus for all of us 18:26:05 next time... 18:26:10 stevemar can get one too 18:26:12 conversion van! 18:26:22 lbragstad, limo? 18:26:32 thankfully downtown is full of one way streets, so it's impossible to get lost 18:26:36 but lets make sure we are in walking distance 18:27:17 was the holiday in walking distance? 18:27:20 lbragstad: careful with that google search-- geekdom has two locations downtown now 18:27:35 lbragstad: one is their co-working space and the other is their event space 18:27:45 if not let's do valencia and I can help with exceptions 18:27:51 dolphm, eerrr, which is the right address? 18:27:58 dolphm: that's the right one then? 18:28:00 off pecan? 18:28:06 112 East Pecan is correct 18:28:18 topol, lets just all go with Valencia, nive to have a common hotel for something like this 18:28:26 ayoung+++ 18:28:28 I agree 18:28:32 agreed 18:28:48 the wrong geekdom location is 110 East Houston 18:29:00 * lbragstad noted 18:29:01 dolphm,i've also been told there is a good place for whiskey around SA. adrian_otto was saying it was awesome -- so... 18:29:12 topol, will fix exceptions for everyone! 18:29:17 dolphm, is that for Keystone only, or Barbican as well? 18:29:18 wrong geekdom??? how many are there? 18:29:23 yes I will fix exceptions 18:29:38 at Geekdom, I mean 18:29:42 IBMer's at least 18:29:44 morganfainberg: the brooklynite is all i can think of 18:30:02 dolphm, is that the one owned by a racker (not sure about former or not) 18:30:05 ayoung: working on barbican separately, but it should be M-Tu-W same space, same week 18:30:11 ++ 18:30:32 morganfainberg: uhh i dunno. the beer place we went to in january was a former racker (big hops) 18:30:46 dolphm, i'll get infos. 18:30:54 topol: geekdom is expanding, quite quickly. two in SA 18:31:09 impressive 18:31:14 topol: (within a couple blocks of each other) 18:31:41 #topic Reviewing languishing reviews for abandonment / re-assignment 18:31:43 morganfainberg: o/ 18:31:47 o/ 18:31:59 ok so if everyone wasn't aware auto abandonment of reviews is dead 18:32:20 dolphm, can we get this one for J1? https://review.openstack.org/#/c/95989/ 18:32:34 morganfainberg: do we have a script to identify reviews to consider for abandonment? 18:32:37 reviews will never auto-abandon, so we need to review (probably once a month / milestone/ something) the reviews that are lingering around 18:32:49 dolphm, i've been commenting on some 18:33:03 dolphm, i think any core can actually mark it as abandoned? 18:33:10 stevemar: thats true now 18:33:14 we can also Restore anything 18:33:22 dolphm, at the moment no, but i think i can scrape up the infra script that used to abandon so we can run it locally 18:33:31 but since we can restore (all cores) 18:33:36 and all cores can abandon 18:33:47 and i assume authors can still restore if core abandon? 18:33:52 dolphm, yes 18:34:12 so we're not risking too much by removing stale things from the review queue 18:34:19 we should clean up old reviews. if a review is desired and has no movment, we need to reassign the work 18:34:47 i've been going through and cleaning up the ones i know for sure about (a couple) 18:34:49 dolphm, or does it need a full blueprint. 18:34:51 ? 18:35:55 but it shoudn't be just one person sweeping reviews up 18:36:08 ayoung: you mean a spec? 18:36:17 ayoung: let's discuss after the meeting 18:36:22 dolphm, yes, SPC and BP 18:36:22 OK 18:37:27 morganfainberg: next-review should make languishing reviews fairly easy to spot 18:37:38 dolphm, as will reviewday 18:37:38 morganfainberg: do we want to use the same rule as before? 1 week? 18:37:56 bknudson, that is kindof harsh 18:38:01 I agree 18:38:03 2 weeks? 18:38:05 3? 18:38:17 once a milestone, imo 18:38:25 doesn't seem like it costs much to have old reviews around. 18:38:27 you end up with a lot of "bring it back to life but not fix" resubmits 18:38:28 or twice a milestone? 18:38:56 start of milestone: abandon / reassign, middle - did we get anywhere on those / checkin 18:39:16 start of milestone seems like a good time 18:39:26 ++ 18:39:34 or maybe at some cutoff before the milestone 18:39:41 to cull out the # of reviews to look at 18:39:45 morganfainberg: i'd rather this not be a significant recurring cleanup effort, but rather an ongoing one 18:39:46 bknudson, sure. 18:40:06 dolphm, i don't mind which way it goes, as long as we're doing it 18:40:18 lets go with one month 18:40:26 month works for me 18:40:26 that is roughly how long the milestones last 18:40:27 after a week or two of silence, we should be leaving review comments asking if the author is available to follow up, and if not, abandon 18:40:46 two weeks also works 18:40:56 but the burden is on everyone to ping authors - bonus points if you want to pick up a patch for them :) 18:41:07 lets do 2 weeks no response, comment, 1 week later reassign/abandon 18:41:10 ayoung: i think they're supposed to average 6 weeks 18:41:25 morganfainberg: can we write that down somewhere? 18:41:33 I also like the idea of if someone isn't working on something that we want we should pick it up rather than abandon 18:41:43 dolphm, Heh, it just feels like the Milestone one release is like a week after the summit, every single time 18:41:53 morganfainberg: or point me to a spot and I can write something up 18:42:20 #info Abandonment/Reassign process: 2 weeks of no activity, ping author and ask for update, 1 week after ping (no response) review is up for abandonment or reassignment to an active contributor 18:42:25 lbragstad, ^ that work? 18:42:32 lol sure! 18:42:48 lbragstad: it'll be in the meeting notes at least 18:42:54 lbragstad, we can put it up on wiki or in our contributing doc 18:42:59 #topic IDP - User / Group Lookup and Policy Functionality 18:43:01 morganfainberg: o/ 18:43:17 really quickly 18:43:21 #link https://review.openstack.org/#/c/93982/ 18:43:28 I think with the sahdow table it becomes: 18:43:31 I have user ID 18:43:38 I look in shadow table to find IdP 18:43:47 this review brought up an interesting proposition, do we hard-validate users and groups on grant creation 18:43:48 right now v2 doesn't validate 18:43:52 so question is: what if it is not in the shadow table 18:44:04 v3 does, but as a side effect fo the policy enforcement decorator 18:44:06 ayoung: then it's not a valid ID? 18:44:10 can I assign to a user, based on userid without them being in the shadow table 18:44:18 V2 only has admin or public I think, no policy 18:44:20 the callback for enforcement that is 18:44:22 shadow table? 18:44:25 dolphm, so, what if I am setting up a role for a user before thye hit the system 18:44:31 henrynash, the unique id mapping table 18:44:31 LDAP, new guy is coming on board... 18:44:37 bknudson: that binary state actually uses policy, lightly 18:44:50 ahh. you mean the one I’m proposing - Ok, got it 18:44:54 henrynash: the mapping table 18:44:55 yeah, yeah, should use a group, but readonly LDAP .... 18:45:02 lookup table? 18:45:05 we just need to make the behavior consistent in apis 18:45:11 morganfainberg: ++ 18:45:17 dolphm, consistent ID proposal 18:45:27 morganfainberg, either we don;'t look up, or we need a way to prepopulate the lookup table 18:45:35 if we go with "don't validate" we need to rethink how policy works for the v3cloud enforcement style 18:45:36 morganfainberg: i'm just trying to remember how we were referring to the proposed table 18:45:46 if we go with validate, v2 needs to check and we should make it explicit 18:45:51 I've been calling it the shadow user table 18:45:58 but I think the official nam,e is IDMapping 18:46:16 dolphm, hm. Unified UserID :P 18:46:23 henrynash, ^^ is that really a good name? should be at least user_id_mapping 18:46:56 ayoung: teh table is id_mapping….remember it has groups in it too 18:47:01 right 18:47:15 henrynash: should we not have two tables then? 18:47:36 henrynash, maybe identity_mapping...I realize ID means identitifier, but it tends to be read as meaning id for any table... 18:47:53 dolphm, nah, so long as it has a type field, one table is better 18:48:08 dolphm: we could indeed…since we need to store the type of entity since its possible that a backend might be using a different name spec for users and groups and they could have the same ID 18:48:09 just like the role assignment table, makes joins easier 18:48:19 ayoung: explain "better" 18:48:24 I don't think indexes on type fields are very efficient 18:48:34 what do we call it there? target is the project side... 18:48:47 bknudson, unless the type is an int :P 18:48:49 bknudson: ++ it just seems like an extra, unnecessary index 18:49:17 morganfainberg: is_user (tinyint) 18:49:30 * dolphm is slightly sarcastic ^ 18:49:31 an int might be ok, but if every other row is a different type then there's no good way to index. 18:49:35 right now its an Enum 18:49:37 this is the assingment tablehttp://paste.openstack.org/show/82655/ 18:49:44 http://paste.openstack.org/show/82655/ 18:49:54 we could call it the actor table 18:50:15 i knew that name would come back and bite me! 18:50:21 although I would expect lots more users than groups 18:50:29 so maybe not a big deal in this case 18:50:33 bknudson: ++ 18:50:34 type | enum('UserProject','GroupProject','UserDomain','GroupDomain') 18:50:42 so enum ('User' 'Group' 18:50:44 ) 18:50:58 henrynash, I like actor 18:50:58 ayoung: that’s what i have in teh code today for it! 18:51:03 so.. i know we need to solve the user id thing as well. i'd like to just make sure we solve what we want with policy and fixing v2/v3 policy post meeting so we can write it up/code it up/etc 18:51:12 henrynash, I know, and I was supporting your approach 18:51:16 (either accept the review that is posted or not enforce existence) 18:51:23 ayoung: bows head 18:51:36 dolphm, i think we're into henrynash's topic here. :) 18:51:48 morganfainberg: was just thinking that 18:52:12 although i wasn't sure what the difference between the two was intended to be... 18:52:14 #topic Cross-backend Unique User and Group Entity IDs 18:52:21 henrynash: o/ 18:52:28 so woudl encourage peopel to read the spec! 18:52:47 dolphm, mine is just about policy enforcement consistency in absence of anything else. 18:52:48 i'm going to appoint henrynash to write up all the specs 18:52:51 #link https://review.openstack.org/#/c/97492 18:52:56 #link https://review.openstack.org/#/c/74214/ 18:53:01 thx 18:53:18 and user must/exist/not exist before grant assigned 18:53:22 henrynash, is there some way to prepopulate a value in the actor table? 18:53:54 If I need to do a role assignment, but the user hasn't logged in, would a GET check in LDAP for the user and then add to the shadow table? 18:53:58 well, do we know he local identifiers? 18:53:59 actore table? 18:54:21 henrynash, yes 18:54:34 ayoung: so any identity manger call that causes the backend entity to be read will populate the mappintable 18:54:41 actore mensamque* 18:54:47 henrynash, list_users? 18:54:49 yep 18:55:02 that could be expensive the first time it is run.... 18:55:06 is that OK? 18:55:21 well I guess someone will hit it 18:55:50 do we know the user name? 18:56:04 then just do a list with tehuser name as the filter 18:56:13 henrynash, I think the only things that accept user name are authenticate and list users 18:56:23 GEt takes userid 18:56:44 ahh no - ther is a get user by name manager call 18:56:55 in V#? 18:56:57 V3 18:56:58 def get_user_by_name(self, user_name, domain_id): 18:57:06 If I do a list all users will all the users get populated? 18:57:32 in the mapping table 18:57:39 bknudson: first, we insist that you at least qualify teh list with a domain_od 18:57:53 henrynash, that is only called from an extension 18:58:16 ayoung: teh get user byname? 18:58:22 henrynash, I think so, yes 18:58:27 * ayoung still confirming 18:58:33 ayoung: it’s in teh identity core manager 18:58:39 ok, if I list all users in a domain then all the users for that domain get populated? 18:58:46 dolphm, ~2min 18:58:48 bknduson: yes…. 18:58:59 ok 18:59:27 you can't actually list users from a federated source 18:59:46 dolphm: from LDAP yes, from federated no 18:59:53 dolphm, we need a way to get a userid from a username for federation 18:59:55 henrynash: maybe and correct 19:00:02 (time) 19:00:03 or at least for LDAP 19:00:03 #endmeeting