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