Open Stack

On 06/04/2015 01:03 PM, Adam Young wrote:
> On 06/04/2015 09:40 AM, Sean Dague wrote:
>> So I feel like I understand the high level dynamic policy end game. I
>> feel like what I'm proposing for policy engine with encoded defaults
>> doesn't negatively impact that. I feel there is a middle chunk where
>> perhaps we've got different concerns or different dragons that we see,
>> and are mostly talking past each other. And I don't know how to bridge
>> that. All the keystone specs I've dived into definitely assume a level
>> of understanding of keystone internals and culture that aren't obvious
>> from the outside. 
> 
> Policy is not currently designed to be additive;  let's take the Nova rule||
> ||
> ||"get_network": "rule:admin_or_owner or rule:shared or rule:external or
> rule:context_is_advsvc"||
> ||
> |FROM
> http://git.openstack.org/cgit/openstack/neutron/tree/etc/policy.json#n27|
> ||
> |This pulls in |
> 
> "external": "field:networks:router:external=True",
> |
> Now, we have a single JSON file that implements this. Lets say that you
> ended up coding exactly this rule in python. What would that mean? 
> Either you make some way of initializing oslo.policy from a Python
> object, or you enforce outside of Oslo.policy (custom nova Code).  If it
> is custom code, you  have to say "run oslo or run my logic"
> everywhere...you can see that this approach leads to fragementation of
> policy enforcement.
> 
> So, instead, you go the "initialize oslo from Python."  We currentl have
> the idea of multiple policy files in the directory, so you just treat
> the Python code as a file with either the lowest or highest ABC order,
> depending.  Now, each policy file gets read, and the rules are a
> hashtable, keyed by the rule name.  So both get_network and external are
> keys that get read in.  If 'overwrite' is set, it will only process the
> last set of rules (replaces all rules)  but I think what we want here is
> just update:
> 
> http://git.openstack.org/cgit/openstack/oslo.policy/tree/oslo_policy/policy.py#n361
> Which would mix together the existing rules with the rules from the
> policy files. 
> 
> 
> So...what would your intention be with hardcoding the policy in Nova? 
> That your rule gets overwritten with the rule that comes from the
> centralized policy store, or that you rule gets executed in addition to
> the rule from central?  Neither are going to get you what you want,
> which is "Make sure you can't break Nova by changing Policy"

It gets overwritten by the central store.

And you are wrong, that gives me what I want, because we can emit a
WARNING in the logs if the patch is something crazy. The operators will
see it, and be able to fix it later.

I'm not trying to prevent people from changing their policy in crazy
ways. I'm trying to build in some safety net where we can detect it's
kind of a bad idea and emit that information a place that Operators can
see and sort out later, instead of pulling their hair out.

But you can only do that if you have encoded what's the default, plus
annotations about ways that changing the default are unwise.

	-Sean

-- 
Sean Dague
http://dague.net