| *** harlowja has quit IRC | 00:09 | |
| *** zerick has quit IRC | 00:12 | |
| *** markvoelker has quit IRC | 00:12 | |
| *** markvoelker has joined #openstack-meeting-cp | 00:12 | |
| *** zerick has joined #openstack-meeting-cp | 00:13 | |
| *** ildikov has quit IRC | 00:13 | |
| *** lcastell has quit IRC | 00:13 | |
| *** jroll has quit IRC | 00:14 | |
| *** lcastell has joined #openstack-meeting-cp | 00:17 | |
| *** ildikov has joined #openstack-meeting-cp | 00:21 | |
| *** jroll has joined #openstack-meeting-cp | 00:21 | |
| *** harlowja has joined #openstack-meeting-cp | 00:25 | |
| *** stvnoyes has quit IRC | 00:47 | |
| *** stvnoyes has joined #openstack-meeting-cp | 00:48 | |
| *** mestery has left #openstack-meeting-cp | 01:17 | |
| *** markvoelker has quit IRC | 01:43 | |
| *** markvoelker has joined #openstack-meeting-cp | 01:44 | |
| *** markvoelker has quit IRC | 01:49 | |
| *** gouthamr has quit IRC | 03:21 | |
| *** markvoelker has joined #openstack-meeting-cp | 03:36 | |
| *** kbyrne has quit IRC | 03:45 | |
| *** kbyrne has joined #openstack-meeting-cp | 03:48 | |
| *** ayoung has quit IRC | 03:53 | |
| *** sheel has joined #openstack-meeting-cp | 04:34 | |
| *** itisha has quit IRC | 06:12 | |
| *** dims has quit IRC | 06:13 | |
| *** MarkBaker has joined #openstack-meeting-cp | 06:28 | |
| *** sheel has quit IRC | 06:37 | |
| *** MarkBaker has quit IRC | 07:20 | |
| *** MarkBaker has joined #openstack-meeting-cp | 07:23 | |
| *** MarkBaker has quit IRC | 07:39 | |
| *** hogepodge has quit IRC | 07:56 | |
| *** sheeprine has quit IRC | 08:05 | |
| *** sheeprine has joined #openstack-meeting-cp | 08:09 | |
| *** edtubill has quit IRC | 08:13 | |
| *** lyarwood is now known as lyarwood_ | 08:30 | |
| *** MarkBaker has joined #openstack-meeting-cp | 08:53 | |
| *** cartik has joined #openstack-meeting-cp | 08:59 | |
| *** MarkBaker has quit IRC | 09:27 | |
| *** cartik has quit IRC | 09:50 | |
| *** MarkBaker has joined #openstack-meeting-cp | 09:55 | |
| *** lyarwood_ is now known as lyarwood | 10:02 | |
| *** lyarwood is now known as lyarwood_ | 10:03 | |
| *** MarkBaker has quit IRC | 10:31 | |
| *** sdague has joined #openstack-meeting-cp | 11:15 | |
| *** MarkBaker has joined #openstack-meeting-cp | 11:29 | |
| *** dims has joined #openstack-meeting-cp | 11:39 | |
| *** MarkBaker has quit IRC | 11:47 | |
| *** MarkBaker has joined #openstack-meeting-cp | 12:53 | |
| *** ducttape_ has quit IRC | 13:14 | |
| *** ducttape_ has joined #openstack-meeting-cp | 13:17 | |
| *** MarkBaker has quit IRC | 13:22 | |
| *** MarkBaker has joined #openstack-meeting-cp | 13:25 | |
| *** MarkBaker has quit IRC | 13:48 | |
| *** david-lyle has quit IRC | 13:56 | |
| *** crinkle_ has quit IRC | 13:59 | |
| *** david-lyle has joined #openstack-meeting-cp | 13:59 | |
| *** crinkle_ has joined #openstack-meeting-cp | 13:59 | |
| *** lamt has joined #openstack-meeting-cp | 14:01 | |
| *** zhipeng has joined #openstack-meeting-cp | 14:02 | |
| *** zhipeng has left #openstack-meeting-cp | 14:02 | |
| *** itisha has joined #openstack-meeting-cp | 14:11 | |
| *** jkomg has joined #openstack-meeting-cp | 14:13 | |
| *** ducttape_ has quit IRC | 14:14 | |
| *** david-lyle has quit IRC | 14:16 | |
| *** MarkBaker has joined #openstack-meeting-cp | 14:35 | |
| *** lamt has quit IRC | 14:40 | |
| *** ducttape_ has joined #openstack-meeting-cp | 14:45 | |
| *** gouthamr has joined #openstack-meeting-cp | 14:52 | |
| *** MarkBaker has quit IRC | 14:54 | |
| *** MarkBaker has joined #openstack-meeting-cp | 15:08 | |
| *** edtubill has joined #openstack-meeting-cp | 15:14 | |
| *** david-lyle has joined #openstack-meeting-cp | 15:17 | |
| *** david-lyle has quit IRC | 15:21 | |
| *** markvoelker has quit IRC | 15:28 | |
| *** jaugustine has joined #openstack-meeting-cp | 15:29 | |
| *** markvoelker has joined #openstack-meeting-cp | 15:29 | |
| *** markvoelker has quit IRC | 15:35 | |
| *** spilla has joined #openstack-meeting-cp | 15:36 | |
| *** diablo_rojo_phon has joined #openstack-meeting-cp | 15:38 | |
| *** MarkBaker has quit IRC | 15:50 | |
| *** diablo_rojo has joined #openstack-meeting-cp | 15:56 | |
| *** markvoelker has joined #openstack-meeting-cp | 15:57 | |
| lbragstad | ping raildo, ktychkova, dolphm, dstanek, rderose, htruta, atrmr, gagehugo, lamt, thinrichs, edmondsw, ruan, ayoung, stevemar | 16:00 |
|---|---|---|
| *** edmondsw has joined #openstack-meeting-cp | 16:00 | |
| lbragstad | #startmeeting policy | 16:00 |
| openstack | Meeting started Wed Jan 11 16:00:45 2017 UTC and is due to finish in 60 minutes. The chair is lbragstad. Information about MeetBot at http://wiki.debian.org/MeetBot. | 16:00 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 16:00 |
| *** openstack changes topic to " (Meeting topic: policy)" | 16:00 | |
| openstack | The meeting name has been set to 'policy' | 16:00 |
| *** gagehugo has joined #openstack-meeting-cp | 16:01 | |
| gagehugo | o/ | 16:01 |
| rderose | o/ | 16:01 |
| lbragstad | o/ | 16:01 |
| lbragstad | we'll wait a few minutes | 16:02 |
| *** lamt has joined #openstack-meeting-cp | 16:03 | |
| lbragstad | gagehugo rderose attendance is looking light today | 16:04 |
| rderose | :) | 16:04 |
| gagehugo | lbragstad today seems like a slow day | 16:04 |
| rderose | yep | 16:04 |
| lbragstad | it does | 16:04 |
| lbragstad | it *is* hump day though, so... | 16:05 |
| gagehugo | true | 16:05 |
| lbragstad | alright - well let's go ahead and start | 16:05 |
| lbragstad | others can join in whenever | 16:05 |
| lbragstad | it will probably be a quick meeting | 16:06 |
| gagehugo | ok | 16:06 |
| lbragstad | #topic updates from last meeting | 16:06 |
| *** openstack changes topic to "updates from last meeting (Meeting topic: policy)" | 16:06 | |
| lbragstad | last time we met i had a couple action items to follow up with nova | 16:06 |
| lbragstad | and discuss their efforts on policy | 16:06 |
| lbragstad | which went really well, i ended up having a really good conversation with johnthetubaguy that was really insightful | 16:07 |
| lbragstad | he was able to highlight some of the motivating factors behind why they wanted to codify their default policy | 16:07 |
| lbragstad | and it essentially boils down to the fact that it allows them to "alias" or deprecate default roles | 16:08 |
| *** ravelar has joined #openstack-meeting-cp | 16:08 | |
| gagehugo | ah | 16:08 |
| lbragstad | so - this is similar to what we do when we use oslo.config to deprecate a configuration option | 16:08 |
| *** ruan_18 has joined #openstack-meeting-cp | 16:08 | |
| lbragstad | something like this - but for oslo.policy http://docs.openstack.org/developer/oslo.config/cfg.html#option-deprecation | 16:09 |
| lbragstad | but another interesting side-effect of codifying policy that johnthetubaguy pointed out that I thought was really smart was that they use it as an exercise to assess all the default policy rules/roles | 16:09 |
| lbragstad | essentially going through each operation and asking "does this role assignment make sense for this operation?" "can it be improved?" | 16:10 |
| lbragstad | because once we have a way to deprecate things using oslo.policy, we have a way to start fixing those ^ depending on what the answer was | 16:11 |
| lbragstad | does that makes sense? | 16:11 |
| lbragstad | or does anyone have questions? | 16:11 |
| samueldmq | hi, sorry I'm late | 16:11 |
| lbragstad | samueldmq no worries | 16:11 |
| *** ayoung has joined #openstack-meeting-cp | 16:12 | |
| samueldmq | lbragstad: deprecate default roles or default rules ? | 16:12 |
| samueldmq | "and it essentially boils down to the fact that it allows them to "alias" or deprecate default roles" | 16:12 |
| lbragstad | samueldmq so nova has a bunch of policy roles/rules they'd like to improve | 16:13 |
| lbragstad | (this came out of a discussion that I was having with johnthetubaguy about nova's policy work) | 16:13 |
| samueldmq | ok, I have a question | 16:13 |
| lbragstad | and it seemed to be the driving factor behind them codifying their policy | 16:13 |
| lbragstad | samueldmq shoot | 16:13 |
| samueldmq | when does the user hits the deprecation notice ? | 16:13 |
| *** Rockyg has joined #openstack-meeting-cp | 16:13 | |
| samueldmq | hit* | 16:13 |
| lbragstad | samueldmq that'd probably be up to the oslo.policy implementation | 16:14 |
| lbragstad | but it could be when the policy is registered so that the operator is aware | 16:14 |
| samueldmq | ok, maybe when the policy.json is generated from code, that will be commented out in the file | 16:14 |
| lbragstad | just like when a service starts we log deprecation warnings for deprecated configuration options | 16:14 |
| samueldmq | lbragstad: policy registered? | 16:14 |
| lbragstad | samueldmq sorry - when the policy is loaded | 16:15 |
| samueldmq | maybe I am missing something or asking dumb questions, sorry, just making sure I get all the context | 16:15 |
| samueldmq | kk | 16:15 |
| lbragstad | samueldmq no worries - no dumb questions here | 16:15 |
| samueldmq | so it will be something similiar to: | 16:15 |
| lbragstad | samueldmq that's another nice thing about codifying policy, is that we can generate policy files instead of maintain them | 16:15 |
| lbragstad | (because right now we maintain two) | 16:16 |
| samueldmq | oslo.policy.enforce(operation, this_is_the_default_rule) | 16:16 |
| edmondsw | samueldmq the policy.json wouldn't be generated from code... it would just stay in the code | 16:16 |
| lbragstad | right | 16:16 |
| samueldmq | if the actual rule in the .json is different than this_is_the_default_rule, thorw a warning ? | 16:16 |
| lbragstad | technically anything in the policy.json file would override the defaults in code | 16:16 |
| edmondsw | there is a tool to generate the policy.json from code, but that's not really for operators | 16:16 |
| samueldmq | edmondsw: so hw do operators customize it ? | 16:16 |
| lbragstad | so the policy.json file, if there is one, would only consist of overrides | 16:17 |
| samueldmq | if that's in the code | 16:17 |
| edmondsw | samueldmq they add to the blank policy.json file just the things that they want to customize | 16:17 |
| lbragstad | edmondsw ++ | 16:17 |
| lbragstad | if an operator only needs to override the "get_user" operation, their keystone policy.json file would only have to consist of that override | 16:18 |
| edmondsw | if they want to customize a whole lot, maybe they would use the tool to generate policy.json, and then go through it line by line and remove what they don't want to change and edit what they do | 16:18 |
| samueldmq | okay, that sounds good, just not getting how oslo.policy will detect an old (deprecated) rule | 16:18 |
| lbragstad | samueldmq that's currently a gap in oslo.policy | 16:18 |
| lbragstad | (that work hasn't been done yet_ | 16:18 |
| samueldmq | but do we have an approach to it ? | 16:18 |
| lbragstad | we're just entertaining the idea of what we could accomplish if we had that kind of ability | 16:18 |
| lbragstad | samueldmq it would be similar to this pattern http://docs.openstack.org/developer/oslo.config/cfg.html#option-deprecation | 16:19 |
| lbragstad | or similar developer experience | 16:19 |
| edmondsw | lbragstad so how does nova intend to do deprecations? | 16:19 |
| samueldmq | I see, but... | 16:19 |
| lbragstad | edmondsw that's a great question for johnthetubaguy, but from my discussion with him, it sounds like they would include some sort of deprecated kwarg in the policy rule | 16:19 |
| edmondsw | I'm not sure I see how deprecation warnings would ever be possible here | 16:19 |
| samueldmq | option deprecation is for removal, not for changing default | 16:20 |
| samueldmq | which is the case of policy rules | 16:20 |
| samueldmq | edmondsw: exactly | 16:20 |
| edmondsw | but anyway... I love having policy in code :) | 16:21 |
| lbragstad | maybe the word "deprecation" isn't right here | 16:21 |
| lbragstad | let me try again | 16:21 |
| edmondsw | we probably don't have to design a deprecation strategy today | 16:21 |
| lbragstad | from what I understand - nova would want the ability to say this operation and this role is deprecated in favor of x | 16:21 |
| samueldmq | lbragstad: what is x ? | 16:22 |
| lbragstad | i.e. get_user + admin is deprecated in favor of get_user + cloud_admin | 16:22 |
| edmondsw | lbragstad the problem is in how you'd allow the deployer to avoid that deprecation warning | 16:22 |
| gagehugo | new role? | 16:22 |
| lbragstad | edmondsw that could technically avoid it by overriding it all they want | 16:23 |
| lbragstad | edmondsw is that what you mean? | 16:23 |
| lbragstad | s/that/they/ | 16:23 |
| edmondsw | lbragstad so at runtime check if the value is "x" which was the old setting, and issue a deprecation warning? | 16:24 |
| samueldmq | edmondsw: what if it was running on default ? | 16:25 |
| lbragstad | edmondsw yeah - that might be one approach | 16:25 |
| edmondsw | a) that doesn't really solve the case where I don't care that nova has changed what they want the default to be, I still want to use this | 16:25 |
| samueldmq | if it was running on default, there is no way to issue a warning I think | 16:25 |
| edmondsw | I shouldn't have to live with a deprecation warning forever because I have a different opinion on what I want the policy value to be | 16:25 |
| lbragstad | edmondsw true | 16:26 |
| samueldmq | changing default will potentially have impact on upgrades | 16:26 |
| samueldmq | and a release note is how we notify deployers | 16:26 |
| lbragstad | edmondsw both are valid, how that's implemented in oslo.policy could take that into account | 16:26 |
| samueldmq | which is no different than we do thay | 16:26 |
| edmondsw | and it doesn't give you a way to warn folks that aren't customizing policy when a default changes | 16:26 |
| samueldmq | today | 16:26 |
| lbragstad | edmondsw it could - i think | 16:27 |
| lbragstad | if we have policy in code, like we do with config, we have the ability to write tooling to provide those things | 16:27 |
| edmondsw | anyway, I don't think that's a solvable problem, but there are other good reasons to codify policy as we've discussed before | 16:27 |
| edmondsw | any other news from nova? | 16:27 |
| lbragstad | that was pretty much it - they have a strong use case to deprecate specific policy check in favor of better defaults | 16:27 |
| lbragstad | which I think is totally valid | 16:28 |
| lbragstad | there may be a few implementation things to work out | 16:28 |
| samueldmq | kk I would like to understand that better, maybe we should talk to them to clarify that | 16:28 |
| lbragstad | but it will eventually allow them to deploy with a richer set of RBAC checks out of the box | 16:28 |
| samueldmq | what are the other use cases ? do you have some in mind ? | 16:28 |
| lbragstad | ^ that's pretty much it | 16:29 |
| samueldmq | kk | 16:29 |
| samueldmq | how does that fit with role checks on middleware ? | 16:29 |
| samueldmq | have we thought about it yet ? | 16:29 |
| edmondsw | samueldmq for me the primary use case for codifying policy is that it makes it much easier to customize policy | 16:29 |
| lbragstad | depending on how things are implemented in olso.policy, we might have a way to get to richer policy | 16:30 |
| edmondsw | a) you know your policy.json is ONLY what you've customized | 16:30 |
| edmondsw | b) you can see exactly what is using which codified policy settings by seeing where those vars pop up | 16:30 |
| lbragstad | samueldmq i consider role check in middleware to be a separate approach that can be enabled by a deployer if they want to use it | 16:30 |
| edmondsw | today it's a nightmare trying to find where different policy rules are actually being checked | 16:30 |
| samueldmq | lbragstad: kk I will very likely be working in a tool to validate policies this year, I'd like to get some input here | 16:32 |
| samueldmq | maybe in the open discussion topic later | 16:32 |
| lbragstad | so - from a keystone perspective, if we wanted to move in that direction it's going to be extra tough since we have two policy files | 16:32 |
| lbragstad | #topic Update on consolidating policy files | 16:32 |
| *** openstack changes topic to "Update on consolidating policy files (Meeting topic: policy)" | 16:32 | |
| lbragstad | stevemar was going to check and see if henry was available for any discussions around this | 16:32 |
| lbragstad | but I haven't seen him on in a while | 16:32 |
| lbragstad | we might just have to dive in and figure things out | 16:33 |
| lbragstad | because in order to codify policy, we'd need to work from a file, and right now we have two of them | 16:33 |
| samueldmq | but we've been always using policy.json | 16:33 |
| samueldmq | the cloud one is just for reference afaict | 16:33 |
| lbragstad | samueldmq sure - be we also maintain a separate one for cloud admin and v3 | 16:34 |
| samueldmq | yes, my opinion is that we should merge them by pulling some things from cloud sample | 16:34 |
| samueldmq | but again, that would be changing a lot of defaults | 16:34 |
| samueldmq | which is a process we're tryign to improve | 16:35 |
| lbragstad | right - and it might take a while to get it right if we don't have the tribal knowledge that henry has around it | 16:35 |
| stevemar | lbragstad: henry has been a bit side tracked lately :( | 16:35 |
| lbragstad | we should be sure to document things we hit that break it | 16:35 |
| lbragstad | stevemar that's what i figured | 16:35 |
| lbragstad | stevemar if he has any time to have that conversation, I'd be happy to accomodate regardless of the time delta | 16:36 |
| edmondsw | lbragstad, you mentioned before how nova used the exercise of codifying policy to go through and check all their values... I think that merging the two policy files would naturally fit into that | 16:36 |
| lbragstad | stevemar or we can start a thread if that works better for everyone | 16:36 |
| samueldmq | lbragstad: that could work well | 16:36 |
| edmondsw | as you go through and codify one thing at a time (shouldn't all be in one huge patch set), you look at both of our current policy files and pick a value to codify that will work for both cases | 16:36 |
| lbragstad | edmondsw so - you propose we start with codifying policy.json and then use it as a tool to consolidate the check in policy.v3cloudsample.json | 16:37 |
| edmondsw | lbragstad yes | 16:37 |
| lbragstad | edmondsw ++ that's a good idea, too | 16:37 |
| edmondsw | there are a bunch of problems with the current v3cloudsample policy, so don't just grab the values there without looking at them and adding test cases to prove things work | 16:38 |
| edmondsw | more/better testing should be an integral part of this | 16:38 |
| lbragstad | edmondsw i like the idea of trying out the oslo.policy deprecation stuff with our own policy hiccups | 16:38 |
| stevemar | lbragstad: you're probably better off creating a ML post and sending a note to henry to check it out | 16:38 |
| dstanek | edmondsw: is there a documented list of problems anywhere? | 16:38 |
| lbragstad | stevemar ack - does anyone have objections to that? | 16:39 |
| lbragstad | if not all take that as an action item | 16:39 |
| lbragstad | I'll* | 16:39 |
| dstanek | it would be nice to capture all those things somewhere if not | 16:39 |
| samueldmq | dstanek: ml post ? | 16:39 |
| edmondsw | dstanek unfortunately no... I just remember last time I tried to use things from it as a basis for my own customization I kept hitting issues | 16:39 |
| samueldmq | dstanek: ++ | 16:39 |
| edmondsw | I should have opened defects... | 16:39 |
| samueldmq | going further, is there a doc with all the roadmap for policy ? | 16:39 |
| * edmondsw is kicking himself | 16:39 | |
| samueldmq | with usecases etc, that'd be great | 16:39 |
| lbragstad | #action lbragstad to send a note to dev mailing list to work out the mysteries of policy.v3cloudsample.json | 16:40 |
| lbragstad | #topic codifying policy.json into oslo.policy | 16:41 |
| *** openstack changes topic to "codifying policy.json into oslo.policy (Meeting topic: policy)" | 16:41 | |
| edmondsw | well we kinda already covered this :) | 16:41 |
| lbragstad | edmondsw yeah - just recapping | 16:41 |
| dstanek | #link https://etherpad.openstack.org/p/keystone-policy-usecases | 16:41 |
| dstanek | samueldmq: ^ what we started with usecases | 16:41 |
| samueldmq | dstanek: thanks | 16:41 |
| lbragstad | 1.) codify policy.json into oslo.policy using the same approach nova did | 16:41 |
| lbragstad | 2.) use oslo.policy deprecation features as an exercise to consolidate policy.v3cloudsample.json | 16:42 |
| lbragstad | 3.) continue moving towards richer policy out-of-the-box | 16:42 |
| samueldmq | how's 1 ? I thought the rules would go in the project's code, not in oslo.policy | 16:42 |
| lbragstad | samueldmq well - they do | 16:42 |
| lbragstad | the checks would live in keystone, but still be checked by olso.policy | 16:43 |
| samueldmq | yep | 16:43 |
| lbragstad | the policy file essentially gets turning into oslo.policy rule objects | 16:43 |
| samueldmq | ++ | 16:43 |
| lbragstad | so - the 3rd point from above is where it gets interesting | 16:43 |
| samueldmq | I am also a bit concerned about 2, I'd like to understand that better. would be great if we could clarify with nova folks | 16:43 |
| edmondsw | I don't think #2 should mention deprecation... as discussed above, there's no deprecation method for this today, and that's probably not even a solvable problem | 16:43 |
| samueldmq | exactly, let's find an approach to it, I think the only way is via releasenotes anyways, just letting deployers know the default has changed | 16:44 |
| lbragstad | edmondsw so 2.) use oslo.policy to improve default policy checks | 16:44 |
| lbragstad | ? | 16:44 |
| edmondsw | #2 should just be that as we move things into code, we have decide what values to put in the code... so it's a perfect time to look at both our policy files and see what they have and consider shortcomings and decide what makes the most sense to codify | 16:44 |
| samueldmq | a:X has changed to a:Y. then they can override a:Y with a:X in the file if they want the old rule | 16:44 |
| lbragstad | right | 16:45 |
| lbragstad | ok | 16:45 |
| lbragstad | how does everyone feel about this? | 16:45 |
| samueldmq | edmondsw: create new set of tests for every policy entry ? | 16:45 |
| samueldmq | lbragstad: sounds a good plan for me | 16:45 |
| edmondsw | 2.) choose policy rule defaults to codify that will satisfy both single- and multi-domain cases (policy.json vs. policy.v3cloudsample.json) | 16:46 |
| edmondsw | samueldmq yes | 16:46 |
| lbragstad | edmondsw ++ that works | 16:46 |
| samueldmq | nice | 16:46 |
| lbragstad | is anyone interested in taking a stag at codifying what we have in policy.json? | 16:47 |
| lbragstad | stab* | 16:47 |
| samueldmq | the goal with that is that we get rid of the .json file as much as we can, leaving there just the overrides. | 16:47 |
| samueldmq | is that correct ? | 16:47 |
| edmondsw | yes... as you codify something, you remove it from the policy.json and policy.v3cloudsample.json, so those files get progressively shorter | 16:47 |
| lbragstad | out goal should be to get rid of it completely, but leave the ability for deployers to override if they choose | 16:47 |
| dstanek | samueldmq: ++ | 16:47 |
| lbragstad | our* | 16:47 |
| edmondsw | yep | 16:48 |
| lbragstad | because it's one less thing for us to maintain | 16:48 |
| samueldmq | that's the opposite of role check in middleware | 16:48 |
| samueldmq | which would require a full policy file, with only roles in the rules | 16:48 |
| samueldmq | anyone agree? | 16:48 |
| edmondsw | no | 16:48 |
| lbragstad | well - rbac in middleware could pull the defaults from oslo.policy objects, too | 16:48 |
| edmondsw | samueldmq why would role check in middleware care whether the policy defaults are in code vs json? | 16:48 |
| lbragstad | I don't think it would *require* a policy.json file.. i think it just requires there is a rule | 16:49 |
| dstanek | samueldmq: i didnt' think so. my understanding is it moved a role check out to middleware, but policy largely does what it currently does | 16:49 |
| samueldmq | how does the middleware captures the default from the service underneath it ? | 16:49 |
| edmondsw | lbragstad ++ | 16:49 |
| edmondsw | samueldmq it doesn't...? | 16:49 |
| samueldmq | the default/the default rule | 16:49 |
| lbragstad | middleware is going to capture the operation based on the URL | 16:49 |
| samueldmq | okay, and where the role (to check) part come from ? | 16:50 |
| ayoung | Middleware | 16:50 |
| ayoung | role is the middleware part. Scope is policy | 16:50 |
| lbragstad | fyi - 10 minute warning | 16:51 |
| samueldmq | ayoung: where does the role part come from? | 16:51 |
| samueldmq | ayoung: a rule is : URL: role. | 16:51 |
| samueldmq | URL comes from the request, where is the required role defined ? | 16:51 |
| ayoung | https://specs.openstack.org/openstack/keystone-specs/specs/keystone/ongoing/role-check-from-middleware.html | 16:51 |
| dstanek | samueldmq: keystone | 16:51 |
| edmondsw | samueldmq from what the user sets | 16:51 |
| samueldmq | hmm so the rules will be defined in keystone, and fetched by the middleware | 16:52 |
| edmondsw | yep | 16:52 |
| dstanek | samueldmq: yeah, take a look at the spec. it's pretty interesting | 16:53 |
| samueldmq | I will mull it a bit more, I mean both directions together | 16:53 |
| lbragstad | ok - so any takers on the policy.json stuff? | 16:53 |
| samueldmq | if they will be complementary rather than alternatives | 16:53 |
| samueldmq | lbragstad: to write the tests ? or just to analyze the differences? | 16:54 |
| lbragstad | samueldmq to start trying to get policy.json into code | 16:54 |
| samueldmq | lbragstad: I think we should start with the ML post, and see what henrynash thinks about it | 16:54 |
| lbragstad | samueldmq i have that one as an action item for me | 16:54 |
| lbragstad | I'll get something written up | 16:55 |
| dstanek | so are we going to use the policy.json or the cloud policy as the base for this? | 16:55 |
| lbragstad | dstanek i think we are going to try and use policy.json as the base | 16:55 |
| lbragstad | (pending discussion with henry) | 16:55 |
| *** jkomg has quit IRC | 16:56 | |
| dstanek | lbragstad: i think that's a good idea otherwise existing deployments would have to have almost a complete policy.json to keep things working | 16:56 |
| lbragstad | ++ | 16:56 |
| edmondsw | lbragstad I will help with reviews, but I'm not sure how much time I'll have to code on it... if i have time I'll pitch in | 16:56 |
| dstanek | i asked because it was started earlier that when things are hard coded they can be removed from policy.json and the cloud policy, but that really isn't true | 16:56 |
| *** jkomg has joined #openstack-meeting-cp | 16:56 | |
| lbragstad | edmondsw that'd be awesome | 16:57 |
| *** Guinu has joined #openstack-meeting-cp | 16:57 | |
| lbragstad | dstanek well - we'd be able to remove them from policy.json but not cloud policy | 16:57 |
| edmondsw | dstanek I don't think one or the other is the basis... I think we look at both and pick a value that will work for both cases | 16:57 |
| ayoung | there are things we need from cloud policy | 16:57 |
| ayoung | the big one is that a lot of the tests assume admin is sufficient...but need domain scoped tokens | 16:58 |
| lbragstad | (that's gonna be fun) | 16:58 |
| ayoung | converting over to rules that say "global admin, or admin on this domain" is going to be necessary | 16:58 |
| edmondsw | yay! | 16:58 |
| ayoung | see https://review.openstack.org/#/c/257636/15 for the latest attempot | 16:59 |
| samueldmq | 1 minute left | 16:59 |
| ayoung | passes keystone checks, but fails Tempest due to how roles are assigned (I think) | 16:59 |
| dstanek | edmondsw: i don't think you can mix and match - the cloud policy makes some assumptions that are not compatible without adding in lots of it | 16:59 |
| edmondsw | dstanek like? | 16:59 |
| lbragstad | alright - i'll work on getting a ML post out today. let's spill over into #openstack-keystone! | 16:59 |
| dstanek | edmondsw: like ayoung said 'cloud admin' vs 'domain admin' | 17:00 |
| samueldmq | ayoung: you still have a minute in -keystone ? | 17:00 |
| lbragstad | #endmeeting | 17:00 |
| *** openstack changes topic to " (Meeting topic: cinder-nova-api-changes)" | 17:00 | |
| openstack | Meeting ended Wed Jan 11 17:00:06 2017 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 17:00 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/policy/2017/policy.2017-01-11-16.00.html | 17:00 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/policy/2017/policy.2017-01-11-16.00.txt | 17:00 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/policy/2017/policy.2017-01-11-16.00.log.html | 17:00 |
| *** Guinu has quit IRC | 17:00 | |
| *** gagehugo has left #openstack-meeting-cp | 17:01 | |
| *** jkomg has quit IRC | 17:01 | |
| *** ruan_18 has quit IRC | 17:06 | |
| *** jaugustine has quit IRC | 17:45 | |
| *** edmondsw has left #openstack-meeting-cp | 18:13 | |
| *** david-lyle has joined #openstack-meeting-cp | 18:15 | |
| *** david-lyle has quit IRC | 18:16 | |
| *** david-lyle has joined #openstack-meeting-cp | 18:16 | |
| *** jaugustine has joined #openstack-meeting-cp | 18:20 | |
| *** Rockyg has quit IRC | 18:51 | |
| *** jkomg has joined #openstack-meeting-cp | 18:59 | |
| *** jkomg has quit IRC | 19:03 | |
| *** jkomg has joined #openstack-meeting-cp | 20:02 | |
| *** ayoung has quit IRC | 20:06 | |
| *** jkomg has quit IRC | 20:11 | |
| *** jaugustine has quit IRC | 20:23 | |
| *** jaugustine has joined #openstack-meeting-cp | 20:24 | |
| *** jaugustine_ has joined #openstack-meeting-cp | 20:26 | |
| *** jaugustine has quit IRC | 20:26 | |
| *** jkomg has joined #openstack-meeting-cp | 20:52 | |
| *** jkomg has quit IRC | 20:53 | |
| *** jkomg has joined #openstack-meeting-cp | 20:53 | |
| *** xyang1 has joined #openstack-meeting-cp | 20:55 | |
| *** lyarwood_ is now known as lyarwood | 21:02 | |
| *** diablo_rojo_phon has quit IRC | 21:20 | |
| *** MarkBaker has joined #openstack-meeting-cp | 21:54 | |
| *** spilla has left #openstack-meeting-cp | 21:55 | |
| *** MarkBaker has quit IRC | 22:12 | |
| *** ayoung has joined #openstack-meeting-cp | 22:13 | |
| *** markvoelker has quit IRC | 22:29 | |
| *** markvoelker has joined #openstack-meeting-cp | 22:32 | |
| *** edtubill has quit IRC | 22:34 | |
| *** markvoelker has quit IRC | 22:34 | |
| *** markvoelker has joined #openstack-meeting-cp | 22:34 | |
| *** markvoelker_ has joined #openstack-meeting-cp | 22:39 | |
| *** markvoelker has quit IRC | 22:39 | |
| *** kberger has joined #openstack-meeting-cp | 22:41 | |
| *** ayoung has quit IRC | 22:51 | |
| *** ravelar has quit IRC | 22:53 | |
| *** ChanServ changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings" | 23:04 | |
| *** lamt has quit IRC | 23:11 | |
| *** markvoelker_ has quit IRC | 23:32 | |
| *** edtubill has joined #openstack-meeting-cp | 23:36 | |
| *** markvoelker has joined #openstack-meeting-cp | 23:40 | |
| *** edtubill has quit IRC | 23:40 | |
| *** xyang1 has quit IRC | 23:55 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!