18:01:46 <morganfainberg> #startmeeting Keystone
18:01:47 <openstack> Meeting started Tue Dec 23 18:01:46 2014 UTC and is due to finish in 60 minutes.  The chair is morganfainberg. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:01:48 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:01:50 <openstack> The meeting name has been set to 'keystone'
18:02:27 <morganfainberg> So I expect this meeting to be fairly quick today (I hope) and we can wish everyone happy holidays :)
18:02:42 <dolphm> was not expecting a meeting this week lol
18:02:57 <morganfainberg> #info no keystone meeting after this one until next year
18:04:12 <morganfainberg> #topc assignment split
18:04:21 <morganfainberg> #topic assignment split
18:04:31 <morganfainberg> Hmm Henry isn't here.
18:04:40 <ayoung> he's making commits
18:04:55 <morganfainberg> Yeah I know he's around. Just not in the channel.
18:05:02 <henrynash> hi
18:05:09 <ayoung> See topic henrynash
18:05:14 <henrynash> sorry am late
18:05:32 <henrynash> give me 2 mins (sorry extracting myself out ofother meeting)
18:06:00 <morganfainberg> Ok so Henry has the only topics on the agenda today.
18:06:13 <morganfainberg> Anything else while we wait for him?
18:06:20 <lbragstad> I have some ae token questions if we absolutely *have* to make the meeting go longer ;)
18:06:40 <dolphm> lbragstad: that's definitely not the goal
18:06:44 <lbragstad> lol
18:07:08 <morganfainberg> We can move to that if they should be brought up in the meeting
18:07:22 <morganfainberg> But I don't *want* to force the meeting to be longer
18:07:26 <lbragstad> that's fine with me, I'll iterate in the spec
18:07:32 <morganfainberg> Ok.
18:07:40 <ayoung> I'd like to
18:07:42 <henrynash> ok, reay
18:07:43 <ayoung> AE is important
18:07:46 <lbragstad> if it's still a hangup next week, I'll add to the meeting agenda
18:07:53 <morganfainberg> lbragstad: ok.
18:07:56 <henrynash> so two questions on the assignment split
18:08:10 <dolphm> lbragstad: next meeting is jan 6th
18:08:25 <lbragstad> s/next week/next meeting/
18:09:11 <henrynash> 1) shoudl role management be in their own backend….and not part of the actual assignment engine?
18:09:27 <henrynash> different views on this…from people
18:09:51 <ayoung> and?
18:10:42 <dolphm> henrynash: review the benefits & reasons of each side of the argument?
18:10:50 <dolphm> reasoning*
18:11:08 <morganfainberg> henrynash: ^^ as Dolph said.
18:11:31 <morganfainberg> I was typing something similar and he beat me to it
18:11:39 <stevemar> i was not expecting this meeting
18:11:44 <dolphm> stevemar: ++
18:12:31 <morganfainberg> stevemar: no body expects the Keystone meeting </Monty Python reference>
18:12:44 <ayoung> Start Again
18:13:03 <stevemar> morganfainberg, ++
18:13:08 <ayoung> OK  so roles and assignments ..... different life cycles
18:13:22 <ayoung> I could see Roles being read only, and assignments consuming them
18:13:23 <henrynash> There are various proposals for what component should own role management (e.g. as aprt of service defintion) and maybe not even be first class entities....
18:13:23 <henrynash> ….but that all points for the them to NOT be i the actual assignment engine
18:13:40 <ayoung> I could see roles being read in from a flat file for that matter
18:14:09 <dolphm> ayoung: liiike from policy.json
18:14:16 <henrynash> and I wrote a same alternate assignment engine to test out that view, see: https://review.openstack.org/#/c/143557
18:14:17 <ayoung> dolphm, potentially
18:14:26 <lbragstad> then we don't need a role backend, right?
18:14:51 <ayoung> I could see policy and roles being unified
18:14:57 <amakarov> ayoung, ++
18:15:15 <dolphm> lbragstad: well, the backend could populate itself from a file, or from a db as we do today, or whatever
18:15:20 <henrynash> I think potentially we don’t need a role backend in teh future…but for now having them parked in their own lets us migrate them away when we want in the futre
18:15:35 <dolphm> henrynash: i agree with that
18:15:40 <lbragstad> that makes sense
18:15:54 <lbragstad> so I guess we wouldn't *absolutely* need a role backend for Keystone
18:16:33 <amakarov> lbragstad, we always can add it if needed
18:17:00 <morganfainberg> My opinion hasn't really changed but I do agree splitting it now does let us migrate away as we see fit.
18:17:25 <henrynash> so the patch has roles in their own backend (under the assignments umbrella)…so separatd from teh assignments engine itself
18:17:25 <henrynash> if we are OK with that, then great!
18:17:39 <morganfainberg> But- I am willing to go with the consensus of the rest of the dev team here.
18:18:01 <ayoung> I think it makes sense
18:18:12 <ayoung> I think we can work with it in the future from a policy side of things
18:18:26 <morganfainberg> henrynash: I am going to need to ask you to split that review up though. It is too beastly to review as it sits. Sorry.
18:18:27 <ayoung> roles will feed in to policy, but can be separate backends
18:18:51 <morganfainberg> Regardless of the direction of role backend.
18:20:28 <dolphm> and then, do we want to take a vote on naming the backend for projects and domains to live in?
18:20:28 <morganfainberg> Ok so the two options here are: roles in a separate backend under new assignment. Or as a direct part of the new assignment.
18:20:41 <ayoung> I could see the argument that Roles belong with the domain,
18:21:13 <morganfainberg> dolphm: sure?
18:21:16 <dolphm> ayoung: having them in a separate backend can satisfy that as well
18:21:25 <ayoung> dolphm, agreed
18:21:39 <raildo> dolphm, i agree
18:21:50 <lbragstad> can we call it 'extras'?
18:22:00 <morganfainberg> lbragstad: haha
18:22:08 <ayoung> lbragstad, just remember that we are all meeting face to face shortly
18:22:24 * lbragstad waits for nerf dart impact
18:22:28 <raildo> I think that roles in a separate backend sounds good to connect to domains in the Reseller implementation :)
18:22:53 <morganfainberg> Is anyone opposed to the roles being separate?
18:23:10 <morganfainberg> As Henry described.
18:23:12 <dolphm> #vote no
18:24:16 <lbragstad> nope
18:24:31 <ayoung> Speak up now or forever hold your peace
18:24:50 <raildo> ayoung, haha
18:24:54 <morganfainberg> I don't know the #startvote syntax but few more seconds and we will call the design ok.
18:25:01 <dolphm> #startvote Should roles be in a separate backend? yes, nope
18:25:02 <openstack> Only the meeting chair may start a vote.
18:25:04 <dolphm> like that
18:25:19 <morganfainberg> #startvote Should roles be in a separate backend? yes, nope
18:25:20 <openstack> Begin voting on: Should roles be in a separate backend? Valid vote options are yes, nope.
18:25:21 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
18:25:23 <dolphm> #vote yes
18:25:24 <lbragstad> #vote no
18:25:25 <openstack> lbragstad: no is not a valid option. Valid options are yes, nope.
18:25:34 <lbragstad> oops
18:25:35 <dolphm> lbragstad: you started it
18:25:43 <raildo> #vote yes
18:25:46 <morganfainberg> lbragstad: read the question too :P
18:25:51 <lbragstad> #vote yes
18:25:56 <morganfainberg> Dolph inverted it :P
18:26:05 <dolphm> i did. only your last vote counts, if you'd like to change your answer
18:26:09 <lbragstad> switching formats
18:26:20 <ayoung> #vote yes
18:26:22 * morganfainberg abstains.
18:26:29 <ayoung> morganfainberg, why>
18:26:31 <ayoung> ?
18:26:41 <dolphm> morganfainberg: abstain is not a valid option. Valid options are yes, nope.
18:26:55 <stevemar> abstaining counts
18:26:55 <henrynash> sorry lost connection
18:26:55 <henrynash> what was the vote question?
18:27:05 <ayoung> Begin voting on: Should roles be in a separate backend? Valid vote options are yes, nope.
18:27:08 <stevemar> henrynash, "Should roles be in a separate backend? Valid vote options are yes, nope."
18:27:26 <henrynash> #vote yes
18:27:32 <dolphm> #showvote
18:27:33 <openstack> yes (5): henrynash, lbragstad, dolphm, raildo, ayoung
18:27:41 <dolphm> that's pretty unanimous
18:27:43 <stevemar> #vote yes
18:27:47 <dolphm> morganfainberg: #endvote when you're ready
18:27:54 <morganfainberg> ayoung: I've abstained from a negative score (or positive) in this process because I am willing to go with the consensus.
18:27:57 <morganfainberg> #endvote
18:27:58 <openstack> Voted on "Should roles be in a separate backend?" Results are
18:27:59 <openstack> yes (6): lbragstad, ayoung, dolphm, henrynash, raildo, stevemar
18:28:10 <morganfainberg> henrynash: your design wins :)
18:28:24 <henrynash> :-)
18:28:26 <morganfainberg> henrynash: now split the review up so its reviewable :P
18:28:36 <henrynash> ok, eill try!!! :-)
18:28:47 <ayoung> thanks henry
18:28:48 <morganfainberg> As it stands I can only negative score it because it's too much at once.
18:29:01 * lbragstad thinks unanimous votes should result in openstack saying 'fatality!'
18:29:05 <morganfainberg> henrynash: but thanks for working through this -
18:29:10 <henrynash> on tehe subject of what we call the place where projects/domains are
18:29:23 <henrynash> did we vote on that while I lost connection?
18:29:33 <dolphm> henrynash: no
18:29:33 <henrynash> morganfainberg: np
18:29:34 <morganfainberg> No.
18:30:19 <dolphm> the two suggestions are resources and projects right now - does anyone else have another proposal?
18:30:34 <dolphm> so the vote would be like:
18:30:34 <dolphm> What should the backend for projects and domains be called? resources, projects
18:30:35 <morganfainberg> So who has an issue with the current name? And also "hardest two thing in CS".
18:30:55 <morganfainberg> Any other suggestions before we start the vote?
18:31:06 <ayoung> projects
18:31:23 <raildo> tenants?
18:31:28 <ayoung> ++
18:31:29 <morganfainberg> #startvote What should the backend for projects and domains be called? Resources, Projects
18:31:30 <openstack> Begin voting on: What should the backend for projects and domains be called? Valid vote options are Resources, Projects.
18:31:31 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
18:31:37 <ayoung> #vote tenants
18:31:38 <openstack> ayoung: tenants is not a valid option. Valid options are Resources, Projects.
18:31:40 <dolphm> #startvote Projects
18:31:41 <openstack> Only the meeting chair may start a vote.
18:31:41 <morganfainberg> raildo: veto.
18:31:49 <raildo> morganfainberg, :(
18:31:59 <morganfainberg> #vote resources
18:32:01 <ayoung> #vote projects
18:32:03 <amakarov> #vote Projects
18:32:15 <henrynash> #vote resources
18:32:18 <dstanek> #vote resources
18:32:19 <raildo> #vote resources
18:32:21 <ayoung> #vote projects
18:32:22 <ayoung> #vote projects
18:32:22 <ayoung> #vote projects
18:32:23 <ayoung> #vote projects
18:32:29 <dolphm> #showvote
18:32:30 <openstack> Projects (2): amakarov, ayoung
18:32:32 <morganfainberg> ayoung: ballot stuffing doesn't work
18:32:32 <openstack> Resources (4): henrynash, dstanek, raildo, morganfainberg
18:32:43 <morganfainberg> stevemar: ?
18:32:49 <dolphm> #vote projects
18:33:11 * morganfainberg prods stevemar
18:33:12 <ayoung> Anything I can do to convince you guys to switch your vote?
18:33:17 <dolphm> dstanek: ^
18:33:21 <ayoung> we are talking about getting rid of the domain table
18:33:24 <dolphm> dstanek: oh you voted, i'm blind
18:33:34 <dstanek> dolphm: :-)
18:33:38 <ayoung> if we do that...projects makes much more sense
18:33:38 <stevemar> #vote resources
18:33:43 <dolphm> bknudson: ^
18:33:43 <morganfainberg> ayoung: I vote resources because it is likely to expand beyond projects in the future.
18:33:43 <ayoung> GAH!
18:33:48 <stevemar> but bknudson had comments about it
18:33:59 <amakarov> almost anything may be called resource
18:34:02 <morganfainberg> And another rename is bad if we can avoid it.
18:34:05 <dolphm> stevemar: know which he preferred? i assume he's afk
18:34:10 <ayoung> morganfainberg, the palantir you are looking in has been corrupted
18:34:17 <stevemar> dolphm, he hated them all
18:34:21 <dolphm> stevemar: ++
18:34:28 <morganfainberg> ayoung: you must construct additional pylons.
18:34:50 <ayoung> morganfainberg, that is what Sauron said to Saruman
18:34:54 <morganfainberg> I'd be open to something else. (I actually like tenant, but the community would lynch us)
18:34:59 <ayoung> watch out for Ents
18:35:03 <dolphm> the backend won't house all the resources in openstack, it houses the containers that define tenancy for openstack: projects.
18:35:11 <stevemar> morganfainberg, ++ i'm against getting lynched
18:35:34 <morganfainberg> Seriously if I thought we could get away with it I'd go back to tenant. I **hate** project.
18:35:52 <stevemar> it's not going to be a user facing concept, it's what we call our backend, that backend can house projects/domain/blah
18:36:28 <raildo> stevemar, so this  a container of resources, not just projects :P
18:36:43 <ayoung> no,  projects are containers for resources
18:36:45 <amakarov> what does the project/tenant do exactly? We can find a correct name this way
18:36:49 <dolphm> stevemar: yeah, but many of our users are deployers
18:36:51 <ayoung> projects and domains are namespaces
18:36:56 <dolphm> stevemar: so, consider the UX impact on them
18:37:03 <morganfainberg> So, in this case I am inclined to follow henrynash's lead on naming. I do agree with bknudson that all suck
18:37:13 <raildo> ayoung, right
18:37:15 <ayoung> projects sucks less
18:37:22 <amakarov> ayoung, why not name it namespaces?
18:37:28 <morganfainberg> And tenant sucks even less :P
18:37:36 <morganfainberg> amakarov: another overloaded term.
18:37:36 <ayoung> and I could totally see splitting projects and domains into two backends
18:37:41 <morganfainberg> Massively overloaded.
18:37:55 <ayoung> in which case we'd put domains into their own backend, and leave projects here
18:38:10 <breton> #vote resources
18:38:11 <dolphm> (i don't know that all services use tenancy to define namespacing?)
18:38:20 <breton> # not sure I'm not late
18:38:26 <dolphm> #showvote
18:38:27 <openstack> Projects (3): amakarov, dolphm, ayoung
18:38:28 <openstack> Resources (6): dstanek, morganfainberg, henrynash, raildo, breton, stevemar
18:38:31 <morganfainberg> dolphm: they don't. But they could.
18:38:38 <amakarov> morganfainberg, ++ but more detailed understanding of what it does can lead us to more informative name
18:38:45 <henrynash> (sorry my connectivety is on teh blink..back)
18:38:54 <morganfainberg> dolphm: swift doesn't, but anyone else either uses projects or not at all afaik
18:39:19 <stevemar> ugh bknudson is gonna hunt me down for proposing that name
18:39:25 <dolphm> /v4/namespaces
18:39:33 <henrynash> sorry, what was the result
18:39:37 <ayoung> /v6/termie
18:39:40 <dolphm> #showvote
18:39:41 <openstack> Projects (3): amakarov, dolphm, ayoung
18:39:42 <openstack> Resources (6): dstanek, morganfainberg, henrynash, raildo, breton, stevemar
18:39:45 <dolphm> henrynash: vote has not ended yet ^
18:39:52 <morganfainberg> dolphm: *sigh* nooooooooooooooooo /darthvader
18:40:07 <stevemar> henrynash, we should all chip in and get you a better connection
18:40:18 <morganfainberg> #endvote
18:40:19 <openstack> Voted on "What should the backend for projects and domains be called?" Results are
18:40:20 <openstack> Projects (3): amakarov, dolphm, ayoung
18:40:21 <openstack> Resources (6): dstanek, morganfainberg, henrynash, raildo, breton, stevemar
18:40:26 <henrynash> (have to pay Mr Marriott)
18:40:40 <dolphm> so keystone will now have a resource backend
18:40:42 <morganfainberg> #info name is still in question. No options are good but resources tends to lead of the two proposed.
18:41:15 <stevemar> it makes sense to me, that an identity has a role assignment on a resource
18:41:17 <morganfainberg> henrynash: needs to split up the review. Please consider other names for the backend.
18:41:19 <lbragstad> I feel like we use the term resource to define anything owned by keystone
18:41:19 <dstanek> how many different backend impls will we have to start?
18:41:21 <amakarov> we can try an allegory :)
18:41:27 <lbragstad> which could be confusing down the road
18:41:47 <morganfainberg> amakarov: let's go with analogy. And make it about cars.
18:41:50 <dstanek> if we only have one then no need to expose the name and we can delay the decision on the name
18:41:55 <amakarov> smth like hub or hive or unit
18:42:01 <morganfainberg> dstanek: ++
18:42:31 <amakarov> morganfainberg, is unit about cars? )
18:42:35 <morganfainberg> Ok let's move on. The name is still open for discussion.
18:42:43 <ayoung> heh
18:43:03 <morganfainberg> Please discuss wth henrynash for better names. If no others come up resources it will be b
18:43:05 <morganfainberg> E
18:43:07 <ayoung> on a slightly related note...I'm working on making every project be a domain
18:43:22 <morganfainberg> Next topic.
18:43:23 <ayoung> I'll just assume this needs to be rebased on top of henrynash 's redone patch
18:43:38 <morganfainberg> #topic domain roles
18:43:46 <morganfainberg> henrynash: o/ (again) :)
18:44:12 <ayoung> OK...so  I think roles  here mean something different than we've been using them to mean
18:44:14 <henrynash> ok, so the question here is whether we trat domain-roles as a different sort of entity than a role, in terms of API
18:44:31 <morganfainberg> Good question.
18:44:42 <henrynash> there is a proposed API spec (thanks to samuel)
18:44:43 <ayoung> lets say that our existing term "role"  is really "collection of capabilties"
18:44:46 <morganfainberg> I see this as more of the VO concept.
18:45:00 <ayoung> and role really should be a role in an organization
18:45:01 <morganfainberg> Not the current capabilities of OpenStack.
18:45:23 <morganfainberg> But that is my understanding here.
18:45:25 <ayoung> does "capabilities" have an official meaning in OpenStack?
18:45:41 <ayoung> I can be more specific
18:45:42 <morganfainberg> Well, as we defined it talking about policy it does ;)
18:45:55 <henrynash> so my view is they are different entities…..our curent “role” is tied to teh service capabiities, while teh “domain-role” is something meaningful to the domain/enterprise,
18:45:57 <morganfainberg> I think we (keystone) are driving that definition.
18:46:04 <ayoung> agreed
18:46:20 <morganfainberg> And I like that definition.
18:46:26 <ayoung> the one issue is that we are enforcing role<->capaility inside policy
18:46:29 <dstanek> morganfainberg has there been any input from other interested parties?
18:46:34 <ayoung> domain scoped roles are supposed to be private
18:46:50 <morganfainberg> dstanek: no dissent, most people are going with it.
18:47:05 <morganfainberg> dstanek: but I also didn't ask, we just asserted the definition.
18:47:15 <ayoung> as such,  a Domain Scoped Role (DSR) is an alias to the current Keystone role, or, potentially, set of roles
18:47:18 <henrynash> …and I think overloading the current role & grant APIs might make things more complicated as we poentially chaneg teh defintion of what teh udnerlying roles aer
18:47:24 <morganfainberg> Figured I could ask forgiveness later if needed
18:48:14 <ayoung> Is there a better term for what we currently call roles?
18:48:52 <henrynash> ayoung: they probably ARE capabilities….and we are jsut allowing service owners to define some meta-capabilties (like admin)
18:49:25 <amakarov> henrynash, or permissions
18:49:50 <ayoung> amakarov, I'd say those are even more fine grained
18:50:00 <ayoung> like "read, write, execute" on an object are permissions
18:50:04 <morganfainberg> ayoung: bags of mostly capabilities (/Star Trek reference)
18:50:08 <henrynash> ayoung: but I see us gradually migrating teh existing roles to be more like that over time…and maybe we do chaneg their name at some point (I’d say the time they stop bring first class entites)
18:50:33 <dolphm> morganfainberg: ++
18:50:38 <lbragstad> I would say "read, write, and execute" are more operations
18:50:46 <ayoung> henrynash, DSR assignments are still going to be scoped to a project, correct?
18:50:53 <henrynash> ayoung: yes
18:50:58 <dolphm> henrynash: i don't think "roles are capabilities", if that's what you were referring to above
18:51:10 <morganfainberg> lbragstad: sure. But the api is more complex than r/w/e. Unlike posix.
18:51:16 <ayoung> henrynash, could we call them aliases, then?
18:51:24 <morganfainberg> lbragstad: so, I think capability is better.
18:51:31 <henrynash> dolphm: they’re not today…but I think that’s what they become
18:51:41 <ayoung> Domains allow aliases to Keystone roles?
18:51:42 <morganfainberg> ayoung: someone vetoed alias at the summit with an "oh god please no"
18:51:51 <dolphm> although you could probably breakdown all of openstack policy into r/w permissions on <thing>
18:51:53 <ayoung> morganfainberg, RoleAliases
18:51:54 <lbragstad> capability vs. permission
18:52:02 <morganfainberg> ayoung: better.
18:52:09 <morganfainberg> But still confusing.
18:52:16 <henrynash> ayoung: well it’s more than aliases…since the domain-roles can be a colleciton of roles (or other domain-roles)
18:52:25 <ayoung> henrynash, so, lets not do that
18:52:32 <henrynash> ayoung: do what?
18:52:37 <ayoung> lets push for hierarchical roles, and then domains get aliases
18:52:47 <morganfainberg> lbragstad: you know...
18:53:06 <ayoung> I think we really need the hierarchical roles to organizat this stuff
18:53:35 <henrynash> ayoung: ok, so that’s not what we agreed at tehe summit…domain-roles can be collectins of roles and we expand them out at token creation time (for example)
18:53:45 <morganfainberg> henrynash: correct.
18:53:55 <ayoung> henrynash, I know, but at the summit the Hierarchical idea was just getting formed, too
18:54:15 <henrynash> ayoung: and that’s what the spec says: https://review.openstack.org/#/c/133855/9
18:54:20 <ayoung> So what.
18:54:23 <amakarov> if we have hierarchical roles on hierarchical projects, do we need separate DSR and domains at all?
18:54:25 <ayoung> This is design work
18:54:29 <ayoung> its supposed to be iterative
18:54:40 <ayoung> amakarov, yes, we do
18:54:45 <morganfainberg> amakarov: there are two concepts so we need two differing things.
18:55:02 <dolphm> 5 minutes
18:55:03 <ayoung> henrynash, OK, take a step back
18:55:18 <henrynash> ayoung: if we don’t let domain_roles be a collection, then we restrict how the domain admin can “create domain-roles that are meangingfiul to them”…and that’s teh point of them
18:55:21 <raildo> morganfainberg, ++
18:55:24 <morganfainberg> henrynash: ayoung : so we have the VO concept Henry was just describing (org wise role) and the openstack role cascade/hierarchy
18:55:28 <raildo> amakarov,  hierarchical projects will use domain roles/hierarchical roles
18:55:38 <ayoung> lets assume for a moment that we had hierarchical roles today.  Would you still push for one DSR apping to multiple hierarchical?
18:55:45 <henrynash> ayoung: yes
18:56:16 <ayoung> OK...so..what if we merge those two things, then
18:56:23 <ayoung> we create a new thing...a role collection
18:56:25 <morganfainberg> dolphm: thx
18:56:33 <henrynash> ayoung: because why would teh hierachy created by teh service owner match what I want in my domain?
18:56:33 <ayoung> and DSRs use them, and Roles use them
18:56:44 <morganfainberg> ayoung: (this sounds like what we described at the summit btw)
18:56:58 <henrynash> ayoung: (which is why I called them role-groups to start!)
18:56:58 <ayoung> anyone can create a role collection, or reuse one
18:57:01 <morganfainberg> Almost to the letter.
18:57:06 <ayoung> a role collection is unnamed
18:57:09 <ayoung> and immutable
18:57:27 <ayoung> hierarchical roles will use them, too
18:57:37 <amakarov> morganfainberg, ++ since we have user groups, why not having role groups?
18:57:42 <morganfainberg> Minor differences but t really is almost to the letter what we decided.
18:58:00 <ayoung> except that role-groups and domain scoped roles are two separate things
18:58:15 <ayoung> I think we had them munged into one before
18:58:20 <morganfainberg> ayoung: this is a logical merging of the constructs.
18:58:36 <morganfainberg> ayoung: not really we just didn't have the intermediate step defined
18:58:47 <morganfainberg> It wasn't hard set as needing to be one concept.
18:58:54 <ayoung> domain scoped roles are the private name for a role-group
18:59:08 <morganfainberg> Ok we need to take this to -keystone
18:59:23 <morganfainberg> But this sounds like we're headed the rift way.
18:59:29 <morganfainberg> #endmeeting