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 __________________________________________________________________________ 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
