18:02:21 <ayoung> #startmeeting Keystone
18:02:23 <openstack> Meeting started Tue Dec  3 18:02:21 2013 UTC and is due to finish in 60 minutes.  The chair is ayoung. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:02:24 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:02:26 <openstack> The meeting name has been set to 'keystone'
18:02:35 <ayoung> Oyez Oyez....
18:02:38 <morganfainberg> #ayoung beat me to typing it.
18:02:54 <ayoung> https://wiki.openstack.org/wiki/Meetings/KeystoneMeeting#Weekly_Keystone_team_meeting
18:03:05 <jamielennox> morganfainberg really wanted to be king for the day
18:03:14 <morganfainberg> jamielennox, i'd just delegate it.
18:03:22 <ayoung> #topic Tempest change for assignments-doesn't-check-identity
18:03:25 <jamielennox> morganfainberg: that's the point of being king
18:03:34 <ayoung> The floor recognized bknudson
18:03:36 <bknudson> ok, I put this one on there.
18:03:38 <ayoung> recognizes
18:03:52 <bknudson> so henrynash (not here) had commented in a previous commit
18:04:07 <bknudson> that we shouldn't be checking against identity API from assignments
18:04:19 <bknudson> e.g., grant role or whatever shouldn't check that the user exists.
18:04:33 <bknudson> which makes some sense especially if using LDAP...
18:04:38 <ayoung> bknudson, agreed.  In the case of Federation, we will not be able to do active lookups
18:04:39 <bknudson> user could go away right after you check it.
18:04:49 <bknudson> so I made that change in keystone
18:04:53 <bknudson> but it fails tempest
18:05:08 <morganfainberg> bknudson, so 3-way tempest change?
18:05:10 <bknudson> because they added a test that if user doesn't exist then should fail
18:05:14 <ayoung> bknudson, are the tempest tests too restrictive?
18:05:19 <gyee> bknudson, how are we going to cleanup the data
18:05:22 <bknudson> ayoung: that's kind of my question
18:05:29 <ayoung> OK,  lets put in a change request to drop that test from tempest
18:05:34 <bknudson> the identity spec doesn't say that it fails specifically
18:05:34 <gyee> I would imagine roles assignment will need to be cleanup at some point
18:05:42 <gyee> just like expired tokens
18:05:46 <ayoung> It should not fail
18:05:57 <morganfainberg> i would agree, it shouldn't fail
18:05:58 <ayoung> its just a rule that will never be triggered
18:06:03 <bknudson> for the tempest change, I'll need a blueprint, and not sure if we had one.
18:06:20 <bknudson> it's probably the federation one
18:06:20 <morganfainberg> bknudson, use the split assignment/identity one?
18:06:23 <ayoung> bknudson, can't we use the Keystone blueprint?  File it under Federation
18:06:25 <morganfainberg> bknudson, or federation
18:06:35 <ayoung> split id is better
18:06:46 <bknudson> ok, I'll point to the split ID one.
18:06:57 <bknudson> I think that's all I needed.
18:07:12 <ayoung> #topic REMOTE_USER auth v2 and v3 mismatch
18:07:13 <bknudson> My change to the tempest test was to accept either NotFound or success.
18:07:16 <bknudson> they didn't like that.
18:07:21 <morganfainberg> bknudson, also, iirc tempest likes you to @skip the test, then change keystone, then unskip/fix test
18:07:33 <morganfainberg> bknudson, at least that was needed for the token 403 vs 404 one
18:07:39 <ayoung> morganfainberg, in this case, just drop the test, or the check
18:07:52 <morganfainberg> ayoung, right, i meant if we were keeping the test.
18:08:07 <bknudson> It seems "correct" to me to actually accept either 404 or 200 in this case...
18:08:24 <bknudson> since identity api doesn't really say what it does
18:08:42 <bknudson> Alright, moving on to REMOTE USER
18:08:47 <bknudson> maybe you had a chance to look at this
18:08:56 <bknudson> but v2 doesn't use plugin so does remote auth its way
18:09:03 <bknudson> v3 uses plugins so does remote auth its way
18:09:17 <bknudson> so you can easily put yourself in a situation where v2 remote auth works and v3 doesn't
18:09:21 <morganfainberg> this is the user w/ @ in the name?
18:09:22 <bknudson> or vice-versa
18:09:28 <ayoung> bknudson, so you want to make V2 honor the v3 plugins?
18:09:29 <morganfainberg> and other... oddities
18:09:39 <bknudson> yes, the problem is typically handling @ in the name
18:09:52 <bknudson> since that's what our supplied external auth plugins do differently
18:10:12 <bknudson> ayoung: I think it makes sense for v2 to use whatever plugin is used for v3...
18:10:18 <ayoung> bknudson, no reason the v2 token controller can't call the v3 plugins.
18:10:24 <bknudson> but I haven't looked into if there's any reason it wouldn't work.
18:10:30 <ayoung> problem solved.
18:10:35 <ayoung> Next topic?
18:10:36 <morganfainberg> ayoung, as long as you wedge in issue_v2_token.
18:10:40 <jamielennox> doesn't that change how v2 auth works?
18:10:40 <morganfainberg> ayoung, but not a big deal
18:10:43 <ayoung> morganfainberg, nah,
18:10:53 <ayoung> plugin just does authentication
18:11:01 <bknudson> jamielennox: it doesn't have to change how v2 auth works if you use the "correct" plugin?
18:11:02 <ayoung> it doesn't get into the token creation code
18:11:11 <morganfainberg> ayoung, doesn't it also issue the token? erm call the token issuancE?
18:11:17 <morganfainberg> ayoung, i might be thjinking something else
18:11:26 <bknudson> but, I haven't looked into it
18:11:26 <ayoung> jamielennox, it would be a backwards compatible change
18:11:32 <ayoung> morganfainberg, this is auth plugins, not token provider
18:11:40 <morganfainberg> ayoung, hm. ok.
18:11:51 <jamielennox> bknudson: so you want to expose the plugins as configurable to v2 as well - default to the old form?
18:11:56 <bknudson> there's already work in progress to clean up auth plugins, so I think we let that progress and then can consider using plugin for v2
18:12:14 <ayoung> V2 can call https://github.com/openstack/keystone/blob/master/keystone/auth/plugins/external.py  if it REMOTE_USER gets triggered
18:12:28 <bknudson> jamielennox: I would guess that for backwards compat they'll have to be separately configurable.
18:12:34 <ayoung> from here...https://github.com/openstack/keystone/blob/master/keystone/token/controllers.py#L281
18:13:01 <morganfainberg> bknudson, i think there is still a fix needed in the V3 plugin... inconsistent behavior (as we discussed before) but it's not as bad as v2 vs v3 at the moment
18:13:03 <jamielennox> bknudson: yea, because the default needs to be different between versions - that works for me
18:13:22 <ayoung> morganfainberg, we can always make more plugins
18:13:28 <morganfainberg> ayoung, right.
18:13:37 <ayoung> we good to move on?
18:13:43 <bknudson> yes, thanks.
18:13:53 <jamielennox> is there a reason we can't just use the v3 one?
18:13:54 <bknudson> oh, one more q
18:14:00 <bknudson> backporting the fix... worth it?
18:14:14 <ayoung> bknudson, lets see how invasive it is, but I suspect no
18:14:14 <jamielennox> because as it stands if using REMOTE_AUTH you would only be able to use v2 or v3 at the moment anyway
18:14:27 <bknudson> apparently we made backwards-incompat change in H
18:14:37 <bknudson> and V2 vs V3 is broken in H
18:14:47 <bknudson> maybe we just say that you have to write your own external auth plugin.
18:14:55 <bknudson> (for H)
18:15:02 <bknudson> since we're not going to backport
18:15:04 <ayoung> bknudson, we could provide one out of tree
18:15:18 <ayoung> but..if we do that, we should just put it in a bug fix
18:16:05 <ayoung> good to move on?
18:16:09 <bknudson> I think it would be hard to justify the backport
18:16:13 <bknudson> let's move on.
18:16:20 <ayoung> #topic reviews for icehouse blueprints
18:16:30 <ayoung> #topic reviews for icehouse blueprints: API Version Discover
18:16:41 <ayoung> #link https://review.openstack.org/#/c/38414
18:16:52 <ayoung> Merged
18:17:05 <ayoung> #topic reviews for icehouse blueprints: Add federation API
18:17:16 <ayoung> #link https://review.openstack.org/#/c/51980
18:17:34 <atiwari> added some comments on patch #12
18:17:40 <ayoung> There is a lot in those three docs.
18:17:42 <jamielennox> woohoo!
18:18:01 <stevemar> *alot*
18:18:15 <stevemar> i will upload a new version of the spec soon
18:18:15 <ayoung> Might I suggest that we only -1 something for structural changes, not verbage or editing, to get a firm contract?
18:18:24 <marekd> ayoung: i should upload some CRUD for IDPs on gerrit tomorrow (my timezone)
18:18:30 <ayoung> stevemar, any thought on splitting that review?
18:18:44 <ayoung> or do you want all three to live/die together?
18:18:45 <stevemar> ayoung, it doesn't bother me that it's all in one
18:18:54 <ayoung> OK
18:18:58 <atiwari> +1 ayoung
18:19:10 <ayoung> stevemar, you feel like you are making progress?  Ice2 will be here before you know it
18:19:15 <atiwari> I think splitting wd work better
18:19:23 <marekd> +1 atiwari
18:19:35 <lbragstad> atiwari: FWIW, i think so too
18:19:56 <atiwari> ayoung, too much content in one review
18:19:56 <stevemar> marekd is submitting a patch to keystone for the idp changes, (based on the current spec state)
18:20:14 <lbragstad> it could almost be broken up into commit for each blueprint...
18:20:18 <ayoung> lets prioritze the mapping one.  That stands alone, and will be useful even if we don't get the whole Federation BP iplemented by I2.
18:20:47 <stevemar> ayoung, yeah, i'm starting to actively work on the impl for that one now, i think the current api spec is close
18:21:01 <stevemar> chadwicks folk like it, so thats a big plus
18:21:06 <ayoung> Federation and IdP can go into I3.  They would be disabled by default, but that is probably OK for people that want Federation support to explicitly enable it.
18:21:16 <morganfainberg> ayoung, ++ i think that is fine
18:21:32 <stevemar> yep, of course
18:21:47 <gyee> ayoung, isn't there a long running Keystone policy that API changes need to be done by I2?
18:21:51 <morganfainberg> ayoung, for J we can enable it by default.  actually kindof like the new feature, disabled by default, next cycle enable if desired / fix and enable
18:21:52 <ayoung> #action stevemar to split API reviews into Mapping and Federation reviews
18:21:57 <stevemar> okay, i can break up the api spec into multiple reviews
18:21:59 <ayoung> morganfainberg, yep
18:22:24 <morganfainberg> gyee, yes, but the SPEC will be done and this shouldn't have any api incompatible changes (extension)
18:22:51 <morganfainberg> gyee (or just disabled even if not an extension)
18:22:51 <ayoung> #topic reviews for icehouse blueprints: Revocation Events
18:23:04 <ayoung> #link https://review.openstack.org/#/c/59546
18:23:12 <ayoung> This one is mine.  Please beat it up accordingly
18:23:52 <ayoung> this needs to go in by I2, and I suspect we will also want to add config options to disable some of the features in the current token infrastructure that are providing pain:
18:24:02 <morganfainberg> ayoung, that is looking good (based upon convos at the summit)
18:24:06 <ayoung> namely, the need to explicitly enumerate tokens
18:24:19 <ayoung> morganfainberg, that's what scares me
18:24:28 <morganfainberg> ayoung, yes, please lets make that die a horrible death.  enumerating tokens == bad
18:25:12 <ayoung> morganfainberg, so I want to make it optional, and make the new revocation architecture optional as well.  If someone doesn't want revocations, that should be OK.
18:25:13 <gyee> ayoung, the revocation events are signed too right?
18:25:23 <ayoung> gyee, I wasn'
18:25:30 <ayoung> t doing that as a first approximation
18:25:31 <morganfainberg> ayoung, correct.  eventually events should be the way to go.
18:25:42 <ayoung> but we could add on a signature envelope.
18:25:47 <gyee> I mean we need to CMS envelope them, just like tokens
18:25:58 <morganfainberg> ayoung, we should sign the envelope, we do it already for TRL.
18:26:03 <ayoung> gyee, in theory, we could make Keystone sign anything it publishes....it would be a content wrappper
18:26:11 <ayoung> Accpest:JSON+CMS
18:26:14 <ayoung> or summat
18:26:22 <ayoung> Accpets
18:26:33 <ayoung> #action ayoung to look into signing revocation events
18:26:58 <atiwari> #link any thoughts on https://blueprints.launchpad.net/keystone/+spec/service-scoped-role-definition
18:27:00 <morganfainberg> ayoung, and i'll (hopefully) have the last bugs worked out on key-value-store token stuff so you can base anything you need on that.
18:27:08 <jamielennox> ayoung: i actually like the Accepts: idea - i'm not sure if anyone would use it though
18:27:21 <ayoung> data model will be scope-type = (user|project|domain)  and then scope Id
18:27:49 <ayoung> jamielennox, I'd like to see if there is a standard out there we could use for signing...but yeah, it seesm like it should be an "add on" for any API
18:27:50 <atiwari> now resource scoped as per Devid Chadwick
18:28:03 <ayoung> atiwari, hold on
18:28:24 <ayoung> #topic reviews for icehouse blueprints: KDS
18:28:36 <ayoung> #link https://review.openstack.org/#/c/59600
18:28:47 <ayoung> this is the first of a long chain of jamielennox 's pathces for KDS
18:29:10 <ayoung> the Nova team especially is waiting for this
18:29:11 <jamielennox> this is still fairly raw - but because I am introducing a whole new framework i'm assuming there will be some beating on the architecture
18:29:29 <jamielennox> so the first couple of reviews can be done without understanding the crypto
18:29:50 <morganfainberg> jamielennox, ayoung , i just did an oslo sync and ended up with a far different oslo result
18:29:54 <ayoung> jamielennox, you bhave unit tests in the latter reviews that should server as examples
18:29:58 <morganfainberg> are we missing things in the openstack-common.conf?
18:29:59 <bknudson> seems like we should get the KDS spec first
18:30:12 <ayoung> bknudson, in parallel
18:30:21 <morganfainberg> and i'm not sure how much in oslo-incubator changed since that review was posted.
18:30:25 <ayoung> we can get the infrastructure for KDS in place while we finalize the spec
18:30:27 <jamielennox> morganfainberg: oh - mine was a few days ago
18:30:33 <jamielennox> maybe it's changed
18:30:49 <jamielennox> i'll update the patch
18:30:49 <ayoung> #action do updated oslo sync
18:30:55 <morganfainberg> and you're missing the py3kcompat stuff from the update.py run etc
18:31:11 <lbragstad> not sure if this will apply in time, but I think oslo/nova teams were working on a consistency document for syncs from oslo
18:31:26 <morganfainberg> jamielennox, http://pastebin.com/ZYKEgi0y is what i got.
18:31:26 <jamielennox> morganfainberg: has that changed in that time? i did a fairly standard oslo update
18:31:36 <lbragstad> morganfainberg: and some discussion about reworking update.py
18:31:36 <ayoung> lbragstad, we will have to sync again.  THis is just geting the deps in that KDS needs
18:31:58 <morganfainberg> jamielennox i just ran with the openstack-common.conf as a config and it was missing files you had in yours, just an FYI
18:32:14 <lbragstad> ayoung: right, yeah that makes sense. Just a heads up in case any of that work has an impact on this
18:32:21 <morganfainberg> lbragstad, nod.
18:32:32 <lbragstad> it was something that was discussed in the cross project meeting last week I htin k
18:32:34 <lbragstad> think*
18:32:41 <ayoung> #topic Icehouse 1
18:32:51 <ayoung> #link https://launchpad.net/keystone/+milestone/icehouse-1
18:32:52 <morganfainberg> i really should start attending the cross-project meetings
18:33:05 <nkinder> One more note on KDS.  I'm taking a pass through the spec today.
18:33:07 <ayoung> All BPs implemented
18:33:12 <morganfainberg> w00t!
18:33:13 <ayoung> nkinder, sounds good
18:33:21 <jamielennox> nkinder: thanks
18:33:51 <morganfainberg> oooh, i need to put a series of idenitty proxy tests in still *doh*
18:33:53 <ayoung> nkinder, as I said, we are going to try and get in infrastructure in place in parallel, so we don't need to wait for a finalized spec in order to get jamielennox moving
18:33:54 * morganfainberg scribbles a todo
18:34:20 <bknudson> I posted several comments on the KDS spec on path set 15 ... not sure if those were rejected or what.
18:34:40 <ayoung> #topic service or resource scoped role definition
18:34:47 <ayoung> atiwari, you;re up
18:34:50 <atiwari> great
18:35:13 <atiwari> so, are we cool with Davis's thoughts
18:35:16 <ayoung> #link https://blueprints.launchpad.net/keystone/+spec/service-scoped-role-definition
18:35:20 <atiwari> resource scoped role-def
18:35:25 <atiwari> ?
18:35:28 <ayoung> atiwari, looking
18:35:41 <nkinder> bknudson: patch set 16 addresses many of those
18:35:43 <atiwari> #link https://etherpad.openstack.org/p/service-scoped-role-definition
18:36:13 <bknudson> ok, I'll go through and make the same comments again if it wasn't addressed.
18:36:13 <atiwari> something like link: http://paste.openstack.org/show/54377/
18:36:43 <ayoung> atiwari, where is the active portion of that document
18:36:50 <ayoung> the etherpad
18:36:54 <atiwari> yes
18:37:22 <ayoung> atiwari, where is the active portion of the etherpad that has David's comments?
18:37:24 <atiwari> link : https://etherpad.openstack.org/p/service-scoped-role-definition line 90 to 107
18:38:22 <ayoung> atiwari, there is a misconnect
18:38:24 <ayoung> disconnect
18:38:26 <atiwari> look at link: http://paste.openstack.org/show/54379/
18:38:39 <ayoung> Domains and Services are resources that Keystone knows about.  Files are not
18:39:07 <atiwari> I think it is for future extension
18:39:24 <atiwari> ayoung, +1
18:39:46 <atiwari> but that approach is workable
18:40:27 <ayoung> so lets ignore Files etc for the moment.  THe question you and I have been arguing is "do we scope a role definition to a service, or do we make only  of the existing scoping mechanisms"
18:40:40 <ayoung> does that sum it up?
18:41:01 <atiwari> yes
18:41:17 <ayoung> You've been saying "scope a role definition to a project."  I'e pushed back on that.
18:41:19 <ayoung> I've
18:41:29 <ayoung> so..here is my thinking, to lay it out for the rest of the team:
18:41:33 <atiwari> and in my opinion scoping to service is need to address my use case
18:41:43 <atiwari> and the service scoped token BP
18:41:51 <atiwari> link:https://blueprints.launchpad.net/keystone/+spec/service-scoped-tokens
18:42:07 <ayoung> So I see Service scoping as a shortsighted limitation.  THere are at least two things it fails to address:
18:42:22 <ayoung> 1.  Scope a role to multiple endpoints for a service (but not all)
18:42:31 <ayoung> 2.  Scoped a role to multiple services (but not all)
18:42:46 <ayoung> Role defintions are, currently, a cross cutting concern
18:42:55 <atiwari> ayoung, that is why David'd proposal is good for both
18:43:06 <ayoung> a role is on a project or domain, and is equally applicable across all services
18:43:21 <ayoung> atiwari, has a requirement to scope a role definition to a specific service
18:43:26 <atiwari> ayoung, I am not saying no but it role name which is cross cutting
18:43:40 <atiwari> role-def entity can be separate for all service
18:43:47 <ayoung> so David's scope and my Namespaceing are solving the same proble,
18:43:49 <ayoung> m
18:44:07 <atiwari> ayoung, no
18:44:14 <ayoung> atiwari, hold on
18:44:19 <ayoung> I am truing to explain to the team...
18:44:43 <atiwari> ok
18:45:08 <ayoung> It is a question of Namespacing a role definitin, and then proving access rules for who can modify a role defintion.  To me, this is separate from what the role gets assigned to
18:45:32 <ayoung> The goal is to be able to distinguish betwee "admin" for "keystone" and "admin" for "glance"
18:45:50 <ayoung> that, in the existing approach, is not really covered by role assignments
18:46:02 <ayoung> it could be handled by using projects, however
18:46:21 <ayoung> for example, we could make a project (under the default or admin domain) called Keystone, and another one called glance
18:46:41 <ayoung> then, to do administrative tasks on glance, you would need the admin role on the glance procet.
18:46:50 <ayoung> That is an implicit mapping of role to service
18:47:06 <ayoung> atiwari, 's proposals so far have been around making it an explicit link
18:47:23 <bknudson> have a role called glance-admin
18:47:28 <ayoung> so instead of a user having a role on project, they would have a role on a sevice
18:47:37 <ayoung> bknudson, that is basically namespacing
18:47:45 <jamielennox> ayoung: (when you're finished) are these exclusive? My immediate thought is that when have a role on a project you only get that role in the token if you scope it to the project - if as you say we have a role on a service wouldn't we need to scope the token to a service to make that work
18:48:17 <ayoung> jamielennox, let me address bknudson first, and then I'll come back to that
18:48:22 <shardy> ayoung: +1, then the service can just define a policy rule to control access
18:48:36 <shardy> ayoung: That is essentially the interim solution I've been working on for Heat
18:48:41 <ayoung> bknudson, so he wants the glance admin to be able to define multiple roles, and do so independantly of what other people are creating and managing
18:48:44 <bknudson> so somebody could do this already with roles and policy.json updates ?
18:48:57 <atiwari> ayoung, role assignment must be abstracted from service (or resource) for which assignment is done
18:48:57 <ayoung> basically, the ability to delegate to other users the ability to create role definitions
18:49:20 <ayoung> bknudson, the assignment side can be done, but not the creation
18:49:28 <ayoung> creation of new role defs in a delegated manner is new
18:49:32 <ayoung> and, I think, innovative
18:49:46 <ayoung> the question, then, is how to decide "who can create a new role"
18:50:08 <bknudson> what if we put roles in domains?
18:50:13 <ayoung> bknudson, or projects
18:50:17 <ayoung> bknudson, that was my thought
18:50:43 <gyee> domain-owned roles?
18:50:47 <ayoung> then, a user with the role "roleadmin" on the "glance" project can manage the set of roles for the "glance" proejct, which is mapped to the "glance" service
18:50:53 <bknudson> are they namespaced to the project?
18:51:00 <ayoung> bknudson, that is my proposal
18:51:38 <ayoung> bknudson, so glance would get a top level role  "glance"
18:51:50 <jamielennox> bknudson: would they need to be or is it just something we need to specify in policy?
18:51:51 <ayoung> that would be created by superadmin, and assigned to the glance proejct
18:52:25 <bknudson> jamielennox: I'm just wondering if someone creates "role1" in "glance" can someone else create "role1" in "cinder"
18:52:26 <ayoung> this would be immutable, but "roleadmin"s in the "glance" proejct" could create roles underneath it
18:52:46 <atiwari> namespace or role name should not be service name
18:52:47 <bknudson> and is "role1" in "glance" the same as "role1" in "cinder" or is it different?
18:52:48 <ayoung> bknudson, they would get namespaced "glance":"admin"  adn "cinder":"admin"
18:52:59 <atiwari> that is tight coupling with resource name
18:53:03 <ayoung> atiwari, I would replace "should not" with "does not have to be"
18:53:13 <jamielennox> bknudson: yea - i got that, but is it something we need to mangle the role name of can we just say in the policy file "role1" in "cinder" somehow
18:53:26 <ayoung> atiwari, I would suggest it as documentation.
18:53:54 <ayoung> one other thing:  role Ids would be immutable, but role names would not.
18:53:58 <atiwari> ayoung, at the same time nested role-def are confusing and hard to implement
18:54:03 <atiwari> my view
18:54:41 <gyee> ayoung, only problem is policy acts on role names, not IDs
18:54:49 <ayoung> atiwari, so, you could do something like this:
18:54:58 <gyee> don't believe middleware set the role IDs either
18:55:00 <atiwari> ayoung, I am advocation name space should be made of something immutable
18:55:05 <ayoung> all the standard Openstack services are put into one of three projects:
18:55:10 <atiwari> like system generated id
18:55:14 <jamielennox> ayoung: agree with gyee - renaming roles will be a problem
18:55:17 <nkinder> we would need to be careful that a scoped role is not named the same as a normal (unscoped) role to avoid ambiguity in the policy files.
18:55:18 <ayoung> os-id:  (keystone, KDS)
18:55:29 <ayoung> os_core (Nova, glance, swift)
18:55:37 <ayoung> os-apps (Marconi etc)
18:56:01 <ayoung> and you could do admin on multiple services based on the role a user has in that project, as opposed to specific to the service
18:56:19 <ayoung> nkinder, so..we discussed reserving a separator
18:56:20 <jamielennox> nkinder: with the way that policy is written now, but can we change it so that we can specify "cinder:role1" in policy which is role1 in cinder without having to namespace them
18:56:27 <ayoung> :  or \ or -> or something
18:56:31 <ayoung> to indicate nesting
18:56:33 <gyee> nkinder, we'll need role filtering based on scope
18:56:43 <atiwari> ayoung, that is not a workble because we have 1 to 1 with service and admin
18:56:51 <nkinder> if the policy file has to specify the namespace, that works fine
18:57:00 <gyee> i.e. nova only interested in nova roles
18:57:05 <ayoung> atiwari, 1 to 1 is the degenerate case
18:57:08 <atiwari> gyee +1
18:57:16 <gyee> that's basically what atiwari is trying to address
18:57:19 <atiwari> no it is not
18:57:23 <jamielennox> ayoung: so i'm comfotable with roles belonging to a project or a domain
18:57:47 <atiwari> if nova manage his role and and swift manage his
18:57:50 <nkinder> ok, so nova would only care about "nova:<role>" scoped roles, but doesn't it care about non-scoped roles too?
18:57:52 <jamielennox> if we are going to let user's add roles it's out only choice
18:57:52 <bknudson> we already use domains for namespacing, so that seemed like the more natural fit
18:57:55 <atiwari> what is the problem
18:58:05 <morganfainberg> nkinder, i think that depends on the policy.json
18:58:10 <ayoung> is if a user has a role on the glance service/project, and sends a token with that role assignment in it to the nova service, nova will ignore it.
18:58:12 <atiwari> and keystone admin can manage all
18:58:15 <atiwari> if needed
18:58:22 <morganfainberg> nkinder, so deployer action. not implementation action
18:58:25 <ayoung> nkinder, "care about" only for admin operations
18:58:38 <ayoung> 2 minutes remaining
18:59:46 <ayoung> So my take  :services are not containers, and should not become containers.  Services will not own role definitions directly, but rather will be paired with a project to manage the role definitions.
18:59:49 <atiwari> so all I am trying to get is Nova/ Swift role-def is managed by nova/swift admin of keystone admin
19:00:03 <nkinder> we should just be careful about avoiding ambiguity to prevent one from accidentally granting access when they don't intend to.
19:00:24 <atiwari> ayoung, that is why we should look for David's proposal
19:00:42 <ayoung> Times up
19:00:46 <atiwari> which is not tight linking
19:00:48 <ayoung> #endmeeting