Open Stack

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"








|

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150604/f861218e/attachment-0001.html>