18:10:10 <heckj> #startmeeting keystone 18:10:11 <openstack> Meeting started Tue Nov 27 18:10:10 2012 UTC. The chair is heckj. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:10:13 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:10:15 <openstack> The meeting name has been set to 'keystone' 18:10:18 <heckj> Folks till around? 18:10:30 <heckj> ayoung, dolph, gyee, dwchadwick? 18:10:37 <gyee> here 18:11:09 <heckj> afraid I'm running very late and on no sleep 18:11:42 <heckj> #topic agenda http://wiki.openstack.org/Meetings/KeystoneMeeting 18:11:57 <henrynash> hi 18:12:01 <heckj> morning henrynash 18:12:05 <heckj> (well, morning for me) 18:12:12 <henrynash> ;-) 18:12:21 <heckj> Any high priority or burning issues? 18:12:48 <henrynash> so for me, its the infamous groups vs attribute-role mapping 18:13:01 <gyee> I need to take care of the keyring thingy for keystoneclient 18:13:10 <heckj> kristy? dwchadwick - either of you around today? 18:13:31 <heckj> gyee: I at least found the keyring issue for you - did you get those notes? 18:13:38 <dolphm> i just realized my cup is leaking quite rapidly onto my desk (not sure if that counts) 18:14:18 <heckj> dolphm: that sounds rather important, I'd recommend dealing with it immediately 18:14:30 <dolphm> heckj: fine, brb 18:15:07 <heckj> We have a bug that's been reported that happens under higher load - a path to get resolved, but not clear implementations 18:15:29 <gyee> heckj, yeah, thanks, I am going to make the changes 18:15:32 <heckj> bug: https://bugs.launchpad.net/keystone/+bug/1020127 18:15:33 <uvirtbot> Launchpad bug 1020127 in keystone "proxy-server Error: Second simultaneous read or write detected" [High,In progress] 18:15:43 <henrynash> we still on? 18:15:43 <gyee> question is, should we disable keyring by default 18:15:58 <gyee> or override it via env var in devstack 18:16:09 <heckj> Alex Yang is supposedly working on moving the memcachering (eventlet safe memcache client) into openstack common, but it's biting some folks using keystone at a high velocity 18:16:42 <heckj> henrynash: yeah, just getting back up to speed 18:17:09 <henrynash> ok, I'm on a rather flaky internet connection from Tunisia ! 18:17:24 <heckj> let's hit the attribute setup pieces in a second - sounds like the biggest topic 18:17:52 <heckj> gyee: How are the other projects using it? i.e. how does novaclient do this (since it has keyring support) 18:18:42 <gyee> heckj, good suggestion, we need to be consistent, I'll go find out 18:19:40 <heckj> #topic attributes, role mapping, etc - ABAC and RBAC 18:19:45 <heckj> ayoung: around? 18:20:26 <heckj> henrynash: I haven't come up to speed with the role mapping concept - ABAC in itself seems pretty straightforward, but it's not at all what we have in V3 right now 18:20:47 <henrynash> agreed 18:21:07 <heckj> I'm generally trying to figure out what's been requested for work - making V3 work cleanly or resetting this whole kit to an ABAC based system 18:21:14 <gyee> I thought roles are nothing more than just a string, the services interpret/enforce the roles 18:22:07 <heckj> gyee: yep - that's not a problem, and I like the concept of the ABAC system in general, but it's not at all what's in our policy engine and there's pending work to change the token API, present additional attributes, and pass them into the policy engine effectively. 18:22:08 <henrynash> I think the (short term) decision is whether we support groups/organisation roles via something like the user-group extensions to RBAC, or introduce attributes in some kind of "local mapping mode" to implement the same fucntionality 18:22:59 <heckj> gyee, henrynash: do you have a preference for either implementation focus? Does using a local mapping mechanism get us closer to ABAC in the future? 18:23:18 <heckj> dolphm: when you're back, would like your input on ^^ 18:24:26 <dolphm> heckj: i'm back, but don't have much input (just interested in seeing where the communities long term preferences lie) 18:24:35 <dolphm> community's 18:24:40 * heckj nods 18:24:45 <henrynash> heckj: Not as currently defined - the current spec seems only half the story (as per my email) 18:25:17 <heckj> henrynash: sorry, which is only half defined - the V3 RBAC setup, or the ABAC/extension pieces? 18:25:37 <henrynash> I think if we did implement what was needed in a local mode, then actually you would end up with exactly the same spec (albeit with a few more layers thrown in) as the user-group spec 18:26:14 <henrynash> ..maybe group membership is just another attribute to be taken into account when we finally implement ABAC 18:28:40 <gyee> group is transparent in the RBAC model I think 18:29:35 <heckj> gyee: transparent? not sure I understand you 18:30:27 <gyee> RBAC authorize on roles, not group 18:30:30 <gyee> groups 18:30:49 <henrynash> <sorry internet going up and down so may miss questions> 18:30:59 <heckj> gyee: ah, yes - in that respect it is transparent 18:30:59 <gyee> groups are there to make role assignment easier 18:31:11 <henrynash> gyee : =1 18:31:15 <henrynash> +1 18:32:09 <heckj> so it seems like short term, implementing a groups REST API mechanism for managing sets of users to projects is the optimal path. 18:32:22 <henrynash> heckj : +1 18:32:25 <gyee> +1 18:32:36 <heckj> With an idea to keeping that API to present the same interface back to customers, but converting the underpinning to ABAC in the long term 18:33:08 <heckj> henrynash: Have you made updates to your proposed spec based on feedback received? 18:34:12 <henrynash> I'm happy to have the bp assigned to me for implementation 18:34:50 <heckj> henrynash: K - we'll go with that and start rolling there 18:35:19 <heckj> dolphm: you'd opened some bugs and noted some issues with the initial V3 API in the past two weeks - any tags or notes related to that you can share? 18:36:47 <dolphm> heckj: just that the service+endpoint spec has evolved far beyond the current implementation... migrating the sql driver to the new model and supporting both v2 CRUD and v3 CRUD will be tricky (the service catalog response will be trivial in either case) 18:37:26 <ayoung> heckj, ah...got the time wrong 18:37:29 <dolphm> heckj: for example, each current endpoint will suddenly have 3 ID's in the v3 spec, but still need to be accessible via the original ID in the v2 spec 18:37:33 <heckj> ayoung: heh 18:37:42 <gyee> for for v3, token APIs are still /v2.0? 18:37:59 <dolphm> gyee: no, there's just no v3 implementation yet 18:38:05 <gyee> k 18:38:12 <dolphm> gyee: and i think the v3 spec on that topic needs some attention 18:38:18 <gyee> oic 18:38:31 <gyee> same goes for middleware then? 18:38:44 <dolphm> gyee: what about middleware? (auth_token?) 18:39:00 <gyee> yes, its not using /v3 at the moment 18:39:29 <heckj> gyee: most of that API remained the same and during the original V3 development work was directly compatible 18:39:31 <dolphm> gyee: right 18:39:50 <heckj> dolphm: where are you focused at the moment? 18:39:57 <dolphm> gyee: the auth_token contract with the underlying service won't change (although we could expose X-Domain-Id / X-Domain-Name if we want to) 18:40:22 <dolphm> heckj: v2 vs v3 catalog driver 18:40:29 <dolphm> heckj: trying to figure out how to support both 18:40:29 <heckj> dolphm: cool 18:41:01 <gyee> dolphm, nah, domain need not be exposed to the services at the moment 18:41:04 <heckj> dolphm: did you ever port the token changes from your development/feature branch into master for Token? 18:41:21 <heckj> (i.e. is there anything more that needs to get moved over)? 18:41:23 <ayoung> heckj, what changes? 18:41:44 <dolphm> gyee: agree, but i expect metering & billing projects to want that data 18:41:56 <heckj> ayoung: the V3 implementation of the token API in the V3 feature branch 18:41:57 <dolphm> heckj: no, i never made any 18:42:10 <dolphm> heckj: there is no v3 token impl 18:42:15 <heckj> Okay - so V3 token implemenation is still pending 18:43:04 <ayoung> heckj, isn't that basically the gyee work on getting the tokenid out of the URL anyway? 18:43:09 <gyee> heckj, yeah, we need to figure out the auth pluggins 18:43:21 <gyee> ayoung, and that too :) 18:43:23 <heckj> ayoung: yep - 18:43:26 <dolphm> heckj: long term, are we okay with deprecating & removing all non-auth related v2 calls & extensions? (i think we need to maintain full support for /v2.0/tokens for quite a while) 18:43:35 <ayoung> dolphm, +1 18:43:43 <heckj> dolphm: yes, definitely 18:43:49 <henrynash> +1 18:44:05 <gyee> so I do the stop-tokin-in-uri thingy on /v2.0 for now? 18:44:05 <heckj> dolphm: we just need to be very clear about deprecation and what's available/supported and when 18:44:08 <ayoung> dolphm, but we probably need a way to turn off the token ID in the URL 18:44:31 <dolphm> ayoung: i think the answer to that is to use v3, and make v2 support a deployment option 18:44:37 <heckj> gyee: I think you want to do that in a /v3 API mapping, using most of what's already there for token support 18:44:37 <ayoung> dolphm, agreed 18:44:49 <dolphm> ayoung: i.e. remove v2 support from the pipeline if you think it's a security issue in your deployment 18:45:14 <heckj> ayoung: token ID in the URL is intrinsic to the API - the only way we get away from it is to deprecate the V2 API 18:45:16 <ayoung> dolphm, yes. gyee can you factor that into your approach? 18:46:12 <ayoung> heckj, well, we want to deprecate it, but a security conscious deployment should be able to avoid it all together. Part of that is disabling it at keystone so you know that other services can't use it without you knowing 18:46:13 <heckj> ayoung: how are you envisioning making v2 API support optional? 18:46:30 <ayoung> heckj, config option? 18:46:30 <heckj> ayoung: like the idea to make it optional 18:46:43 <heckj> config option or asking customers to change their paste.ini? 18:46:50 <ayoung> yes, defaults V2_Tokens=True 18:47:14 <ayoung> but setting to False shuts down accepting them 18:47:14 <dolphm> ayoung: heckj: it's already sort of optional (there's just nothing to replace it) 18:47:38 <ayoung> dolphm, there is also no way to yank it yet 18:47:57 <heckj> dolphm: I'm just missing it this morning 18:48:07 <dolphm> ayoung: sure there is, remove it from your keystone.conf (v2 is isolated from v3 there) 18:48:17 <heckj> gyee: are you good to move forward with what dolphm and ayoung are suggesting? 18:48:30 <ayoung> I mean, you could yank the whole v2 API...I was just thinking the tokenID in the URL piece (tokens) 18:48:55 <ayoung> but I guess going V3 pure would be a viable solution 18:49:23 <gyee> so I am going to impl the v3 token APIs? 18:49:28 <heckj> ayoung: would be less work than partially disabling V2 APIs 18:49:48 <heckj> gyee: yes - and include the stop-id work in there 18:49:53 <gyee> k 18:50:02 <gyee> but leave the v2 APIs along for now 18:50:26 <heckj> yep - we'll plan to deprecate them, at least the token part - but ideally the whole V2 API set 18:50:27 <ayoung> OK, that should work...it means that it would be Grizzly only, and not something independently back portable, but so be it 18:50:37 <dolphm> heckj: +1 18:50:42 <heckj> ayoung: never expected it to be back-portable 18:50:59 <gyee> not backportable since the auth content is different 18:51:25 <heckj> only a few minutes left 18:51:28 <heckj> #topic open discussion 18:51:35 <heckj> henrynash you good? (if yo'ure still with us) 18:51:42 <ayoung> heckj, can I get a final blessing on the normalize patch? 18:51:46 <henrynash> yes, been in and out! 18:51:49 <ayoung> https://review.openstack.org/#/c/16322/ 18:51:50 <heckj> ayoung: where are you focused? How's identity coming along? 18:52:04 <ayoung> heckj, I am working on preauth..now renamed to trusts 18:52:28 <heckj> ayoung: trusts huh? Did you update the blueprint or is that an internal convention naming thing? 18:52:32 <ayoung> I like the name trust. A trust has a truster and a trustee 18:52:42 <ayoung> https://blueprints.launchpad.net/keystone/+spec/trusts 18:53:00 <heckj> cool 18:53:18 <ayoung> I've done a lot of vetting of names. All names have some limitation. This had the least 18:53:21 <ayoung> it maps to intention 18:53:28 <heckj> ayoung: will do the identity review today 18:53:51 <heckj> ayoung: sounds good - isn't this predicated on passing in auth/authN refactor? - where's that sitting? 18:53:57 <ayoung> the word 'trusts' are used in Kerberos, but it is a slightly different level: cross domain trusts. There are user to user trusts 18:54:11 <ayoung> heckj, a good chunk of the refactor was done. 18:54:31 <heckj> ayoung: more outstanding while you work on trusts? 18:54:40 <ayoung> I think I will weave the additional refactoring work in to the trusts...I don't want to shut down dev on service.py if I don't need to 18:54:41 <heckj> ayoung: or is someone else tracking on that work? 18:54:55 <heckj> cool 18:55:23 <ayoung> heckj, Iike the current refactor state, as it is at least readable/maintainable. I can foresee doing much more in the future, but under the guise of other features 18:55:43 <heckj> ayoung: sounds good 18:55:56 <ayoung> trusts by themselves should add an addition set of functions to the Authenticate code path, but they should be isolated from the authenticate function itseld 18:55:58 <ayoung> f 18:56:24 <heckj> I'm going to focus on that bug I mentioned at the top of the discussion - not sure how much traction I'll get between now and next week, but I'll at least try and get a repro running for it 18:57:06 <ayoung> ie... there will be an additional conditional that we are dealing with a trust request, and that will call a function that will prevent calling REMOTE_USER etc. I'll shoult when I get closer to that, right now I am working over the SQL schema and unit tests for the back end 18:57:33 <ayoung> heckj, are you referring to the swift thing? 18:57:40 <heckj> ayoung: yeah 18:57:50 <ayoung> I think the right solution there is to stop using memcached as the cache 18:58:18 <ayoung> memcached and eventlet don't play nice. I hate being a playground referee 18:58:20 <heckj> ayoung: and use what instead? memcachering was proposed - sounded OK to me with a move into openstack common 18:58:29 <ayoung> yes, that is the solution 18:58:48 <dolphm> ayoung: is that what you mean by "stop using memcache"? 18:58:58 <ayoung> assuming memcache ring doesn't have any baggage of its own... 18:59:06 <ayoung> dolphm, we don't want to make a blocking call to cache 18:59:13 <ayoung> so, KVS 18:59:30 <ayoung> something that times out like memcached, but that is purely in memory 18:59:36 <gyee> I got burned with blocking calls in middleware once :) 18:59:50 <ayoung> dolphm, only for auth_token users that are running in eventlet 18:59:54 <ayoung> say they are running in apache under prefork mode, they should use memcached 19:00:10 <heckj> ayoung: right now, we don't even have any means of reproducing the issue and verifying that it's resolved - so focusing on that first 19:00:17 <ayoung> so memcache ring is, I think, an abstraction that lets us swap one or the other in 19:00:19 <ayoung> But I want that confirmed 19:00:57 <heckj> ayoung: read the code - it's not a complete memcache replacement, but it's darned close - does what's needed, and there's equiv art elsewhere in use 19:01:12 <heckj> ayoung: I noted as such in the blueprint to push that into openstack-common 19:01:15 <ayoung> heckj, can we ask them to run with a hacked auth_token that uses kvs and see if the problem goes away? 19:01:49 <heckj> ayoung: the guy asking/reporting the bug isn't in to hacking code or he'd already have this solved 19:02:03 <heckj> I've got to run to another meeting 19:02:06 <heckj> #endmeeting