18:02:12 <heckj> #startmeeting
18:02:13 <openstack> Meeting started Tue May 29 18:02:12 2012 UTC.  The chair is heckj. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:02:14 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:02:28 <heckj> Ola all
18:02:35 <heckj> #topic status and progress...
18:02:45 <heckj> milestone 1 is cut and available
18:02:50 <heckj> so we're into milestone 2
18:03:11 <heckj> #link https://launchpad.net/keystone/+milestone/folsom-2
18:03:25 <heckj> Lots of blueprints this next milestone
18:03:31 <ayoung> IPv6....
18:03:48 <ayoung> I was hoping to use Apache HTTPD and make it a non issue.
18:03:49 <rafaduran> hi all
18:04:02 <ayoung> Let me check on the status of Eventlet upstream IPv6 support.
18:04:09 <dolphm_> o/
18:04:16 <heckj> ayoung: sounds good
18:04:32 <heckj> token_id work is under review now
18:05:04 <heckj> V3 API is in review, and needs another draft. I have a significant amount of feedback to pull together this week.
18:05:19 <heckj> Is joesavak around?
18:07:09 <heckj> dolphm (guilty by association here) - any idea what joesavak specifically wanted with https://blueprints.launchpad.net/keystone/+spec/rbac-keystone? (I updated the whiteboard with what I think it needs, but wasn't sure)
18:08:19 <dolphm_> He reviewed my proposal, and gave it a thumbs up
18:08:37 <dolphm_> Some of his feedback was already included in what I posted tithe draft API
18:08:58 <heckj> dolphm_: do we need a separate blueprint for what he wants there?
18:09:34 <dolphm_> Something specific you're referring to?
18:09:59 <heckj> dolphm_: just trying to figure out what he wanted with the blueprint and how to track it's "progress".
18:10:03 <heckj> everett toewes about?
18:10:17 <dolphm_> He likes actions/capabilities, doesn't need rules for rax
18:10:27 <heckj> chmouel?
18:10:48 <heckj> dolphm_: I guess my question really is should we be tracking a blueprint for that specific work against the v3 api?
18:11:53 <dolphm_> I'd roll it into the RBAC-keystone bp, but it's up to you
18:13:19 <heckj> I'll hunt down chmouel and everett related to the last two blueprints in folsom-2 to find out how they're doing and what help might be needed. Everett is a new contributor, so i'm expecting he'll need some
18:13:45 <heckj> #topic open discussion
18:14:33 <heckj> We've got a pile of reviews outstanding. I'm working through a number today
18:14:52 <heckj> haven't checked bug and questions this week yet either, so I"ll be trying to hit that today as well
18:15:28 <heckj> Any open questions?
18:16:15 <liemmn> o/  Thanks for all the love for https://review.openstack.org/#/c/7706/...  How do we trigger SmokeStack for patch set#3?
18:16:39 <ayoung> https://review.openstack.org/#/c/7706/
18:16:49 <ayoung> the ... messes up the hyperlink
18:17:22 <liemmn> What ...?
18:17:27 <heckj> liemmn: not entirely sure… mtaylor or dprince might have a good idea
18:17:28 <dolphm> need someone with smokestack admin access to retrigger last i asked
18:17:39 <liemmn> okie dokie
18:18:38 <ayoung> who are the core reviewers?  Why does this patch require so many reviewers to get in?  We have 3 community members plus core....
18:19:00 <heckj> ayoung: all reviews take 2 core reviewers
18:19:21 <dolphm> i'm happy to +2 if there's community consensus there
18:19:38 <heckj> core members are https://launchpad.net/~keystone-core/+members
18:19:39 <ayoung> dolphm, are you core?
18:19:45 <dolphm> ayoung: yes
18:20:08 <ayoung> yeah, and this code is basically adding in functionality that didn't make the KSL redo
18:21:24 <ayoung> As far as other topics:  I have a working proof of concept of the PKI signed tokens
18:21:38 <dolphm> :D
18:21:42 <ayoung> #link https://github.com/admiyo/keystone/tree/signed-tokens
18:21:46 <heckj> ayoung: nice!
18:22:26 <ayoung> One thing I noticed is that the service.py authenticate method is kindof overflowing its scope.  I think this should move mostly into a middleware component
18:22:53 <ayoung> it does more than authenticate, really,  as it also generates the data for the token,  then calls the token API
18:23:08 <dolphm> what would you move to middleware?
18:23:35 <dolphm> it is a token api call
18:23:40 <ayoung> this one might include a refactoring where user-id authentication is one middleware component, and the token generation and persistance a different one
18:24:00 <ayoung> I have to grok the architecture a little bit better
18:24:36 <dolphm> if you can simplify, please do!
18:25:09 <ayoung> dolphm, there are 3 stages as I see it.  1 is authenticate.  2  Is generate token,  and that needs to call the SSL binary (in my first impl)  3 is persist to DB/KVS whatever
18:25:45 <ayoung> I'd like to be able to say:  add in these two authentication mechanisms:  basic-auth,  certiificate,  and if you use those,  you then get aswsigned a token
18:26:02 <ayoung> however,  if you come in with a token,  you can do new things.
18:26:28 <ayoung> But you need to use a non-token based auth in order to get assigned a token,  or tokens never really time out...
18:27:09 <dolphm> basic-auth == http basic auth?
18:27:14 <ayoung> dolphm, yes
18:27:42 <ayoung> dolphm, as well as client certificate auth, which is part of the PkI blueprint.
18:27:59 <dolphm> makes sense to me
18:28:40 <ayoung> dolphm, the idea is, I think, that the authentication mechanism sets REMOTE_USER,  which is the WSGI way of saying the container has done auth for us.
18:29:16 <ayoung> So the definition of authenticated is that REMOTE_USER is set,  and then we can build a token for users that need it
18:29:45 <ayoung> It should also allow us to interop with Apache HTTPD a little more cleanly
18:29:51 <dolphm> cool
18:31:58 <ayoung> heckj, I'd like to backpeddal on https://bugs.launchpad.net/keystone/+bug/996139
18:32:04 <ayoung> "Change default token backend from KVS to SQL "
18:32:05 * heckj looks
18:32:06 <uvirtbot> Launchpad bug 996139 in keystone "Change default token backend from KVS to SQL" [Undecided,In progress]
18:32:14 <ayoung> I think that change only makes sense if we default to HTTPD
18:32:37 <ayoung> I think that for Eventlet,  I'd prefer to keep the Tokens in memory.  Especially in light of the PKI Signing
18:32:55 <dolphm> what's the impact from pki?
18:33:04 <ayoung> since we won't have to go back to Keystone to authenticate tokens,  "losing" them on reboot is no longer a real concern
18:33:34 <heckj> ayoung: I'm OK with that. You're welcome to mark the bug as invalid to kill it.
18:33:45 <ayoung> I like memory vs  SQL  for security reasons
18:34:02 <ayoung> IE,  you can't get access to everyone's token via A SQL query
18:34:08 <ayoung> heckj, OK.  Will do
18:34:16 <dolphm> ah
18:34:43 <dolphm> do pki tokens need to be persisted at all, then? or just logged a bit
18:35:17 <rafaduran> ayoung: if many tokens are saved in memory, can be an issue?
18:35:35 <ayoung> rafaduran, possibly
18:36:00 <ayoung> the new tokens are going to be larger.  Probably about 700 Bytes or so,  ve 64 currently
18:36:10 <ayoung> vs
18:36:36 <ayoung> rafaduran, so maybe the right answer is to not persist them at all
18:37:15 <ayoung> I could see an argument that for Signed tokens,  just append the new tokens to an audit log
18:37:16 <rafaduran> ayoung: yes, I think so
18:38:06 <rafaduran> ayoung: if you are not going back to ask for them not saving them seems the way to go
18:39:34 <ayoung> rafaduran, let me think about that for a bit.   There is some discussion vis-a-vis revocation I want to deal with first
18:39:42 <ayoung> revocation might require persistance
18:40:20 <dolphm> ayoung: pki tokens still have an identifier, i assume?
18:40:43 <dolphm> ayoung: persist only that, and remember its state?
18:40:45 <ayoung> dolphm, well,  for the first approximation, it is the whole token
18:41:05 <dolphm> a hash of the entrie token then?
18:41:13 <dolphm> sha1 or whatever
18:41:20 <ayoung> dolphm, I thought there was a separate Blueprint for splitting Token ID from secret portion
18:41:32 <ayoung> Hashing would be fine...just not certain yet it is required
18:41:40 <dolphm> ayoung: that was just a thought, i didn't make a bp
18:42:30 <ayoung> If a token has a life span of 8 hours, are we really going to need revocation?
18:42:51 <dolphm> ayoung: 8 hours is an eternity ;)
18:43:05 <ayoung> I tend to doubt it, as it makes the system much more complex, and Kerberos works with 8 hour service tickets for 20+ years now
18:43:43 <ayoung> dolphm, the only reason to make them that long is if tokens need to be used in batch jobs or something
18:44:00 <ayoung> for most uses,  20 minutes would likely be fine
18:44:06 <dolphm> personally, i think "need" is relative, so i'm just playing devil's advocate
18:44:22 <ayoung> The devil can hire his own advocates.  He has the payroll for it
18:44:26 <dolphm> as long as the token lifespan is configurable
18:44:30 <dolphm> lol
18:44:40 <ayoung> dolphm, that is my thinking
18:47:52 <rafaduran> ayoung: I don't know a lot of encryption so probably is a bad idea, but you could get automatic revocation if the encryption includes a variable part that changes/cycle afet expriation time
18:48:24 <ayoung> rafaduran, if it is after expiration time,  you have to go and get a new certificate.
18:48:37 <ayoung> lets call them tokens, actually
18:48:48 <ayoung> so the signed token has a expiry in it
18:49:08 <ayoung> and the auth_token middleware will check that
18:49:21 <ayoung> if the token has timed out,  the user will not be authenticated
18:49:44 <ayoung> the usually deal is that they then go back to keystone and get a new token
18:50:33 <rafaduran> ayoung: I think that would work fine
18:50:39 <ayoung> We can provide a grace period if the token was used to auth against, say, Nova, and then is needed a while later to talk to, say Quantum.
18:51:22 <ayoung> and b "talk to"  I mean that nova sends the token along as part of a quantum request....
18:54:37 <mtaylor> heckj: aroo?
18:54:52 <heckj> mtaylor: ola
18:55:13 <heckj> y'all good with ending the meeting?
18:55:59 <heckj> #endmeeting