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