Open Stack

On 06/03/2015 08:40 PM, Tim Hinrichs wrote:
> 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.

Um... why? Nova (or any other server project) needs to know what the
currently computed policy is to actually enforce it internally. Turning
around and spitting that back out on the wire is pretty straight forward.

Is there some secret dragon I'm missing here?

	-Sean

> 
> Tim
> 
> On Wed, Jun 3, 2015 at 1:53 PM, Doug Hellmann <doug at doughellmann.com
> <mailto: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://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> 
> __________________________________________________________________________
> 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
> 


-- 
Sean Dague
http://dague.net