18:02:41 <heckj> #startmeeting
18:02:42 <openstack> Meeting started Tue May 22 18:02:41 2012 UTC.  The chair is heckj. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:02:43 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:02:52 <heckj> #topic F1 milestone release
18:03:06 <heckj> morning morning!
18:03:12 <ayoung> How do!
18:03:14 <heckj> We've got the F1 milestone release this week
18:03:24 <liemmn> o/
18:03:27 <heckj> #link https://launchpad.net/keystone/+milestone/folsom-1
18:04:44 <heckj> I've kicked back blueprints that I didn't think we'd get
18:05:10 <heckj> We have some bugs pending F1 release that just need reviews
18:05:12 <liemmn> ayoung, the eventlet 2-way ssl stuff should be posted soon ... been distracted with other stuff...
18:05:21 <ayoung> liemmn, very cool
18:06:02 <ayoung> For the rest of the team:  I got liemmn 's origianal patch ported to the KSL architecture,  but missing things like unit tests
18:06:08 <ayoung> also,  remove the auth piece
18:06:12 <heckj> so call out to y'all - please take a look at the code reviews
18:06:20 <ayoung> he's  making it into a proper patch
18:06:28 <heckj> ayoung: sounds great!
18:06:38 <ayoung> heckj, seems like the right way to do
18:06:41 <ayoung> it
18:06:44 <liemmn> yep... with 2-way ssl support for keystone client, too
18:07:04 <heckj> liemmn: fantastic!
18:07:27 <heckj> Anyone have anything specific for the F1 release, or hot issues that we should have open a critical bugs
18:07:28 <heckj> ?
18:07:34 <ayoung> heckj, the one caveat is that I don't think doing real Client Certificate in SSL is simple enough that we can just slip it in. I looked at the Apache SSL/ModNSS   code base, and client cert requires all this renegotiation magic voodoo
18:07:53 <ayoung> also,  I think I misunderstood the original purpose of the auth part of that patch
18:08:02 <heckj> ayoung: understood
18:08:42 <ayoung> liemmn, gyee that patch didn't do client cert auth,  it used X509s in a way analogous to how tokens are used, right?
18:10:51 <heckj> moving on a bit...
18:11:00 <heckj> #topic V3 API draft
18:11:05 <ayoung> heckj, so the other issue is that the PKI Signed Tokens requires gyee's patch
18:11:15 <gyee> ayoung, not sure if I understand you question, you mean client cert in exchange for a token as opposed to just protecting the comm channel?
18:11:15 <ayoung> for keeping the tokens out of the URLs
18:11:21 <ayoung> gyee, yes
18:11:43 <ayoung> gyee, in HTTP,  you can use the client cert to authenticate,  which is how I originally read that patch
18:12:03 <ayoung> but It looks like that patch was using X509s some other way.
18:12:40 <heckj> gyee: how are you coming along with the PKI patch?
18:12:49 <liemmn> ayoung, yes it is doing client cert to authenticate... avoid the need for that admin token we were using
18:13:03 <gyee> there are 3 issues here
18:13:11 <gyee> 1) using SSL to protect the comm channel
18:13:20 <gyee> 2) use SSl for client auth, in exchange for a token
18:13:31 <gyee> 3) remove token from URL
18:13:50 <gyee> Liem's patch solved 1)
18:14:08 <liemmn> We are still using the token in my patch... (not to be confused with the PKI work ayoung is doing :) )
18:15:13 <ayoung> gyee, yes,  sorry for confusing them...The first patch liemmn submitted 96f2fc18ee2bb562e99cb966d33758b929ec2c60  does 1
18:15:18 <ayoung> I thought it was also doing 2
18:15:28 <ayoung> but it isn't getting the client cert from the SSL layer
18:15:30 <gyee> no
18:15:31 <gyee> just 1)
18:15:37 * heckj nods
18:15:41 <gyee> there are two aspects of PKI authentication
18:15:52 <gyee> 1) client cert in exchange for a token
18:15:58 <gyee> 2) token signed by Keystone
18:16:21 <gyee> not sure which one we are addressing, I presume 2) first correct?
18:16:49 <ayoung> gyee, OK...so to do the token PKI
18:17:09 <gyee> meaning token signed by Keystone correct?
18:17:11 <ayoung> I need the patch to do 3
18:17:16 <ayoung> gyee, correct
18:17:36 <ayoung> gyee, to do 2 requires Apache HTTPD,  I think
18:17:47 <gyee> 2) is a bit more complicated
18:18:00 <ayoung> gyee, right
18:18:03 <gyee> we need to figure out how to map cert to user
18:18:27 <gyee> like cn <=> user name
18:18:33 <ayoung> gyee, well, I think we can do that for Dashboard no problem,  since that uses HTTPD already.
18:18:43 <ayoung> gyee, ah, right
18:19:09 <gyee> that's fine, as long as it is configurable and we're clear on that
18:19:38 <ayoung> gyee, OK...so first thing is the signed tokens.  Question for small audience now is "What SSL library is acceptable"
18:19:52 <gyee> m2crypto? :)
18:19:58 <ayoung> I was starting with NSS,  but got some input that people would want OpenSSL
18:20:05 <ayoung> gyee, I thought m2crypto was dead
18:20:16 <gyee> still alive and kicking in HP
18:20:17 <ayoung> I was going to use the SSL command line in conjunction with Popen
18:20:26 <heckj> gyee: we (OpenStack) pulled m2cyrpto because of inconsistencies and build problems.
18:20:41 <gyee> heckj, I am aware of it :)
18:20:44 <ayoung> gyee, they just removed M2 Crypto from Nova since the upstream M2Crypto is unresponsive
18:21:19 <liemmn> OpenSSL seems like a well-accepted standard in the *nix world...
18:21:30 <gyee> m2crypto builds on top of openssl
18:21:59 <ayoung> So it looks like using eventlet with Popen calling the openssl command line is acceptable?
18:22:15 <ayoung> and then we can revisit m2crypto if it is really demanded?
18:22:47 <ayoung> I think that Popen is actually going to be more eventlet friendly than the native library.  I doubt OpenSSL is async
18:23:37 <ayoung> It means individual requests will be slower,  but the overall server should be more responsive
18:24:24 <heckj> ayoung: sounds like a good approach
18:25:04 <gyee> you need openssl to parse the cert?
18:25:10 <ayoung> gyee, yes
18:25:22 <gyee> oh ok, yeah, popen should do it
18:25:25 <ayoung> gyee, in Keystone,  openssl will sign the token
18:25:43 <ayoung> in the other services, openssl will verify the signature
18:27:12 <gyee> sure, give it a shot, just follow the driver pattern so we can replace popen with something more efficient later
18:27:51 <gyee> ayoung, you still need a patch from us or you are OK?
18:27:52 <ayoung> gyee, will do.  WRT your patch for "remove token from URL"
18:28:00 <ayoung> I need the Database schema
18:28:13 <ayoung> it would be even easier if I had your whole patch to work with
18:28:40 <liemmn> heckj... What's the window for v3 api feedback?
18:28:52 <liemmn> now till?
18:29:09 <ayoung> The current code for writing tokens to the DB uses the ID generation to create the secret part of the token,  and that is a pain to work with,  especially since I suspect that it is going to change slightly with your patch
18:29:23 <heckj> liemmn: waiting until the PKI discussion is wrapped up
18:30:16 <gyee> heckj, we'll take the URL discussion offline, I am not working on the "remove token fom URL" BP at the moment
18:30:24 <heckj> OK
18:30:44 <heckj> #link https://docs.google.com/document/d/1s9C4EMxIZ55kZr62CKEC9ip7He_Q4_g1KRfSk9hY-Sg/edit <-- Draft v3 API available
18:30:49 <heckj> sent email to the mailing list.
18:31:11 <heckj> Would like initial feedback by the end of this week so I can wrap it together and make another draft next weekend
18:31:27 <heckj> #action: review draft API for end of week for another revision...
18:32:03 <heckj> termie hasn't had time to dig in there either - so I'm expecting significantly more feedback in another week or two when he's back in the US
18:33:07 <heckj> liemmn: do you need more time?
18:33:31 <liemmn> Until Monday would be good.
18:33:57 <liemmn> even though we will try to get everything in by EOD Friday
18:34:15 <heckj> liemmn: no problem, I'll refrain from making another draft rev this next weekend and push it back a few days
18:34:43 <liemmn> thx...  I will try to get all in by Friday though
18:37:41 <ayoung> heckj, I'll push the Fedora world to try and get all input in by Friday as well
18:37:57 <heckj> ayoung: thank you.
18:38:17 <heckj> ayoung: do you work with any of the guys in the OpenShift world? Would love to just have their general eyes on it as well
18:38:29 <ayoung> heckj, I can hunt a few of them down, yes
18:42:00 <heckj> #topic open discussion
18:42:16 <rafaduran> I've uploaded a new version for #link https://review.openstack.org/7239 trying to solve some people concerns (middleware, audit)
18:42:33 <heckj> radaduran: I'll try and get some time to review today
18:42:43 <rafaduran> it's still unfinished, but I would like to know if this approach looks better
18:42:54 <rafaduran> before going further
18:42:58 <ayoung> rafaduran, please use a more descriptive title than "Fixes bug x"
18:43:40 <rafaduran> ayoung: I know I was on hurry since I couldn't work on this and just sent the git review for being available for the meeting
18:43:42 <chmouel> rafaduran: yes probably want to address dolph review so would be easier for reviewer to look at it
18:44:30 <rafaduran> this #link https://review.openstack.org/7127 needs review
18:44:30 <chmouel> rafaduran: you can use gerrit draft feature if you want to just show to other people
18:44:39 <dolphm> that was all feedback from last week's meeting, as i recall
18:45:05 <rafaduran> chmoul: I know about that feature, but I don't know how to use it very well
18:45:28 <rafaduran> chmoul: las week I sent a link that wasn't public...
18:46:01 <dolphm> rafaduran: i think you just have to add people's names explicitly?
18:46:10 <dolphm> rafaduran: i haven't created a review with that feature myself
18:46:30 <heckj> yeah, not entirely sure about how that works myself...
18:46:40 * heckj needs to read up on the gerrit/git-review stuff a bit more
18:47:39 <chmouel> the draft feature?
18:47:46 <chmouel> you basically add -D to git-review
18:48:05 <chmouel> and it will upload as draft and you can share the link and work on it before click Publish it (or something like  that)
18:48:09 <mtaylor> draft reviews are good crack
18:48:29 <mtaylor> they are invisible to other people unless you explicitly request review from them
18:48:39 <heckj> mtaylor: word
18:48:42 <ayoung> mtaylor, +1
18:48:53 <heckj> rafaduran: so just explicitly add the individuals you want to share with
18:49:14 <dolphm> mtaylor: can you "demote" a regular review to draft status by re-uploading with -D?
18:49:28 <mtaylor> dolphm: you can not - it's a one-way transition
18:49:31 <dolphm> k
18:49:32 <heckj> mtaylor: can you have a generally available public draft, or is that synonymous with a review request?
18:49:39 <rafaduran> heckj: that was my problem, I publish it instead of adding reviewers/people on demand
18:49:40 <mtaylor> dolphm: however, we're working on adding work-in-progress state right now
18:49:54 <dolphm> mtaylor: i have a review that would be useful for :)
18:49:55 <heckj> mtaylor: nice
18:49:56 <mtaylor> (we have the state done, working on adding the button to the UI...)
18:51:36 <heckj> 10 minutes left… Anything else, or should I wrap this up?
18:51:40 <chmouel> yeah
18:51:53 <chmouel> we probably want to look over a unified way to cache token
18:51:58 <chmouel> for ec2/s3/auth token
18:52:29 <chmouel> auth_token has it but ec2/s3 doesn't
18:52:45 <ayoung> heckj, can I get https://review.openstack.org/#/c/7156/ merged in?
18:52:49 <chmouel> I was thinking about adding another middleware or use common functions to share between
18:54:26 <heckj> chmouel: sounds sensible
18:54:55 <heckj> I don't know if middleware makes sense there (haven't thought about it), but common functions certainly does
18:55:09 <rafaduran> +1
18:55:43 <chmouel> well i am not sure since those middleware are supposed to be dropin
18:55:50 <dolphm> if nothing else, they should share common code
18:56:06 <dolphm> there's too much overlap otherwise
18:56:10 <heckj> chmouel: sounds like we're all in general agreement
18:56:16 <liemmn> An idea is to create a separate middleware for caching tokens.
18:57:03 <chmouel> heckj, dolphm: cool will add something like a common.py in middleware to make it easy for packagers to don't include everything but the middleware adn that file
18:57:41 <chmouel> liemmn: yeah was thinking about that, but I think there is quite a bit of middleware profileration ATM in the pipeline and I am not sure if it will be as flexible
18:57:51 <chmouel> liemmn: but we could definitively look to do something like swift.cache does
18:58:04 <liemmn> yeah... just separation of concerns
18:59:00 <chmouel> i'll dig a bit more about this and would come back to you guys next week
18:59:09 <heckj> chmouel: word
18:59:09 <notmyname> heckj: we also need to talk about moving the keystone middleware piece into swift
18:59:39 <heckj> notmyname: ohai! Definitely - unfortunately out of time for this meeting
18:59:42 <notmyname> heckj: we don't need to solve it here :-)
18:59:48 <notmyname> heckj: just needs to be done
19:00:00 <heckj> notmyname: can I swing by the #swift meeting tomorrow and chat about that?
19:00:20 <notmyname> heckj: there's not a standing meeting, so there's nothing scheduled for tomorow
19:00:34 <notmyname> heckj: either email me or ping me on IRC
19:00:35 <LinuxJedi> mtaylor: meeting?
19:00:41 <heckj> #endmeeting