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