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