18:01:24 <heckj> #startmeeting
18:01:25 <openstack> Meeting started Tue Jul  3 18:01:24 2012 UTC.  The chair is heckj. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:01:26 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:01:44 <heckj> How's things?
18:01:53 <heckj> #topic folsom-2 milestone
18:02:23 <heckj> #link https://launchpad.net/keystone/+milestone/folsom-2
18:02:54 <heckj> dolphm: you and I have a few reviews outstanding - otherwise we're in good shape for the F2 release milestone
18:03:03 <liemmn> o/
18:03:14 <dolphm> heckj: i'll take another pass this afternoon
18:03:59 <heckj> ayoung: around?
18:04:11 <dolphm> is jenkins having a bad day again? :-/
18:05:09 <heckj> oh, probably
18:05:51 <heckj> Reviews that need someone other than Dolph or I looking at this for the F2 release: https://review.openstack.org/#/c/8909/, https://review.openstack.org/#/c/9182/
18:05:57 <heckj> both for F2 milestone
18:06:00 <heckj> #link https://review.openstack.org/#/c/9182/
18:06:06 <heckj> #link https://review.openstack.org/#/c/8909/
18:06:53 <heckj> #topic hot issues
18:07:03 <heckj> Any new issues? Hot topics?
18:07:22 <liemmn> Heckj, when is the v3 API "frozen"?
18:07:35 <ayoung> \)/
18:08:07 <ayoung> finally got the SSL Cert generation into Keystone
18:08:09 <heckj> liemmn: I'm going through the existing feedback now - going to take one more cut at it, and then it'll be solid enough to start development against
18:08:22 <heckj> I'd hoped to do that this past weekend, but ended up sleeping through most of it
18:08:29 <liemmn> sounds good :)
18:08:33 <heckj> ayoung: yeah!!!
18:08:42 <ayoung> heckj, do we have a summary sheet of the changes?
18:08:50 <dolphm> ready for implementation != frozen, correct?
18:08:53 <ayoung> I have to present on it, and am lazy
18:09:05 <heckj> liemmn: I do expect to leave the spec "open" per bcwaldon's suggestion to allow us to revise as we run into implementation issues
18:09:17 <heckj> ayoung: #link https://launchpad.net/keystone/+milestone/folsom-2
18:09:21 <dolphm> heckj: is that what glance did?
18:09:29 <heckj> dolphm: yeah
18:09:46 <heckj> dolphm: Brian said it made a huge difference for their work as they sussed out deeper issues
18:09:57 <dolphm> heckj: i can imagine :)
18:10:02 <ayoung> should I add in https://bugs.launchpad.net/keystone/+bug/994860  ?
18:10:03 <uvirtbot> Launchpad bug 994860 in keystone "Keystone middleware auth_token assumes top level URL when making http connection" [Medium,In progress]
18:10:10 <liemmn> ayoung, there were some feedback on making PKI optional... That is still in the plan right?
18:10:25 <ayoung> liemmn, I don't want it optional.
18:10:38 <ayoung> I'd rather have it out there, have everyone beat on it
18:10:47 <ayoung> and if it is a real problem,  we roll back
18:11:00 <jrouault> but some implementers will not use PKI
18:11:02 <ayoung> there are 2 parts to it:   token generation and token validation
18:11:13 <ayoung> the old style validation *can* be done with the new tokens
18:11:20 <heckj> ayoung: I think it's only pending unit tests
18:11:31 <ayoung> but vice versa is not
18:11:47 <ayoung> heckj, my ticket?  Yes,  I will get unit tests.  I meant should I add that bug to the API blueprint?
18:12:06 <ayoung> jrouault, why would they not use PKI?
18:12:10 <heckj> ayoung: not worried too much about it either way -
18:12:21 <dolphm> heckj: ayoung: can we "demote," for example, the token validation call to an official extension, if it's not necessary for PKI and PKI is core?
18:13:04 <ayoung> dolphm, I don't think that is wise
18:13:13 <liemmn> ayoung, so...  if someone is using non PKI and going through to Keystone backend to do a validation (and have no cert), how would that work with PKI enforced?
18:13:13 <jrouault> ayoung: because they have implementations running today that dont require it
18:13:16 <heckj> dolphm, ayoung: I don't want to demote anything at this point
18:13:18 <ayoung> I think PKI will give us many new features.  Probably most important is Federation
18:14:27 <ayoung> liemmn, token is generated using PKI.  That means that it can be validated with the signing cert.  But it can also be validated the old way:  by asking Keystone directly.
18:14:40 <ayoung> I am going to post another patch shortly that is just the token generation
18:14:47 <ayoung> the vaolidation will be a separate patch
18:15:33 <liemmn> Cool, as long as we can still have an option to ask Keystone to validate the token, should the signed cert is not there, I think that should be ok
18:15:47 <ayoung> dolphm, the thing is,  token validation without calling to keystone is pretty much the reason for having PKI in the first place.  Otherwise,  we've just implemented a slightly more expensive token generation scheme
18:16:00 <ayoung> liemmn, signed cert is fetched on demand
18:16:39 <jrouault> which is why it should be optional whether the token is signed
18:16:39 <liemmn> I mean, if a token is not signed, then we have the option to ask Keystone to validate the token as before...
18:16:41 <ayoung> One thing that is currently missing, and I am tempted to try and add before submitting the token generation is the ID of the Keystone server
18:16:49 <rafaduran> ayoung: PKI  will be part of just v3 API or it will land into master before it?
18:17:11 <dolphm> ayoung: that's why i don't like it remaining in the "core" api
18:17:11 <ayoung> rafaduran, it makes no changes to the API and will land before it
18:17:12 <heckj> rafaduran: he's aiming to have it in prior to V3 api - in progress now
18:17:21 <dolphm> ayoung: it's just bloat if it's not recommended
18:17:35 <dolphm> granted, it should be kept around
18:18:25 <ayoung> dolphm, this is based on the lessons learned in other IdM systems.  Probably most notably is Kerberos.  THe biggest difference between V4 and V5 is the way that service tickets are validated,  which is what this is echoing
18:19:16 <jrouault> another reason to support the current token scheme in conjunction to the PKI scheme is to support token revocations
18:19:52 <ayoung> It should have a significant impact in decreasing the amount of network traffic
18:20:12 <jrouault> not arguing that... just asking that is be optional
18:20:23 <jrouault> you configure if you want PKI or not
18:20:47 <heckj> we do need it to work side-by-side with the legacy mechanisms and not break the legacy mechanisms
18:21:18 <heckj> #topic keystone-core
18:21:28 <heckj> Switching topics - sounds like that one's tapped out
18:21:36 <heckj> I'm proud to announce the addition of ayoung to keystone-core
18:21:54 <dolphm> awesome
18:21:57 <dolphm> ayoung: grats
18:22:00 <heckj> I'll send a note out to the list shortly with the same
18:22:04 <ayoung> thanks
18:22:10 <heckj> ayoung: awesome work, thank you - and here's more to do
18:22:27 <heckj> :-)
18:23:41 <heckj> #topic open discussion
18:24:12 <ayoung> um...one last thing on the PKI tokens...I was planning on changing the behavior of auth_token middleware,  but I could also privde a different middleware  for it....I could do something like check the length of the token,  and if it is short, assume it is a hashed (current style) token,  but if it is longer than some threshold, assume it is PKI signed.  Question then is do we want to make people 1) default to phone home and  enable
18:24:12 <ayoung> signing validation or 2)  default to PKI validation and explicelty enable phone home?
18:24:41 <ayoung> My thought is that we should push the new functionality to ensure that people test it and report issues
18:25:04 <ayoung> we can provide the fall back...so you would have to explicitly set the middleware on, say glance
18:25:18 <ayoung> I'd hoped to avoid doing anything along those lines....
18:26:27 <jrouault> so you will then support unsigned tokens?
18:26:36 <dolphm> ayoung: shouldn't you try to decrypt in middleware, and if that fails, try phoning home if phoning home is enabled?
18:26:41 <ayoung> jrouault, only under duress :)
18:26:44 <dolphm> ayoung: otherwise immediately fail?
18:26:57 <heckj> ayoung: extending the current auth_token middleware should be fine as long as it doesn't get too complex in there. kind of a judgement call though.
18:26:58 <dolphm> ayoung: fail = reject authentication
18:27:03 <liemmn> ayoung, you could leave the auth_token as is to provide the default behavior, and create a new filter before auth_token to handle PKI tokens.  If the tokens are not PKI, then let them fall to the auth_token for legacy support.
18:27:13 <jrouault> +1
18:27:22 <ayoung> liemmn, but that makes a configuration nightmare
18:27:36 <liemmn> just another filter in the WSGI pipeline...
18:27:47 <ayoung> liemmn, I object to the word "just"
18:27:51 <heckj> means we have to change a bunch of client pipelines
18:28:00 <dolphm> liemmn: that doesn't sound like it will work at all -- auth_token will filter out incoming authentication claims as-is
18:28:12 <ayoung> it means that we have to change devstack,  plus any tool like puppet or chef...
18:28:22 <ayoung> human sacrifice,  dogs and cats. living together
18:28:26 <heckj> heh
18:28:26 <dolphm> liemmn: and always attempt token validation
18:28:27 <ayoung> masss hysteria
18:29:21 <ayoung> Here's a thought.  Let me get the token generation code through review and into the repo,  and let people beat on it for a while.
18:29:41 <liemmn> well.. the alternative is to have auth_token do it all... that's fine too, but IMHO, I am just trying to do separation of concerns... did not think about deployment
18:29:42 <ayoung> Meanwhile,  we can go through the auth_token code with a fine tooth comb,  deal with corner cases etc
18:30:08 <heckj> ayoung: that sounds like a good take on it
18:30:10 <jrouault> i would like to conclude on whether PKI usage will be optional...
18:30:23 <ayoung> I'd like to make it default
18:30:33 <ayoung> but provide an override to turn it off?
18:30:49 <dolphm> jrouault: are you asking about the api or keystone's implementation?
18:31:02 <jrouault> yes, I would like to turn it off and use the v2.0 mechanism
18:31:14 <heckj> jrouault: We will support that
18:31:24 <dolphm> i'd vote for optional in API, and required (or at least on by default) in keystone
18:31:35 <jrouault> doph: my understanding is ayoung wanted to force all tokens to be signed... I don't want to do that if I am using the v2 mechansim
18:31:46 <jrouault> of validation
18:31:59 <jrouault> it is unnecessary overhead
18:32:12 <dolphm> jrouault: still not sure if you're referring to the v2 api or v2 implementation?
18:32:16 <ayoung> jrouault, out of curiousty, why?  I mean, I understand the revokation issue,  but beyond that,  what issue do you see with PKI?
18:32:37 <jrouault> if I request a token from Keystone configured for no PKI, i should get a token back that is not signed
18:33:13 <ayoung> jrouault, are you worried about doing a rolling upgrade?
18:33:29 <dolphm> jrouault: as a service consumer, does it matter?
18:33:50 <jrouault> no, we have use cases where a signed token will just cause us greif
18:34:00 <dolphm> jrouault: example?
18:34:55 <ayoung> jrouault, the token is opaque.  To the end user, the only difference will be the length
18:35:07 <ayoung> and they should not really even care about that
18:35:13 <jrouault> and that will cause problems for other services we have
18:35:18 <dolphm> jrouault: example?
18:37:37 <heckj> jrouault: can you expand on the "grief" and what causes it?
18:37:52 <dolphm> jrouault: i'm not sure how we're supposed to address issues that you're not sharing or justifying
18:38:25 <jrouault> 1. we have other services that consume tokens that have problems with the length
18:38:45 <ayoung> OK...I'll put in a disalbe override,  but leave enabled the default.  Will that  suit everyone?
18:38:56 <jrouault> yes
18:39:18 <ayoung> jrouault, so you specifically need the shorter length?
18:39:20 <dolphm> jrouault: what kind of length is problematic? what lead you to assume a specific length?
18:40:23 <dolphm> jrouault: is there a maximum token length documented somewhere that we need to correct?
18:40:58 <jrouault> 2.  we also have some keystone like token generators that are used for testing... those would all need to change to support signing... but that is not so much a concern for the community
18:41:23 <ayoung> jrouault, I can help you build some replacements.
18:41:38 <heckj> jrouault: I'm most interested in the length issue and what you're hitting there - do you have a max length?
18:42:11 <jrouault> heckj: i do have the exact length but can get that to you
18:42:34 <jrouault> s/don't/do
18:43:16 <heckj> jrouault: thanks - would like to know that ASAP, as there's a bunch of other potential impacts there
18:43:36 <ayoung> OK...I'm thinking that is insufficient reason to hold up the PKI side of things.  THe token length could change for many reasons  without PKI.  I am not really willing to disable the server side just for a specific test harness
18:44:33 <jrouault> making it optional is holding things up?
18:44:57 <heckj> ayoung: don't hold up the PKI effort - carry it forward, let's just make sure we can disable it as an option, but not as the default settings
18:45:18 <ayoung> heckj, disabling it is not trivial on the Keystone side.
18:45:51 <ayoung> So it will hold it up.  Plus,  if both forms of tokens ate allowed, they should be minimally tested
18:46:18 <heckj> ayoung: gotcha. Let's see what we can suss out to enable both or either at the same time
18:46:44 <ayoung> OK...I'll post the current code to my github page here shortly
18:46:49 <heckj> sounds good
18:48:53 <rafaduran> ayoung: Can I change topic now?
18:48:57 <heckj> #action jrouault to provide a max key length
18:49:02 <heckj> rafaduran: yep -
18:49:09 <ayoung> rafaduran, yes, please do so
18:49:13 <rafaduran> I've working on the rate limit middleware, I still need some work on it, but It would be nice get some feedback on corner cases, defaults ...
18:49:30 <rafaduran> I think it would be nice take some time for next meeting
18:49:44 <heckj> rafaduran: I'll schedule it up as a specific topic for next meeting
18:49:58 <rafaduran> heckj: Ok, thanks
18:51:02 <heckj> cool - any other topics for today?
18:53:27 <heckj> Okay - gotta present in 5 minutes, so I'll close this up for today.
18:53:32 <heckj> #endmeeting