Open Stack

Excerpts from Sean Dague's message of 2015-06-03 13:34:11 -0400:
> 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.

It doesn't have to live in /etc, though. It could be packaged in the
nova code namespace as a data file, and accessed from there.

Doug