16:00:45 <lbragstad> #startmeeting policy
16:00:46 <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:47 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:50 <openstack> The meeting name has been set to 'policy'
16:01:12 <gagehugo> o/
16:01:14 <rderose> o/
16:01:18 <lbragstad> o/
16:02:18 <lbragstad> we'll wait a few minutes
16:04:20 <lbragstad> gagehugo rderose attendance is looking light today
16:04:34 <rderose> :)
16:04:39 <gagehugo> lbragstad today seems like a slow day
16:04:47 <rderose> yep
16:04:47 <lbragstad> it does
16:05:03 <lbragstad> it *is* hump day though, so...
16:05:10 <gagehugo> true
16:05:44 <lbragstad> alright - well let's go ahead and start
16:05:50 <lbragstad> others can join in whenever
16:06:02 <lbragstad> it will probably be a quick meeting
16:06:02 <gagehugo> ok
16:06:10 <lbragstad> #topic updates from last meeting
16:06:22 <lbragstad> last time we met i had a couple action items to follow up with nova
16:06:30 <lbragstad> and discuss their efforts on policy
16:07:04 <lbragstad> which went really well, i ended up having a really good conversation with johnthetubaguy that was really insightful
16:07:20 <lbragstad> he was able to highlight some of the motivating factors behind why they wanted to codify their default policy
16:08:00 <lbragstad> and it essentially boils down to the fact that it allows them to "alias" or deprecate default roles
16:08:23 <gagehugo> ah
16:08:26 <lbragstad> so - this is similar to what we do when we use oslo.config to deprecate a configuration option
16:09:04 <lbragstad> something like this - but for oslo.policy http://docs.openstack.org/developer/oslo.config/cfg.html#option-deprecation
16:09:43 <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:10:12 <lbragstad> essentially going through each operation and asking "does this role assignment make sense for this operation?" "can it be improved?"
16:11:03 <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:09 <lbragstad> does that makes sense?
16:11:21 <lbragstad> or does anyone have questions?
16:11:39 <samueldmq> hi, sorry I'm late
16:11:43 <lbragstad> samueldmq no worries
16:12:38 <samueldmq> lbragstad: deprecate default roles or default rules ?
16:12:45 <samueldmq> "and it essentially boils down to the fact that it allows them to "alias" or deprecate default roles"
16:13:09 <lbragstad> samueldmq so nova has a bunch of policy roles/rules they'd like to improve
16:13:23 <lbragstad> (this came out of a discussion that I was having with johnthetubaguy about nova's policy work)
16:13:33 <samueldmq> ok, I have a question
16:13:34 <lbragstad> and it seemed to be the driving factor behind them codifying their policy
16:13:38 <lbragstad> samueldmq shoot
16:13:43 <samueldmq> when does the user hits the deprecation notice ?
16:13:59 <samueldmq> hit*
16:14:01 <lbragstad> samueldmq that'd probably be up to the oslo.policy implementation
16:14:13 <lbragstad> but it could be when the policy is registered so that the operator is aware
16:14:22 <samueldmq> ok, maybe when the policy.json is generated from code, that will be commented out in the file
16:14:37 <lbragstad> just like when a service starts we log deprecation warnings for deprecated configuration options
16:14:48 <samueldmq> lbragstad: policy registered?
16:15:04 <lbragstad> samueldmq sorry - when the policy is loaded
16:15:07 <samueldmq> maybe I am missing something or asking dumb questions, sorry, just making sure I get all the context
16:15:10 <samueldmq> kk
16:15:20 <lbragstad> samueldmq no worries - no dumb questions here
16:15:53 <samueldmq> so it will be something similiar to:
16:15:58 <lbragstad> samueldmq that's another nice thing about codifying policy, is that we can generate policy files instead of maintain them
16:16:06 <lbragstad> (because right now we maintain two)
16:16:11 <samueldmq> oslo.policy.enforce(operation, this_is_the_default_rule)
16:16:18 <edmondsw> samueldmq the policy.json wouldn't be generated from code... it would just stay in the code
16:16:27 <lbragstad> right
16:16:28 <samueldmq> if the actual rule in the .json is different than this_is_the_default_rule, thorw a warning ?
16:16:44 <lbragstad> technically anything in the policy.json file would override the defaults in code
16:16:49 <edmondsw> there is a tool to generate the policy.json from code, but that's not really for operators
16:16:58 <samueldmq> edmondsw: so hw do operators customize it ?
16:17:04 <lbragstad> so the policy.json file, if there is one, would only consist of overrides
16:17:05 <samueldmq> if that's in the code
16:17:23 <edmondsw> samueldmq they add to the blank policy.json file just the things that they want to customize
16:17:30 <lbragstad> edmondsw ++
16:18:02 <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:03 <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:05 <samueldmq> okay, that sounds good, just not getting how oslo.policy will detect an old (deprecated) rule
16:18:25 <lbragstad> samueldmq that's currently a gap in oslo.policy
16:18:31 <lbragstad> (that work hasn't been done yet_
16:18:40 <samueldmq> but do we have an approach to it ?
16:18:48 <lbragstad> we're just entertaining the idea of what we could accomplish if we had that kind of ability
16:19:04 <lbragstad> samueldmq it would be similar to this pattern http://docs.openstack.org/developer/oslo.config/cfg.html#option-deprecation
16:19:15 <lbragstad> or similar developer experience
16:19:20 <edmondsw> lbragstad so how does nova intend to do deprecations?
16:19:51 <samueldmq> I see, but...
16:19:52 <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:53 <edmondsw> I'm not sure I see how deprecation warnings would ever be possible here
16:20:01 <samueldmq> option deprecation is for removal, not for changing default
16:20:06 <samueldmq> which is the case of policy rules
16:20:22 <samueldmq> edmondsw: exactly
16:21:00 <edmondsw> but anyway... I love having policy in code :)
16:21:03 <lbragstad> maybe the word "deprecation" isn't right here
16:21:06 <lbragstad> let me try again
16:21:34 <edmondsw> we probably don't have to design a deprecation strategy today
16:21:37 <lbragstad> from what I understand - nova would want the ability to say this operation and this role is deprecated in favor of x
16:22:03 <samueldmq> lbragstad: what is x ?
16:22:06 <lbragstad> i.e. get_user + admin is deprecated in favor of get_user + cloud_admin
16:22:12 <edmondsw> lbragstad the problem is in how you'd allow the deployer to avoid that deprecation warning
16:22:14 <gagehugo> new role?
16:23:04 <lbragstad> edmondsw that could technically avoid it by overriding it all they want
16:23:05 <lbragstad> edmondsw is that what you mean?
16:23:38 <lbragstad> s/that/they/
16:24:28 <edmondsw> lbragstad so at runtime check if the value is "x" which was the old setting, and issue a deprecation warning?
16:25:01 <samueldmq> edmondsw: what if it was running on default ?
16:25:03 <lbragstad> edmondsw yeah - that might be one approach
16:25:22 <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:28 <samueldmq> if it was running on default, there is no way to issue a warning I think
16:25:51 <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:26:01 <lbragstad> edmondsw true
16:26:17 <samueldmq> changing default will potentially have impact on upgrades
16:26:27 <samueldmq> and a release note is how we notify deployers
16:26:29 <lbragstad> edmondsw both are valid, how that's implemented in oslo.policy could take that into account
16:26:32 <samueldmq> which is no different than we do thay
16:26:33 <edmondsw> and it doesn't give you a way to warn folks that aren't customizing policy when a default changes
16:26:35 <samueldmq> today
16:27:03 <lbragstad> edmondsw it could - i think
16:27: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: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:32 <edmondsw> any other news from nova?
16:27:58 <lbragstad> that was pretty much it - they have a strong use case to deprecate specific policy check in favor of better defaults
16:28:04 <lbragstad> which I think is totally valid
16:28:20 <lbragstad> there may be a few implementation things to work out
16:28:34 <samueldmq> kk I would like to understand that better, maybe we should talk to them to clarify that
16:28:37 <lbragstad> but it will eventually allow them to deploy with a richer set of RBAC checks out of the box
16:28:44 <samueldmq> what are the other use cases ? do you have some in mind ?
16:29:03 <lbragstad> ^ that's pretty much it
16:29:41 <samueldmq> kk
16:29:51 <samueldmq> how does that fit with role checks on middleware ?
16:29:58 <samueldmq> have we thought about it yet ?
16:29:59 <edmondsw> samueldmq for me the primary use case for codifying policy is that it makes it much easier to customize policy
16:30:01 <lbragstad> depending on how things are implemented in olso.policy, we might have a way to get to richer policy
16:30:03 <edmondsw> a) you know your policy.json is ONLY what you've customized
16:30:29 <edmondsw> b) you can see exactly what is using which codified policy settings by seeing where those vars pop up
16:30:45 <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:50 <edmondsw> today it's a nightmare trying to find where different policy rules are actually being checked
16:32:02 <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:08 <samueldmq> maybe in the open discussion topic later
16:32:17 <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:17 <lbragstad> #topic Update on consolidating policy files
16:32:41 <lbragstad> stevemar was going to check and see if henry was available for any discussions around this
16:32:47 <lbragstad> but I haven't seen him on in a while
16:33:04 <lbragstad> we might just have to dive in and figure things out
16:33:24 <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:45 <samueldmq> but we've been always using policy.json
16:33:55 <samueldmq> the cloud one is just for reference afaict
16:34:05 <lbragstad> samueldmq sure - be we also maintain a separate one for cloud admin and v3
16:34:37 <samueldmq> yes, my opinion is that we should merge them by pulling some things from cloud sample
16:34:51 <samueldmq> but again, that would be changing a lot of defaults
16:35:03 <samueldmq> which is a process we're tryign to improve
16:35:04 <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:32 <stevemar> lbragstad: henry has been a bit side tracked lately :(
16:35:35 <lbragstad> we should be sure to document things we hit that break it
16:35:42 <lbragstad> stevemar that's what i figured
16:36:04 <lbragstad> stevemar if he has any time to have that conversation, I'd be happy to accomodate regardless of the time delta
16:36:10 <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:19 <lbragstad> stevemar or we can start a thread if that works better for everyone
16:36:32 <samueldmq> lbragstad: that could work well
16:36:50 <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:37:14 <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:42 <edmondsw> lbragstad yes
16:37:51 <lbragstad> edmondsw ++ that's a good idea, too
16:38:04 <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:16 <edmondsw> more/better testing should be an integral part of this
16:38:18 <lbragstad> edmondsw i like the idea of trying out the oslo.policy deprecation stuff with our own policy hiccups
16:38:32 <stevemar> lbragstad: you're probably better off creating a ML post and sending a note to henry to check it out
16:38:55 <dstanek> edmondsw: is there a documented list of problems anywhere?
16:39:03 <lbragstad> stevemar ack - does anyone have objections to that?
16:39:04 <lbragstad> if not all take that as an action item
16:39:24 <lbragstad> I'll*
16:39:29 <dstanek> it would be nice to capture all those things somewhere if not
16:39:31 <samueldmq> dstanek: ml post ?
16:39:31 <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:38 <samueldmq> dstanek: ++
16:39:49 <edmondsw> I should have opened defects...
16:39:50 <samueldmq> going further, is there a doc with all the roadmap for policy ?
16:39:56 * edmondsw is kicking himself
16:39:59 <samueldmq> with usecases etc, that'd be great
16:40:04 <lbragstad> #action lbragstad to send a note to dev mailing list to work out the mysteries of policy.v3cloudsample.json
16:41:04 <lbragstad> #topic codifying policy.json into oslo.policy
16:41:16 <edmondsw> well we kinda already covered this :)
16:41:25 <lbragstad> edmondsw yeah - just recapping
16:41:27 <dstanek> #link https://etherpad.openstack.org/p/keystone-policy-usecases
16:41:34 <dstanek> samueldmq: ^ what we started with usecases
16:41:47 <samueldmq> dstanek: thanks
16:41:48 <lbragstad> 1.) codify policy.json into oslo.policy using the same approach nova did
16:42:07 <lbragstad> 2.) use oslo.policy deprecation features as an exercise to consolidate policy.v3cloudsample.json
16:42:31 <lbragstad> 3.) continue moving towards richer policy out-of-the-box
16:42:34 <samueldmq> how's 1 ? I thought the rules would go in the project's code, not in oslo.policy
16:42:45 <lbragstad> samueldmq well - they do
16:43:03 <lbragstad> the checks would live in keystone, but still be checked by olso.policy
16:43:14 <samueldmq> yep
16:43:16 <lbragstad> the policy file essentially gets turning into oslo.policy rule objects
16:43:29 <samueldmq> ++
16:43:45 <lbragstad> so - the 3rd point from above is where it gets interesting
16:43:49 <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:55 <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:44:29 <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:36 <lbragstad> edmondsw so 2.) use oslo.policy to improve default policy checks
16:44:37 <lbragstad> ?
16:44: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:59 <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:45:16 <lbragstad> right
16:45:18 <lbragstad> ok
16:45:33 <lbragstad> how does everyone feel about this?
16:45:39 <samueldmq> edmondsw: create new set of tests for every policy entry ?
16:45:52 <samueldmq> lbragstad: sounds a good plan for me
16:46:14 <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:27 <edmondsw> samueldmq yes
16:46:30 <lbragstad> edmondsw ++ that works
16:46:34 <samueldmq> nice
16:47:04 <lbragstad> is anyone interested in taking a stag at codifying what we have in policy.json?
16:47:05 <lbragstad> stab*
16:47:20 <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:22 <samueldmq> is that correct ?
16:47:49 <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:50 <lbragstad> out goal should be to get rid of it completely, but leave the ability for deployers to override if they choose
16:47:52 <dstanek> samueldmq: ++
16:47:58 <lbragstad> our*
16:48:12 <edmondsw> yep
16:48:14 <lbragstad> because it's one less thing for us to maintain
16:48:14 <samueldmq> that's the opposite of role check in middleware
16:48:28 <samueldmq> which would require a full policy file, with only roles in the rules
16:48:32 <samueldmq> anyone agree?
16:48:35 <edmondsw> no
16:48:48 <lbragstad> well - rbac in middleware could pull the defaults from oslo.policy objects, too
16:48:55 <edmondsw> samueldmq why would role check in middleware care whether the policy defaults are in code vs json?
16:49:07 <lbragstad> I don't think it would *require* a policy.json file.. i think it just requires there is a rule
16:49:12 <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:16 <samueldmq> how does the middleware captures the default from the service underneath it ?
16:49:17 <edmondsw> lbragstad ++
16:49:36 <edmondsw> samueldmq it doesn't...?
16:49:41 <samueldmq> the default/the default rule
16:49:49 <lbragstad> middleware is going to capture the operation based on the URL
16:50:06 <samueldmq> okay, and where the role (to check) part come from ?
16:50:17 <ayoung> Middleware
16:50:42 <ayoung> role is the middleware part.  Scope is policy
16:51:04 <lbragstad> fyi - 10 minute warning
16:51:04 <samueldmq> ayoung: where does the role part come from?
16:51:14 <samueldmq> ayoung: a rule is : URL: role.
16:51:27 <samueldmq> URL comes from the request, where is the required role defined ?
16:51:31 <ayoung> https://specs.openstack.org/openstack/keystone-specs/specs/keystone/ongoing/role-check-from-middleware.html
16:51:38 <dstanek> samueldmq: keystone
16:51:43 <edmondsw> samueldmq from what the user sets
16:52:19 <samueldmq> hmm so the rules will be defined in keystone, and fetched by the middleware
16:52:58 <edmondsw> yep
16:53:06 <dstanek> samueldmq: yeah, take a look at the spec. it's pretty interesting
16:53:15 <samueldmq> I will mull it a bit more, I mean both directions together
16:53:43 <lbragstad> ok - so any takers on the policy.json stuff?
16:53:48 <samueldmq> if they will be complementary rather than alternatives
16:54:07 <samueldmq> lbragstad: to write the tests ? or just to analyze the differences?
16:54:19 <lbragstad> samueldmq to start trying to get policy.json into code
16:54:21 <samueldmq> lbragstad: I think we should start with the ML post, and see what henrynash thinks about it
16:54:36 <lbragstad> samueldmq i have that one as an action item for me
16:55:03 <lbragstad> I'll get something written up
16:55:15 <dstanek> so are we going to use the policy.json or the cloud policy as the base for this?
16:55:27 <lbragstad> dstanek i think we are going to try and use policy.json as the base
16:55:37 <lbragstad> (pending discussion with henry)
16:56:26 <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:34 <lbragstad> ++
16:56:47 <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:54 <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:57:04 <lbragstad> edmondsw that'd be awesome
16:57:50 <lbragstad> dstanek well - we'd be able to remove them from policy.json but not cloud policy
16:57:54 <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:59 <ayoung> there are things we need from cloud policy
16:58:20 <ayoung> the big one is that a lot of the tests assume admin is sufficient...but need domain scoped tokens
16:58:39 <lbragstad> (that's gonna be fun)
16:58:42 <ayoung> converting over to rules that say "global admin, or admin on this domain" is going to be necessary
16:58:55 <edmondsw> yay!
16:59:06 <ayoung> see https://review.openstack.org/#/c/257636/15  for the latest attempot
16:59:12 <samueldmq> 1 minute left
16:59:22 <ayoung> passes keystone checks, but fails Tempest due to how roles are assigned (I think)
16:59:25 <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:37 <edmondsw> dstanek like?
16:59:43 <lbragstad> alright - i'll work on getting a ML post out today. let's spill over into #openstack-keystone!
17:00:00 <dstanek> edmondsw: like ayoung said 'cloud admin' vs 'domain admin'
17:00:04 <samueldmq> ayoung: you still have a minute in -keystone ?
17:00:06 <lbragstad> #endmeeting