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