18:00:05 <heckj> #startmeeting
18:00:06 <openstack> Meeting started Tue Aug  7 18:00:05 2012 UTC.  The chair is heckj. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:07 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:00:09 <gyee> \o
18:00:18 <heckj> ola all
18:00:22 <dolphm> hola
18:00:26 <ayoung> \m/ ^v^ \m/
18:00:42 <ayoung> Gotta be a better way to do horns than that....
18:00:49 <heckj> heh
18:01:02 <dolphm> \../
18:01:30 <heckj> ayoung: did you want to reset to last week's agenda and continue?
18:01:34 <ayoung> Yes please
18:01:39 <heckj> sec...
18:01:48 <ayoung> If I can jumpright in to the PKI stuff, I'll truy top keep it moving
18:02:06 <heckj> #topic PKI stuff
18:02:09 <heckj> ayoung: take it away
18:02:12 <ayoung> "Reissue of tokens "
18:02:29 <ayoung> THe ides here is that tokens are not necessarily 0 cost to create
18:02:47 <ayoung> so the question is does it make sense to return an old token if requested
18:03:00 <ayoung> it used to bwe done, before the time out was bound to the token
18:03:14 <ayoung> so, in order to implement, we would need a new concept:  reissue window
18:03:17 <ayoung> something like this
18:03:22 <ayoung> tokens last 24 hours
18:03:47 <ayoung> if I ask for a new one,  and I have an active one that is less than, say, 1 hour old, reissue it
18:04:13 <heckj> ayoung: this makes me a little squirmy
18:04:17 <ayoung> my concern is that without this concept,  we will start generating DDOS levels of tokens on a busy system
18:04:23 <dolphm> if reissue_window == 0, would new tokens always be created on POST?
18:04:34 <ayoung> dolphm, yes
18:04:48 <dolphm> and if reissue_window == 24 hours, existing tokens will always be returned, if any
18:04:51 <heckj> I'm not disagreeing that it's costly to make a token, but I think we're generally better off creating new tokens as a standard
18:05:01 <heckj> I'd prefer to not re-issue tokens
18:05:07 <ayoung> dolphm, yes,
18:05:29 <ayoung> heckj, we can make it a configuration option, with NO_REISSUE the default policy
18:05:37 <heckj> I was talking with some security professionals that reviewed the keystone codebase, and they called out the direct token usage as being somewhat fundamentally flawed
18:05:48 <ayoung> but we build in the mechanism to alleviate the pressure if it turns out to be necessary
18:06:06 <heckj> ayoung: yeah - I've got that, but it seems like a poor idea in genera
18:06:08 <ayoung> heckj, if the clients tended to cache the tokens, I would agree with you
18:06:52 <gyee> what's the use case for token reissue? job automation?
18:06:54 <dolphm> ayoung: instead of "NO_REISSUE", just set the default reissue window to be 0
18:07:01 <ayoung> in the past we haven't seen the problem because we weren't too strict on the time outs.  so doing a request for a no-tenant token would not generate a new DB line
18:07:15 <ayoung> dolphm, yeah, I was just naming the policy,  but that is what I am saying
18:07:52 <ayoung> heckj, also,  with putting the whole token text in the database, the DB is going to get larger quicker
18:08:17 <ayoung> and that was what this concept grew out of:  right now, the PKI tokens are recorded en-toto
18:08:38 <ayoung> one discussion was whether this was necessary.
18:09:08 <dolphm> yeah -- was there another use case for storing the entire token in keystone, other than to re-issue them?
18:09:14 <ayoung> the only reason I could see is if you ever needed to re-read the token data.  So if there is no re-issue,  we can remove the token body from the db table
18:09:41 <ayoung> dolphm, only for parity with the previous system.   If no reissue, I think we can safely remove it
18:10:02 <gyee> if you are going to reissue the old token, why not just store the hash?
18:10:12 <ayoung> And, if no reissue, we *should* remove it.
18:10:28 <ayoung> gyee, agreed:  we can store just the hash
18:10:30 <ayoung> but
18:10:30 <gyee> the request will contain the old token data anyway right?
18:10:31 <dolphm> i vote to only store a token hash + enable/disable state (for revocation), and skip re-issuing tokens altogether
18:10:39 <ayoung> if we reissue the token,. we need to have the body identical
18:11:07 <ayoung> heckj, is ^^ your opinion as well?
18:11:22 <heckj> ayoung: yeah, I'd prefer dolph's suggestion
18:11:30 <heckj> just want to keep enough to allow revocation
18:12:16 <ayoung> #action ayoung to remove token body from the database table.  tokens will not be reissued.
18:12:25 * heckj nods
18:12:55 <ayoung> OK...next line item:  use of keyring:
18:13:12 <heckj> saw some notes on the list re: this, but don't know what "keyring" is...
18:13:24 <ayoung> I think, if we can, we should  cache the tokens on the client side
18:13:41 <ayoung> heckj, it is a python library that maintains a credentials cache\
18:13:54 <ayoung> they are going to use it in the unified cli to store the password
18:14:09 <ayoung> I'd like to store any tokens received in there as well
18:14:12 <dolphm> purely a client-side issue, correct?
18:14:17 <ayoung> yep
18:14:54 <ayoung> It will allow the sharing of tokens.  If we are not going to reissue, this is the best way to keep load off the keystone server
18:15:01 <heckj> ayoung: so what's the issue - seems perfectly reasonable for the unifiedCLI work (BTW: who's doing that work?)
18:15:20 <heckj> ayoung: define "sharing of tokens"?
18:15:22 <ayoung> heckj, they are doing it for passwords.  I am proposing extending it to tokens
18:15:42 <dolphm> heckj: dtroyer
18:15:54 <ayoung> heckj, most CLI calls do a POST /tokens  before calling glance, nova, etc
18:16:06 <ayoung> this will obviate that call if the token is fresh enough
18:16:42 <ayoung> since each call into the CLI is a separate process, you need to store the token somewhere to reuse it.  Keysring is a safe way to do that.
18:17:28 <ayoung> I think it is this: http://pypi.python.org/pypi/keyring/
18:18:02 <ayoung> Kind of like ssh agent
18:18:11 <ayoung> does this sound like a good approach?  I think it is
18:18:41 <ayoung> If so, I'll write up the blueprint
18:18:46 <gyee> swift team is implement auth plugin for their client right?
18:18:52 <gyee> keyring will be a plug-in then?
18:19:10 <ayoung> gyee, yes, and will not be a hard requirement, I think
18:19:11 <dolphm> ayoung: bp for keystoneclient?
18:19:27 <ayoung> dolphm, probably for keystoneclient and common
18:20:02 <gyee> yeah, should be in common
18:20:19 <ayoung> I'll let you guys hedge for now if you want time to think about it.  I just wanted to get it above the noise threshold
18:20:20 <heckj> seems perfectly reasonable to me
18:21:09 <ayoung> ?action ayoung to write up blueprints for using keyring for client side token caching
18:21:20 <ayoung> that OK
18:21:36 <heckj> does dtroyer have a launchpad or something that we can add that to, or should we keep it in keystone?
18:21:45 <heckj> (er, keystonelclient project)
18:22:04 <ayoung> heckj, I can find out
18:22:19 <dolphm> https://launchpad.net/python-openstackclient
18:22:22 <heckj> I'm good with it either way - just think we should keep this close to unifiedCLI work if we can
18:22:29 <ayoung> +1
18:22:39 <dolphm> https://bugs.launchpad.net/python-openstackclient/+bug/1030440
18:22:41 <uvirtbot> Launchpad bug 1030440 in python-openstackclient "keyring support for openstack client" [Undecided,New]
18:23:06 <ayoung> #action ayoung to write up blueprints for using keyring for client side token caching as part of python-openstackclient
18:23:17 <marek_> Are you assuming that all clients will have to store the tokens somewhere since heystone server only stores the hash? what is returned when the user asks for the token with the same credentials? Are you going to issue  a new one or regenerate the old one.
18:23:38 <ayoung> marek_, they get a new one, since it will have a new timeout value
18:24:16 <dolphm> does the keyring api let us delete cached tokens once they expire?
18:24:16 <ayoung> marek_, a comparison other is Kerberos.
18:24:35 <ayoung> So in this case, the Kerberos credentials cache is the analogue of using keyring
18:24:39 <marek_> How many active tokens can a user hold?
18:25:09 <ayoung> dolphm, NO idea...but if it does not, we can delete any old tokens when we get a new one
18:25:24 <dolphm> http://pypi.python.org/pypi/keyring/#api-interface is this what we're talking about?
18:25:26 <ayoung> marek_, potentially multiple...one per tenant would be the expected case
18:25:36 <ayoung> dolphm, I *think* so
18:25:56 <dolphm> ayoung: pip-requires for the proposed page references 'keyring'
18:26:01 <dolphm> proposed patch*
18:26:11 <ayoung> dolphm, right...
18:26:26 <ayoung> dolphm, so keysring is just a front to a handful of different stores
18:26:36 <ayoung> GnomeKeyring, KDEWallet
18:26:50 <ayoung> ideally it would handle openssh and Mozilla NSS dbs...
18:26:57 <ayoung> but I digress
18:27:41 <ayoung> but there is no dedicated process.  SO any work has to be done on the process that access the keyring
18:28:29 <ayoung> I'd like top move on
18:28:35 <dolphm> sure
18:28:53 <ayoung> enable: token_format = PKI | uuid
18:29:01 <ayoung> decideing when to swith over
18:29:04 <ayoung> switch
18:29:18 <dolphm> in keystone.conf?
18:29:29 <ayoung> dolphm, let me restate
18:29:36 <dolphm> or is this a poll lol
18:29:43 <ayoung> criteria for switching from UUID to PKI as the default
18:30:14 <ayoung> that is what I meant to have in the agenda.  The config option is already decided
18:30:28 <ayoung> so, I think a *must have* feature is revocation
18:30:51 <ayoung> are there are any other criteria we need to meet before we flip the default to PKI tokens?
18:31:03 <dolphm> timing with release milestones?
18:31:06 <ayoung> I think it is clear that we will leave the ability to do UUID tokens in as part of keystone
18:31:09 <dolphm> > grizzly day 0?
18:31:28 <ayoung> dolphm, I'd hoped to have it in Folsom
18:31:33 <ayoung> is that even possible now?
18:31:41 <dolphm> as a default?
18:31:46 <ayoung> yes
18:32:14 <dolphm> i'd say we need to ship uuid as default for folsom, but i'd like to switch asap after
18:32:24 <gyee> +1
18:32:46 <ayoung> OK.  I think I am OK with that
18:32:53 <ayoung> let me rephrase the question, then
18:33:12 <ayoung> assumign that we need a fully functional PKI token as an alternative auth mechnism in Folsom, what else does it need?
18:34:14 <dolphm> revocation -- what was the conclusion on the mailing list? GET /tokens/revoked, and let clients cache the result?
18:34:25 <ayoung> dolphm, basciially, yes
18:34:33 <dolphm> does support for that (middleware included) need to land in folsom?
18:34:36 <gyee> if you are going to implement revocation, what benefits does PKI token have? :)
18:34:44 <ayoung> dolphm, yes, I think it does
18:35:01 <ayoung> gyee, it will still be a lot less chatty than UUID tokens
18:35:34 <ayoung> you are talking one RPC request per timeout period as opposed to multiple RPCS per request
18:35:38 <dolphm> gyee: revoked token list could be checked & cached every minute, for example, instead of GET /tokens/{token_id} per token, several times a second
18:35:39 <gyee> not sure about that
18:36:34 <ayoung> plus..I think that revocation should be optional.  I suspect that most people would want it.  But with revocation, you could have tokens for a long period of time (weeks) and have a short revocation cache window (hours) if you wanted
18:36:37 <heckj> gyee: what you expectging otherwise there
18:37:03 <gyee> if they want revocation, use UUID tokens
18:37:09 <heckj> ayoung: i like the optional revocation setup
18:37:32 <gyee> there's a reason why OCSP failed :)
18:37:36 <ayoung> heckj, I'll make sure that is noted in the blueprint
18:37:48 <gyee> complexity versus benefits
18:37:53 <dolphm> i imagine GET /tokens/revoked will be a very small request with (generally) an empty response... way better than a giant PKI GET request, with a giant pki response
18:39:03 <rafaduran> and what about an RPC call to do revokation explicit?
18:39:08 <ayoung> dolphm, yes, that is what I foresee as well:  a signed document if there is anything, an empty document otherwise.  Document will be nothing more that [HASH1,HASH2]
18:39:32 <ayoung> rafaduran, you mean to revoke a token?  There are ways of doing that now.
18:40:14 <ayoung> rafaduran, at a minimum, I know that all tokens for a user account get revoked when the account is deactivated
18:40:36 <ayoung> let me see if we havea deliberate revoke_token API...I can add that, too if needs be
18:40:45 <ayoung> BTW< tokens also get revoked on password change
18:41:05 <ayoung> OK.  15 minutes left.  I can surrender the floor
18:41:28 <ayoung> #action  UUID tokens will be default for Folsom
18:41:48 <heckj> ayoung: revokation of uuid tokens has been invoking a delete /token/UUID
18:41:55 <ayoung> #action PKI tokens will ship in Folsom with revocation.
18:41:55 <dolphm> ayoung: DELETE /tokens/{token_id} is part of the api
18:42:35 <ayoung> I figured as much...just realized I hadn't looked directly.  I reviewed the changes for the password/account revocation cases, so I knew we already had some ways...
18:43:32 <ayoung> heckj, floor is yours
18:44:09 <heckj> uh, hi?
18:44:32 <heckj> as usual, highly distracted
18:44:36 <dolphm> HI, HECKJ!
18:44:44 * heckj needs more coffee
18:44:50 <heckj> Okay - other topics
18:45:30 <gyee> what's the feature cut off date for folsom?
18:45:34 <heckj> #topic API changes
18:45:42 <heckj> gyee: Aug 16th or so
18:45:42 <ayoung> heckj, the reason I put "API Changes " on the agenda was to trigger a review of the changes done thus far
18:45:53 <heckj> Okay - how about summit topics
18:46:01 <heckj> #topic blah blah open discussion
18:46:03 <ayoung> heckj, one sec
18:46:20 <ayoung> the question of API stability was a big topic on the main list
18:46:21 <heckj> kk
18:46:22 <dolphm> lol
18:46:34 <ayoung> we've made some changes to the API, specifically to the return codes
18:46:36 <dolphm> v3 stability?
18:46:39 <heckj> ayoung: yeah
18:46:41 <ayoung> no v2
18:46:43 <dolphm> ah
18:46:51 <dolphm> what return codes? i must have missed this
18:47:01 <ayoung> so the question is, if someone coded against v2 for essex, is it going to break against v2 in folsom?
18:47:16 <heckj> Somewhere in there (I'm missing the reviews), we approved some changes that were subtle tweaks to the V2 api return codes
18:47:18 <ayoung> dolphm, 403 vs 402 type stuff is what I've noticed
18:47:43 <ayoung> heckj, right, so the question is:  is this OK, is it a big deal,  who are we going to annoy...?
18:47:46 <heckj> In general, I'm very much in favor of the "keep the API static" - there's almost no means of versioning like a 2.1 in a meaningful way
18:47:50 <ayoung> I guess that is more than one question
18:47:54 <dolphm> i thought 403 vs 402 was all straightened out -- i think we changed it and reverted it
18:48:05 <heckj> we did - but it's worth bringing up
18:48:10 <ayoung> dolphm, if that is the case, great
18:49:15 <gyee> 402 or 420? :)
18:49:20 <gyee> just kidding
18:49:29 <ayoung> gyee, we aren't writing a twitter client here...
18:49:40 <heckj> Unless anyone disagrees, I'd like to assert that we'll generally abide by the API stability policy that the crew on the ML defined out
18:50:12 <ayoung> heckj, I think that is a given
18:50:24 <ayoung> my question was, have we done so thus far?
18:50:36 <ayoung> Itsounds like we have at least made a best effort to do so
18:50:51 <dolphm> heckj: link?
18:51:07 <heckj> ayoung: we've been pretty darned good
18:51:11 <heckj> dolphm: link in a sec...
18:51:16 <dolphm> for meeting officiallity
18:51:27 <heckj> #link http://wiki.openstack.org/APIChangeGuidelines
18:51:54 <heckj> It's a pretty good set of general guidelines (FWIW)
18:52:00 <ayoung> OK to table the summit topics to next week?
18:52:23 <heckj> yep - we're running out of time. I'll update the wiki agenda with the notes, and I think we're good.
18:52:37 <ayoung> Oh..one other thing,  gyee and I talked, and it looks like Domains will have to wait until Grizzly
18:52:47 <ayoung> no big surprise there
18:52:50 <heckj> darnit. I understand, but darnit
18:53:02 <ayoung> but It does mean we can do all the work in /v3/
18:53:23 <heckj> I haven't had the time to knock in much code this past release.. working to get that better
18:53:52 <dolphm> speaking of v3... https://review.openstack.org/#/c/9744
18:54:17 <dolphm> i added /v3 to keystone.conf, and laid down some new routers and whatnot
18:54:57 <heckj> dolphm: nice
18:55:09 <heckj> I'll do some lookin'
18:55:12 <dolphm> also some v3 testing infrastructure which runs against wsgi directly, since we don't have keystoneclient support yet (chicken and egg)
18:55:48 <gyee> dolphm, is the RBAC stuff ready for action?
18:55:51 <heckj> dolphm: I'd like to get the keystoneclient stuff in first (not that it's happened)
18:56:12 <heckj> dolphm: for the primary reason of setting up the tests and then filling in the implementation
18:56:21 <dolphm> gyee: you review it and tell me :)
18:56:28 <gyee> k
18:57:08 <dolphm> heckj: is there a keystoneclient bug for v3 work?
18:57:11 <dolphm> or bp
18:57:18 <heckj> dolphm: yep
18:58:12 <ayoung> we still working with https://docs.google.com/document/d/1VP-bTBbwsn6q-rDzuS9CEKb2ubE1VjbWRFd4BkkjoOY/edit?pli=1
18:58:35 <dolphm> ayoung: i am, so i hope so :)
18:59:00 <ayoung> Can we move this over to wiki soon?
18:59:04 <ayoung> I'll volunteer
18:59:43 <dolphm> ayoung: the draft itself?
18:59:48 <heckj> ayoung: OK by me, but recall we're keeping it "open" to learn from implementation
19:00:00 <heckj> need to wrap this up so mtaylor doesn't smack me around
19:00:06 <heckj> #endmeeting