18:00:46 #startmeeting keystone 18:00:47 Meeting started Tue Nov 6 18:00:46 2012 UTC. The chair is heckj. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:48 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:00:49 The meeting name has been set to 'keystone' 18:01:21 agenda at http://wiki.openstack.org/Meetings/KeystoneMeeting 18:01:23 #link http://wiki.openstack.org/Meetings/KeystoneMeeting 18:02:04 #topic high priority issues 18:02:28 We've got some reviews passing through to fix inadvertant breakage after we merged the V3 keystoneclient branch 18:02:40 \O/ 18:02:50 yeah!!! 18:03:03 dolphm will be back in a minute or so 18:03:27 #link https://review.openstack.org/#/c/15516/1 18:03:31 #link https://review.openstack.org/#/c/15513/1 18:03:34 while we're chilling - ayoung, what's the hierarchical data that's current in attributes? I thought that was mostly flat 18:03:46 #link https://bugs.launchpad.net/keystone/+bug/1075376 18:03:48 Launchpad bug 1075376 in keystone "keystoneclient unit tests fails on update tenants and users" [Critical,In progress] 18:03:57 heckj, let me look, I think it is the role assignments 18:04:18 ayoung: ahh.. yeah, it think that gets populated out in lists, good point - would be good to do that separately 18:04:21 o/ 18:04:47 heckj, regardless, getting password and enabled out in one patch along with the other normalized fields would be a good thing (tm) 18:05:03 lets not ask for a 100% solution up front 18:05:22 If we can go completely normalized in one pass, great 18:05:29 ayoung: migrations on existing data will be the tricky part there, especially for enabled 18:05:58 ayoung: definitely 18:06:16 dolphm, nah, it should be pretty straightforward. Once we accept that we are parsing JSON, which are the True values for enabled should be pretty clear 18:06:19 dolphm: yep - we'll want to make sure we can smoothly migrate that out 18:07:28 ayoung: I was triaging bugs yesterday - at least a few that you files are better as blueprints - made note of such in the bug 18:07:42 heckj, that is fine 18:07:44 ayoung: enabled='mondays' 18:08:00 enabled="every third thursday" 18:08:05 wtf? 18:08:08 dolphm, I'm more of the Arthur Dent school disabled="Thursdays" 18:08:10 you serious? 18:08:11 gyee: exactly 18:08:12 lol 18:08:20 gyee: sure! Why not :-) 18:08:27 gyee: users are creative 18:08:33 sorry, getting back to topics 18:08:33 I mean you seen such data? 18:08:57 and the client is like "awesome, Enabled: Thursdays... got it." 18:09:03 #topic Keystone-v3 feature branch merge 18:09:19 so aside from screwing the tests in keystone, we have the python-keystoneclient updated with V3 parts in place 18:09:47 * dolphm apologizes for not testing client feature/keystone-v3 against server master :( 18:09:52 tests (and bad assumptions) getting fixed up now - so now we're just pending getting keystone V3 into place 18:10:23 dolphm: since you submitted most of those change sets, how would you like to move that forward? 18:10:45 dolphm: do you want to merge what we can, and then re-submit the remaining against master, or do it all in a feature branch and update that? 18:11:31 gyee: I'm assuming getting that merged into master is blocking you on the stop-id components 18:11:42 heckj: fix current issues ASAP, merge keystone server feature/keystone-v3, fix any unknowns, rebase pending v3 changes on master and re-review them 18:11:50 heckj, I can do it in master 18:12:17 gyee: there's no v3 API in server master..? 18:12:27 gyee: not yet anyway 18:12:29 gyee: middleware fix or something? 18:12:43 both middleware and backend 18:13:03 gyee: can you give a quick rundown on your approach? 18:13:18 middleware set the token in the header for token validation 18:13:27 backend get it from the header 18:13:29 gyee: we'll want to time the middleware so that we don't screw up henrynash' work in moving auth_token into keystoneclient 18:13:52 should be pretty trivial change 18:13:53 gyee: ah, i was thinking middleware on top of the keystone server (not referring to auth_token) 18:14:08 should I do it in the v3 branch? 18:14:29 gyee: probably easiest to do it in master after we land the V3 branch 18:14:32 gyee: keystone server changes, yes 18:14:43 k, I'll wait then 18:15:17 if you can do the middleware separately (auth_token, yes), then if you have that ready to go ASAP, that might be worthwhile - get it in before we start trying to shift that to keystonelcient 18:15:17 gyee: are you using X-Subject-Token? (is that what it's called in the v3 spec? lol) 18:15:55 dolphm, how about I make the header configurable? 18:16:01 X-Thuesday if you want :) 18:16:06 gyee: it needs to be spec'd 18:16:23 gyee: and actually, support in keystoneclient v3 auth is where this should really go :-/ 18:16:37 gyee: auth_token should just be refactored to support the client, and not care about the api details 18:17:29 I need to be very careful about refactoring middleware again as HP is extending them 18:17:33 I am sure there are others 18:18:05 so gyee what kind of extensions? Is this generalizable stuff? 18:18:54 gyee: keystone.middleware.auth_token won't be refactored necessarily, it should just be deprecated and eventually removed, in favor of keystoneclient.middlware.whatever_the_new_name_is which utlizes the client itself 18:19:11 we are extending middleware class interface 18:19:29 gyee: auth_token's or keystone.wsgi.Middlware? 18:19:35 auth_token 18:20:17 dolphm, right, namespace change is a lot easier than class interface change 18:20:31 gyee, so once this moves to keystoneclient, it should just require you to update the import 18:20:33 gyee: i'm thinking both at once 18:20:59 what are we changing in the interface? 18:21:28 dolphm, you mean pluggable auth? 18:22:28 I am trying to understand what "both" means 18:22:29 there's a couple interfaces here... gyee is concerned about auth_token's class interface 18:23:35 auth_token's interface to the wsgi pipeline is stable and won't break backwards-compatibility 18:23:44 dolphm, whew 18:23:56 I was worried I missed something key there. 18:24:32 moving auth_token into the client means new namespace and freedom to refactor the class itself... though, i don't have anything in mind 18:24:55 heckj, did you incorporate everyone's input into some sort of overall development scheme? 18:25:02 gyee: and i'm sure HP would have some feedback on how that class interface should be structured to be more easily extensible? 18:25:26 dolphm, yes, should I create a BP? 18:25:28 #topic Upcoming contribution plans for Grizzly 18:25:34 gyee: that'd be awesome 18:25:41 #link https://etherpad.openstack.org/keystone-grizzly-plans 18:25:45 dolphm, we have a load of work in the queue. I would avoid adding 18:26:02 ayoung: it needs to happen in grizzly anyway, to support v3 18:26:36 yeah, we've got a serious pile of work building up here 18:26:49 I took everyone's feedback and tossed it all into that etherpad 18:27:08 Thierry is asking for a generalized "what folks are doing" from all the PTLs - that's why I'm trying to consolidate that 18:27:35 I also went through bugs yesterday, triaged them up to a first pass, and nailed some of the blueprints against milestones for an initial cut 18:28:24 heckj, so Alvaro Lopez is helping on the refactoring for Authenticate . 18:28:29 Let me update that 18:28:33 we have some more requirements for delegation 18:28:35 I have some pieces targetted against grizzly-1 https://launchpad.net/keystone/+milestone/grizzly-1 18:28:38 #link https://launchpad.net/keystone/+milestone/grizzly-1 18:28:44 someone from HP will create a BP, just a heads up 18:29:14 ayoung: thanks 18:29:27 We have a couple of blueprints that need to be created yet 18:29:45 need one around: authentication & token validation abstraction 18:29:53 meh 18:30:06 gyee: you were talking about creating one for service and endpoint scoping I think 18:30:12 yes 18:30:13 that too 18:30:15 dolphm: and you had one pending around schema validation 18:30:34 heckj: pending creating a bp? 18:30:57 dolphm: do you already have a BP around the schema validation work you proposed a meeting or two back? 18:31:08 heckj: no, drafting it now :) 18:31:12 dolphm: just meant that a BP was needed, but didn't exist yet 18:31:15 cool 18:31:42 dolphm, having schema validation will be awesome 18:32:25 pluggable auth, moving auth_token, and the merging of V3 is all the earliest pre-req stuff as far as I can see 18:32:53 heckj, that is my take on it 18:32:59 sounds right 18:33:29 ayoung: you had some general elements under PKI moving forward - pieces that can be done in parallel - should that be a BP to track it? 18:33:55 (add signing user, policy rules for enforcing signed user, etc) 18:33:57 heckj, PKI future should cover it. I don't think it calls for another BP 18:34:10 PKI Future - cool - will add that link in etherpad 18:34:15 But instead probably should add the details 18:34:18 PKI is a big umbrella 18:34:52 https://etherpad.openstack.org/keystone-pki-future 18:35:03 ayoung: uh - being blind - not seeing BP in https://blueprints.launchpad.net/keystone 18:35:16 did you create on there, or is it just in the etherpad link? 18:35:19 heckj, hmm...thought It was there 18:35:53 ayoung: that list is *huge* - I think it really needs to be broken down if we want to get you help with it and lay it out against milestones in grizzly... 18:36:10 I'd be happy to break it apart for you if you want... 18:36:35 some others have already put in blueprints that overlap with some of this 18:36:35 Guess I didn't add it 18:37:01 heckj, True. 18:37:06 pre-auth, keystone-explicit-impersonation, delegation 18:37:11 #link https://blueprints.launchpad.net/keystone/+spec/client-side-request-response-validation 18:37:18 heckj, lot of it is under delegation 18:37:28 #link https://blueprints.launchpad.net/keystone/+spec/delegation 18:37:47 kk - I'll start with it under delegation, and we can break out pieces that don't fit from there if we need 18:37:50 which should then link the the etherpad on PKI future 18:37:56 heckj, yeah 18:38:10 we have more requirements for delegation 18:38:19 just added to whiteboard 18:38:20 probably will add our comments there 18:38:23 yeah 18:38:47 there's also a wiki page that David added linked up : http://wiki.openstack.org/keystone/Delegation 18:40:35 given how much is laid out in delegation, looks like that's Grizzly-2 or grizzly-3. 18:40:37 heckj, yes, that is the link for the full specification. I Need to move things from the Etherpad to there 18:40:58 We probably need to pick some specific milestone deliverable for it to step forward between the two milestones 18:41:03 kk 18:41:13 heckj, perhaps. A lot depends on how much churn we have in other bugs, and whether I can get some time working on it heads down 18:41:32 I knew that wehen we flipped to PKI tokens it would cause some new issues to rise to the surface 18:41:43 ayoung: would you like me to start with asserting it as grizlzly-2 and being aggressive with the planning for it? 18:41:58 ayoung: or defer to grizzly-3 and give us a few more weeks in there 18:42:10 heckj: link to dates on those? 18:42:11 heckj, what are the cut off dates? 18:42:27 #link http://wiki.openstack.org/GrizzlyReleaseSchedule 18:42:38 grizzly-1 is basically thanksgiving 18:42:46 grizzly-2 is jan 10th 18:42:52 grizzly-3 is feb 21st 18:43:09 feature ingest freeze is feb 21st 18:43:10 NOt going to have it by -1 that is for sure 18:43:56 ayoung: yeah, that was clear - figured it was 2 or 3 - don't have to assign it yet - but the more I can get laid out, the easier it'll be to coordinate changes later 18:43:57 heckj: when is auth_token moving to the client? 18:44:19 dolphm: henrynash is starting to work on that ASAP - just got CLA, so I'm hoping in the next 2 weeks (grizzly-1) 18:44:20 heckj, OK, so the whole thing will be -3 but let me see which pieces we can push for in -2 18:44:26 heckj: oh awesome 18:44:26 kk 18:45:52 #topic open discussion 18:46:46 heckj, can we clear out the people on Core that never review patches? 18:47:01 yep 18:47:15 I'd like to eventually get some new names in there, but for now, we should show who is active 18:47:40 #link https://launchpad.net/~keystone-core/+members#active 18:47:52 ayoung: I'll clear that out later today - I'll do keystone-core,keystone-drivers, and keystone-bugs maintenance all together 18:48:04 heckj, +2 18:49:52 heckj, also, I'd like to have a couple items part of our current operating guidelines. 1. Make sure all changes will work in an HTTPD deployment. We put a lot of effort in heading toward that, and I'd hate to backtrack 18:50:33 2. We are considering auth_token locked down except for security /critical fixes until the migration is done. We need to expediate that 18:51:02 ayoung: "expediate"? 18:51:03 3. service.py authenticate is locked down until refactoring is done. Don't waste time writing code against the old layout 18:51:12 expediafy? 18:51:21 make fast! 18:51:31 Lightning McQueen it! 18:51:37 ayoung: ah - yep, Henry asked some questions in email and was starting to roll on it 18:51:55 ayoung: how do you propose to verify we don't backtrack on #1 18:52:08 a boat-load of tests :) 18:52:15 unit and functional 18:52:26 heckj, well, the three active approvers should keep it in mind when reviewing patches. For the most part, be aware of eventlet specific additions 18:52:36 gyee: are tests sufficient, or does it also need to be in devstack gating? 18:52:59 tests are the best way to guard against these things 18:53:06 heckj, I think we need to start working toward tests run in HTTPD 18:53:09 gyee: agreed, but only if they're run 18:53:18 haha 18:53:26 ayoung: I think that's the only way to make sure they're run. 18:53:32 heckj, yeah. 18:53:45 ayoung: alternately, we can work with CI to talk about how to test an alternate deployment and see if they have suggestions 18:54:06 heckj, I suspect that first step is normalizing the user table. 18:54:24 Then we can use the REMOTE_AUTH in conjunction with the mod_auths in apache to run in HTTPD 18:55:00 Need devstack support. Perhaps first off is an option to deploy Keystone in HTTPD along side the Horizon code. Can be optional to start 18:55:03 ayoung: makes sense 18:55:30 Heh, that would let me finally close the IPv6 ticket, too 18:55:38 ayoung: does devstack use httpd now? Thought it was a different config... 18:55:57 ayoung: nevermind - just was told it does 18:56:00 heckj, devstack uses httpd for Horizon, and eventlet for the rest of the services 18:56:29 heckj, they do some neat things in there to make it developer friendly, so you run as yourself and not as root or the httpd user 18:56:50 I had some problem getting logging working, which was making dev a PITA. 18:57:08 Since I am waiting on the refactoring for other work, I can do a spike on the normalization. 18:57:26 ayoung: sounds good 18:57:57 So who is full time coding on Keystone now: /me, dolph, gyee, soon to be nash, 18:58:24 I'm part time only - and mostly on client at the moment 18:58:26 I think that's it 18:58:32 Jose part time too 18:58:46 heckj, I don't know if we'll get any more of boden's time either 18:59:11 I think that's it for now 18:59:19 Ok - wrapping up meeting 18:59:24 #endmeeting