Open Stack

On 06/03/2015 12:10 PM, Tim Hinrichs wrote:
> I definitely buy the idea of layering policies on top of each other. 
> But I'd worry about the long-term feasibility of putting default
> policies into code mainly because it ensures we'll never be able to
> provide any tools that help users (or other services like Horizon) know
> what the effective policy actually is.  In contrast, if the code is just
> an implementation of the API, and there is some (or perhaps several)
> declarative description(s) of which of those APis are permitted to be
> executed by whom, we can build tools to analyze those policies.  Two
> thoughts.
> 
> 1) If the goal is to provide warnings to the user about questionable API
> policy choices, I'd suggest adding policy-analysis functionality to say
> oslo_policy.  The policy-analysis code would take 2 inputs: (i) the
> policy and (ii) a list of policy properties, and would generate a
> warning if any of the properties are true for the given policy.   Then
> each project could provide a file that describes which policy properties
> are questionable, and anyone wanting to see the warnings run the
> functionality on that project's policy and the project's policy property
> file.
> 
> It would definitely help me if we saw a handful of examples of the
> warnings we'd want to generate.

WARN: "server create permissions have been restricted from the default,
this may impede operation and interoperability of your OpenStack
installation"

> 2) If the goal is to provide sensible defaults so the system functions
> if there's no policy.json (or a dynamic policy cached from Keystone),
> why not create a default_policy.json file and use that whenever
> policy.json doesn't exist (or more precisely to use policy.json to
> override default_policy.json in some reasonable way).

Because it's still a file, living in /etc. Files living in etc are
things people feel they can modify. They are also things that don't
always get deployed correctly with code deploys. People might not
realize that default_policy.json is super important to be updated every
time the code is rolled out.

With Nova microversions it's not unexpected that we're going to change
policy a number of times during a cycle (with additional items), and the
layering model only really works if, like db migrations, the model is
strongly coupled to the code.

It's only not discoverable if we don't make it so. See the concept of
"GET /policy" as a way to REST expose this from services. That could be
consumed by Horizon, Keystone, whatever, to get a start of truth version
of policy.

	-Sean

-- 
Sean Dague
http://dague.net