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"
|
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
