18:01:35 #startmeeting Keystone 18:01:36 Meeting started Tue Jul 21 18:01:35 2015 UTC and is due to finish in 60 minutes. The chair is morganfainberg. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:01:37 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:01:38 #link https://wiki.openstack.org/wiki/Meetings/KeystoneMeeting 18:01:39 The meeting name has been set to 'keystone' 18:01:45 * ayoung needs to leave at the 1/2 hour mark 18:01:47 Hi everyone! 18:01:49 o/ 18:01:51 o/ 18:02:03 so... lets jump right in 18:02:03 Hi :) 18:02:08 Welcome back from midcycle 18:02:15 time to do non-midcycle things now 18:02:19 #topic Dynamic Policies 18:02:24 ayoung, samueldmq: o/ 18:02:28 W00t 18:02:33 hello guys o/ 18:02:33 ok, gave a presentation last week 18:02:36 link in am oment 18:02:39 moment 18:02:47 still digesting them lobstars 18:03:03 (lobsters, plural ????) 18:03:13 #LINK to git repo https://github.com/admiyo/keystone-rbac-presentation 18:03:27 henrynash, +2! 18:03:43 #LINK https://github.com/admiyo/keystone-rbac-presentation/raw/master/risk-assessment.pdf 18:04:00 +1 (a +2 would just go to his head) 18:04:22 I think we are making progress, but still concerned that most people don't get what we are trying to do here...please ask away if you have any questions 18:04:35 ayoung: yes, and I'd like to ask for an offical decision on the SFE 18:04:40 the goal is to minimize the amount we depend on the remote services to change 18:05:02 morganfainberg, that is for you to decide, or the TC? 18:05:04 ayoung, we have some Horizon folks here interested to try to make an editor for policies 18:05:06 ayoung: see what cores (who didn't responded to the email) think and see what morganfainberg thinks (since it's a ptl decision, as ttx said :)) 18:05:21 ayoung: hmm? 18:05:25 ayoung: the SPFE? 18:05:25 put it to a vote? 18:05:27 I think we need to develop a crisp strategy that we can share x-project (multi-cycle, inevitably) 18:05:28 yep 18:05:31 it's a core decision 18:05:39 i'll support the general view of the keystone-core team 18:05:45 morganfainberg: ++ 18:05:50 ayoung: so my view is that IF we limit our selves to making it easier for projects to source their polciy files form keystone (without any fundamental change to policy format, definitions etc.) then I support 18:05:53 it's my call,but i'll leave it to the team to decide 18:06:02 geoffarnold, that is the goal; need to make it understandable cross project 18:06:20 i would rather not step on the toes of those who need to review/maintain/support/look at bugs in it [if that makes sense] 18:06:22 henrynash: I think that's pretty the scope to L, at least as I see it 18:06:30 henrynash, that is exactly the intention of the SFPE 18:06:52 ayoung, I am lost, you saying changing the policy format is a precursor to dynamic policy? 18:07:01 gyee, no 18:07:10 no change to the policy format is proposed 18:07:11 they are two different deal 18:07:17 I'll take the strategy + motivating user stories to the ProductWG when we're ready 18:07:34 samueldmq, can you find the link to the SFPE email? 18:07:47 geoffarnold, those are all in the presentation 18:08:05 ayoung: henrynash the bp https://blueprints.launchpad.net/keystone/+spec/dynamic-policies-delivery 18:08:20 ayoung: if you want a vote, happy to start one 18:08:22 yeah those changes are fairly contained 18:08:22 and the email ... 18:08:24 #link https://www.mail-archive.com/openstack-dev@lists.openstack.org/msg57416.html 18:08:28 otherwise general consensus here works too 18:08:28 I know. Waiting on final consensus 18:08:47 no objection here 18:08:50 as far as delivery, what we are propsing can be summarized like this 18:09:10 we make use of the endpoint policy extension we have now to associate a policy with an endpoint 18:09:15 endpoints will fetch by endpoint id. 18:09:32 The most explicit will be to set the id in the authtoken secition of the config file 18:09:32 samueldmq: well, at lesat one of this listed is abandoned! 18:09:42 later, we will implement aless invasive approch; 18:09:52 calculate the endpoint_id from the URL 18:09:54 "endpoints will fetch by endpoint id." -- this has to be implemented in all the other projects? 18:10:05 henrynash: yes, as a consequence of what was decided on the midcycle.. we'll be fetching by endpoint_id, not by policy id 18:10:22 ayoung, samueldmq: before a vote, we need a definitive list of what BPs are included 18:10:26 do you feel like you've incorporated sdague's concerns? 18:10:46 bknudson, "has to" no. "may be" yes 18:10:46 ayoung, samueldmq: please excluded those you have abandoned 18:10:49 henrynash: just this one for the dynamic delivery: https://blueprints.launchpad.net/keystone/+spec/dynamic-policies-delivery 18:10:51 #link https://blueprints.launchpad.net/keystone/+spec/dynamic-policies-delivery 18:10:55 that's all for L 18:11:08 henrynash: how do I exclude that ? 18:11:20 samueldmq, edit the white board and remove the abandonded specs, please 18:11:33 or say "(abandoned)" next to them 18:11:35 same net effect 18:12:41 ayoung: henrynash done! 18:13:18 morganfainberg: sorry was removing :) it can be viewed as abandoned when filtering by gerrit topic 18:13:26 its' fine either way 18:13:39 both work, it indicates what is active 18:14:08 ayoung: bknudson has a question about sdague's concerns above .. ^ 18:14:22 any other core has any concern/question on this subject? 18:14:24 i'm still super weary about this 18:14:31 so we can clarify before a vote 18:14:34 no clue on whether sdague would approve or reject at this point... 18:14:46 stevemar weary or wary? 18:14:58 wary :P 18:15:01 geoffarnold, he's wary, I'mweary 18:15:15 stevemar: hehe I need to translate that one :p 18:15:24 ayoung, srevemar I knew that ;-) 18:15:48 stevemar, please state your concerns 18:15:56 stevemar, do let us know your feelings, this is also a dynamic policy therapy session 18:15:56 I think we need more love on this subject, what is target to L is very small, the delivery 18:16:08 let's clear the points that need to, get reviews, and get it done :) 18:16:13 gyee: lets save therapy for another time 18:16:28 I know I've had lots of time to look at the spec but I haven't yet... I wouldn't mind taking a look at it this week and then I'll vote on the spec. 18:16:29 a whole system for storage/retrieval of policies to solve the issue of inconsistent 'is_admin' roles seems like overkill 18:16:43 I think people are wary because we implement lots of things that other projects wind up not using 18:16:51 so are other projects actually going to use this? 18:16:59 stevemar overkill for this, or overkill as an eventual goal? 18:17:17 bknudson: other projects don't even need to know about it, they get the policy file 18:17:27 bknudson: that can be modified before with the dynamic one 18:17:33 geoffarnold: i'd prefer to just better define what is_admin is, and make sure projects adhere to that 18:17:39 * marekd sneaks in late 18:17:41 bknudson: so no change on other projects for the delivery, if that's what you want to know 18:17:42 policy had a store and fetch mechanism for al ong time, it just was useless 18:17:43 everyone's using oslo.policy and they use that? 18:17:50 bknudson: yes 18:17:56 * morganfainberg directs marekd to the open seat in the front of the room - no sneaky 18:18:01 bknudson, not all projects have migrated from the incubated yet 18:18:11 bknudson: that will be optional I guess.. not a must use that 18:18:15 just nova and a few of the new projects 18:18:16 this is not really about admin 18:18:23 admin is deployment-specific 18:18:30 stevemar that's a good short term goal. as we discussed last week, is_admin needs to disappear long term, except for break-glass 18:18:32 it just some role with some capabilities 18:18:32 bknudson: so that goes in the middleware/oslo config sections 18:18:34 stoarge is just the first step. The goal is to be able to link the polices and the role assignments into a coherent mechanism 18:18:50 so...yeah, each step is going to seem small, cuz, you know, baby steps 18:18:56 this is really about flexibility in authorization management 18:18:58 and things that are understandable, and valuable in and of themselves 18:18:59 are you planning to put together a gate job that uses it? 18:19:03 here’s the fundamental question (imho): are the eventual solutions to policy one that require us to recommend that cloud providers top using the tradiational methods of policy distribution (e.g. chef etc.) and instead use keystone as a central repository of policy 18:19:12 changing devstack to use it? 18:19:22 functional tests? 18:19:23 henrynash: good question 18:19:24 documentation? 18:19:26 (provuders stop…) 18:19:28 bknudson: yeah I can do it 18:19:33 bknudson, yes, yes, and yes. 18:20:15 henrynash, this is same mechanism as domain backend in sql 18:20:20 could it live as it's own project until all the baby steps are done? or as a feature branch? 18:20:34 ayoung: see henrynash's question .. if we do that, we are advising them to do so, i.e use keystone for the distribution instead of CMS 18:20:40 stevemar, I'd probably just give up in frustration if we tried 18:20:53 if we think yes to my question, then what is being roposed seems a godo second step (we already mad teh first by having the APIs to allow such a centralized repository) 18:21:12 ok 4 more mins on this topic 18:21:28 then we either vote or use the spec as the vote 18:21:38 stevemar, its like; something major is broken here. Keystone itslef is a security nightmare, and we are afraid of fixing it. I'm fine with someone suggesting an alternative approach tio fixing it, but not with postponing the fixes 18:21:53 +1 18:22:00 things take for-ever in Keystone, and if we say "we are afraid of this" we will never fix it 18:22:11 so...speak up. how do we fix keystone? 18:22:34 ayoung: this, however, is *not* a keystone is a security nightmare. this is a policy is a security nightmare 18:22:43 I like the idea of a separate branch/repo for this to prove it out 18:22:45 we can fix keystone policy - that really is a lot less difficult 18:22:45 a quick hack would be to patchup the individual policy.json file :) 18:22:47 just saying 18:22:54 if we only care about the admin problem 18:22:57 fixing policy everywhere is hard 18:23:02 morganfainberg, can we? PLease explain how. 18:23:40 gyee, if I thought we could address this by fixing the individual policy files, I'd go for it 18:23:41 ayoung: simple - we change the loading params, make a new default, change devstack, and tell people the old single admin/member policy is dead with a simple migration to a "real" policy. that isn't hard to sell 18:23:48 ayoung: fixing is_admin *everywhere* is hard 18:23:55 ayoung: if it were a nightmare we'd have operators desperately asking us for it. i'm hearing a "yeah, it's cool" 18:24:04 fixing policy everywhere is hard, but it's less hard if we provide an easy-to-adopt framework which addresses the issues 18:24:11 ayoung, like defining a nova_admin role? 18:24:39 just trying to avoid the "keystone is broken" statements, keystone is mildly broken - but it's hard to fix everything everywhere - we know this. 18:24:42 gyee, namespaced roles have been suggested before...are you saying we should prioritize that? 18:25:18 ayoung, we could 18:25:22 but that's not "dynamic" 18:25:31 but would get us pass the global admin problem 18:25:39 ayoung: gyee is suggesting somthig simpler I think, jsut work with the prpjects so the don’t call their “own” admin role “admin” 18:25:51 henrynash: ++ 18:25:53 henrynash, who gets to assigne that role? 18:25:57 what scope is it enforced on? 18:26:11 and how is that enforcement done? 18:26:14 enforcement is still the same 18:26:37 gyee, and that is policy, right? 18:26:39 ok since ayoung needs to go in 4... 18:26:44 ayoung: and second, we change oslo.policy so we can put comments in policy.json, create some kick-ass samples (e.g. give one to Nova and Glance to show them how) 18:26:44 also, oslo.policy is already dynamic, edit a file and the next request will use it 18:26:48 is_admin: role:admin or role:nova_admin 18:26:59 gyee, it needs to be scoped 18:27:04 are we voting on the spfe? or are we aiming for a different tack (get namespaced roles?)? 18:27:12 oor using the spec as a vote? 18:27:16 just assign the nova_admin role to user for a given project 18:27:45 or something totally different? 18:28:05 We can distribute the mechanism by some other form. The problem is then it becomes "config" 18:28:08 and not "data" 18:28:09 the state of this discussion (and last week) suggests that whatever we're talking about it isn't ready for a vote yet 18:28:11 morganfainberg: I think we should vote.. if we don't get enough yeses, that may mean we should reprioritize, or try anythingelse ? 18:28:13 and the rules change for the operators. 18:28:13 so just spfe 18:28:17 to maintain backward compatibility, we roll a small middleware to translate nova_admin to admin at nova api pipeline 18:28:37 gyee, gah! 18:28:38 no 18:28:51 ayoung: your call since it's your initiative - vote, defer, something else? 18:28:55 gyee: no (even from me!) 18:28:56 vote 18:29:00 ok 18:29:03 like I said, that's a simple hack to solve the global adminness issue 18:29:04 just on the distro mechanism 18:29:07 but not for dynamic policy 18:29:13 it is opt in...won;'t be enabled until the user wants it 18:29:27 specifically 18:29:29 https://review.openstack.org/#/c/134655/ 18:29:30 and 18:29:36 ayoung: is this classed as experimental? 18:29:36 https://review.openstack.org/#/c/197980/ 18:29:38 #startvote Dynamic Policy SPFE Acceptance? accept, deny, defer 18:29:39 Begin voting on: Dynamic Policy SPFE Acceptance? Valid vote options are accept, deny, defer. 18:29:40 Vote using '#vote OPTION'. Only your last vote counts. 18:29:50 #vote defer 18:30:08 #vote accept 18:30:08 defer would be either next meeting or use spec scoring as the vote 18:30:10 henrynash, so one is cahce headers...I see no need to defer or make experimental 18:30:19 the other is for middleware 18:30:22 #vote defer 18:30:27 #vote accept 18:30:43 #vote defer 18:30:47 #vote accept 18:30:57 https://review.openstack.org/#/c/134655/ is the thing we are really voting on....the other is just better HTTP coding 18:31:05 * morganfainberg pokes stevemar 18:31:06 #vote accept 18:31:08 morganfainberg: if we defer, people should put more love on that, we'll be defering because they don't know enough about it 18:31:15 (this is just cores, right?) 18:31:20 morganfainberg: i'm thinking 18:31:21 geoffarnold: feel free to vote 18:31:29 #vote defer 18:31:30 geoffarnold, this is democracy 18:31:32 geoffarnold: i'll weight to cores if it's a tie 18:31:37 #vote accept 18:31:39 #vote accept 18:31:53 #vote defer 18:31:58 so, before we close the vote, let's be clear on what we are voting on 18:32:20 a defer vote means we will make no progress on dynamic policy this release 18:32:38 #vote for progress 18:32:38 gyee: for progress is not a valid option. Valid options are accept, deny, defer. 18:32:43 > defer would be either next meeting or use spec scoring as the vote 18:32:46 #vote defer 18:32:49 this was the absolute smallest piece of it we could make happen. 18:33:13 #votes 18:33:23 #votestatus 18:33:28 * morganfainberg cant remember 18:33:30 #showvote 18:33:31 defer (6): lbragstad, bknudson, dstanek, amakarov, breton, stevemar 18:33:32 accept (6): gyee, ayoung, marekd, geoffarnold, samueldmq, henrynash 18:33:33 endvote first 18:33:54 morganfainberg: ^ showvote ;) 18:34:06 crap... 18:34:12 really i'm going to have to be the tie breaker? 18:34:14 it's up to morganfainberg 18:34:16 *really*?! 18:34:17 hah 18:34:22 ok, love me now 18:34:27 #vote accept 18:34:29 nobody voted no, so I'm fine with it either way 18:34:43 breton, heh 18:34:49 where is lbragstad, dolphm, and jamielennox? 18:34:49 the only way it could go is towards accept at this point 18:34:56 I already voted 18:34:59 morganfainberg: lbragstad voted 18:35:06 \o/ 18:35:07 oh 18:35:08 haha 18:35:12 jamielennox is probably asleep. He's been battling SSL issues until the wee hours of the morning 18:35:16 lbragstad, hi 18:35:23 I need to go 18:35:24 and even split of cores also 18:35:25 ugh 18:35:27 morganfainberg: o/ 18:35:27 switch to TLS 18:35:32 #showvote 18:35:32 defer (5): lbragstad, bknudson, dstanek, amakarov, stevemar 18:35:33 accept (7): gyee, ayoung, marekd, geoffarnold, samueldmq, henrynash, breton 18:35:38 dolphm: ^^ vote - and views? 18:35:45 oh crap meeting lol 18:35:47 * morganfainberg is trying to *not* be the tie breakers here 18:36:10 #vote defer 18:36:15 I'll check the results later 18:36:22 ahha 18:36:42 #vote defer 18:36:53 #endvote 18:36:53 Voted on "Dynamic Policy SPFE Acceptance?" Results are 18:36:54 defer (7): lbragstad, morganfainberg, bknudson, dstanek, dolphm, amakarov, stevemar 18:36:55 accept (7): gyee, ayoung, marekd, geoffarnold, samueldmq, henrynash, breton 18:37:07 this is impossible 18:37:13 even split - but more cores on defer 18:37:19 so we will go with defer. 18:37:21 morganfainberg: next meeting ? so we can vote again even if people don't look at the specs 18:37:27 please vote on the spec - score it 18:37:45 #action Keystone Cores - review the SPFE and Dynamic policy spec(s) specifically for liberty 18:37:58 i expect to have scores on the specs by next meeting 18:38:21 if you don't... we'll approve it and you're stuck with it 18:38:32 since defer is closer to accept than deny 18:39:00 ok moving on 18:39:04 #topic Moving role assignment inheritance (OS-INHERIT) to core 18:39:08 henrynash: o/ 18:39:17 ok, so a spec for this is here: https://review.openstack.org/#/c/200434/ 18:39:22 #link https://review.openstack.org/#/c/200434/ 18:40:33 fwiw - I'm for this. 18:40:40 I think we agreed we're moving things from extensions already 18:40:41 Liek to get people’s views on pushing this in….as I say, the only wrinke is using the change of API (i.e. extension -> core) to provide new inheritance rules (that we think are mosre suitable to generalized project hierachies) 18:40:58 bknudson: this is the API change to change how inheritence works we're considering when moving 18:41:05 bknudson: since it wont be OS-INHERIT anymore 18:41:24 has to be deprecated 18:41:28 then we can remove it in v4 18:41:30 OS-INHERIT will maintain the old and be deprecated 18:41:32 yes 18:41:39 bknudson: the old OS-INHERIT will depreacted, but support for 4 cycles in case anyone wants the old sematics 18:41:44 but the non-deprecated/new way will be the new inheritence model 18:41:59 henrynash: at least 4.. we may not remove before v4 18:42:09 * morganfainberg kicks that can waaaaay down the line 18:42:12 morganfainberg: agreed 18:42:28 if there are concerns about this change - please say so now. 18:42:44 I haven't looked at all the changes but can't think of a reason to not do it. 18:42:54 same here 18:42:58 defer to next week :) 18:43:06 no concerns 18:43:06 gyee: no defer 18:43:08 sorry 18:43:11 I only browsed the change, but it looked OK 18:43:12 this one is a yes or no 18:43:56 #startvote Accept SPFE for os-inherit behavior change when moved to core (old API/behavior deprecated)? yes, no 18:43:56 henrynash: just a question 18:43:57 Begin voting on: Accept SPFE for os-inherit behavior change when moved to core (old API/behavior deprecated)? Valid vote options are yes, no. 18:43:59 Vote using '#vote OPTION'. Only your last vote counts. 18:44:04 #vote yes 18:44:11 henrynash: so we'll be proposing a new inheritance api ? 18:44:17 only think I don't like is "GET /projects/{project_id)/groups/{group_id}/roles/inherited" 18:44:22 henrynash: or just moving the old one ? 18:44:22 #vote yes 18:44:22 samueldmq: it'll be rolled into assignment directly 18:44:27 #vote yes 18:44:29 #vote yes 18:44:31 #vote yes 18:44:39 #vote yes 18:44:41 #vote yes 18:44:43 samueldmq: OS-INHERIT will be deprecated, but continue on 18:44:44 #vote yes 18:44:47 same behavior 18:44:58 #showvote 18:44:58 yes (8): lbragstad, morganfainberg, bknudson, marekd, geoffarnold, dstanek, htruta, raildo 18:44:59 I was just thinking about fixing the beharvior of inherited in the new api 18:45:01 #vote yes 18:45:02 like 18:45:06 applying to the node itself 18:45:07 samueldmq: can't change behavior 18:45:12 samueldmq: that’s what we are doing! 18:45:13 in the old api 18:45:21 morganfainberg: k but we can in the new 18:45:23 henrynash: ^ 18:45:26 ? 18:45:30 samueldmq: yes and that is the plan :) 18:45:35 #vote YES 18:45:40 3 18:45:42 ... 18:45:43 2 18:45:45 ... 18:45:47 1 18:45:48 ... 18:45:52 #endvote 18:45:53 Voted on "Accept SPFE for os-inherit behavior change when moved to core (old API/behavior deprecated)?" Results are 18:45:54 yes (10): lbragstad, morganfainberg, lhcheng, bknudson, marekd, geoffarnold, dstanek, htruta, samueldmq, raildo 18:46:00 henrynash: have at. 18:46:04 ok! 18:46:12 please reference this meeting irc-log in the bp 18:46:24 will do 18:46:26 next topic 18:46:29 #topic Clarifying how domain_id, parent_id and is_domain are used in project hierarchies 18:46:32 henrynash: you again 18:46:49 this should also be quick 18:46:52 ok, so this is mainly clarifying in teh API spec how we use these three things 18:46:54 https://review.openstack.org/#/c/200624/ 18:47:03 teh wrinle in this one... 18:47:27 * morganfainberg is fine with this one. 18:47:34 …is that it clarifies that you can use parent_id on proejct creation to implicitely place the project in the hierarchy and hence what domain it is on 18:47:42 (it is in) 18:48:00 cool 18:48:05 big +2 18:48:18 we're making domain_id optional 18:48:43 htruta: only if you provide a parent_id 18:48:51 since a parent_id implies a domain_id 18:48:55 morganfainberg: ++ 18:49:07 minor usability improvement 18:49:13 yep 18:49:14 and doesn't break any api compat 18:49:17 what should happen if we pass domain_id but no parent? 18:49:30 htruta: ends up as a child of that domain 18:49:36 parent_id = domain there 18:49:41 htruta: then the project is placed as a child of the project acting as that domain 18:49:57 henrynash, morganfainberg... ok 18:50:02 makes sense 18:50:26 any concerns? 18:50:54 morganfainberg: I'm fine with this 18:50:54 please review the spec and score/approve/etc 18:51:15 next topic 18:51:19 #topic Making project.domain_id immutable 18:51:30 isn't this already the case? 18:51:38 i mean defaults to be this way 18:51:41 just following this structure, we might not be able to change domain_id 18:51:41 ?? 18:51:44 I think it's an option 18:51:51 bknudson: yeah its an option 18:51:54 but we default to immutable 18:52:10 morganfainberg: not sure about that, since we used to allow it! 18:52:17 and if anyone complains about security by toggling that i'm going to snicker and tell them to stop allowing it 18:52:19 I guess the default value is True 18:52:30 I think we can't allow change domain_id at all 18:52:31 htruta: yeah it defaults to immutable 18:52:34 for projects 18:52:41 htruta: we're going to need to leave the option 18:52:47 once we'll be always changing the parent_id 18:52:54 what are the consequences of being not immutable? 18:52:57