Open Stack

As long as there's some way to get the *declarative* policy from the system
(as a data file or as an API call) that sounds fine.  But I'm dubious that
it will be easy to keep the API call that returns the declarative policy in
sync with the actual code that implements that policy.

Tim

On Wed, Jun 3, 2015 at 1:53 PM, Doug Hellmann <doug at doughellmann.com> wrote:

> 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150603/5f3e1e19/attachment.html>