Open Stack

On 06/03/2015 01:43 PM, Sean Dague wrote:
> Assume that Keystone git tree owns that file. Nova adds an API via
> microversions for an intermediate milestone that adds new policy in.
> Deployers CD this version out, leaving Keystone at the previous release
> version. Now Nova has code out there that requires policy which doesn't
> exist. The policy at some level is really linked to the code.

I was thinking it would go in its own git repo, with appropria\te cross 
project oversite, but I see your concern.

>
> In a world of microversions this is now a lot more like database schema,
> because big bang API changes are a thing of the past (at least on the
> Nova side). (Note: I'm working up some more general explanation of that
> whole model shortly, part of our comms plan out of summit).

So...what if we change the approach like this:

1.  Namespaces can have defaults.
2. The unified policy file will be updated for each micro version, but 
anything not explicitly added will get the namespace default.

Then, the only thing esssential to pre-position in the global file would 
be the ones that do not meet the default criteria.  For most APIs, I am 
guessing the default would be role.admin to start, with it being a 
deliberate decision to change an API to public consumption via 
role.Member or more granular.


I don't see the unified policy file replacing the project defaults, at 
least not for a while.  I think too many people are deploying with the 
Niova , keystone etc.  defaults for us to significantly change those 
without breaking existing setups. I see the unified policy  file as an 
effort to get a reasonable set of defaults that a deployment could use 
as a starting point for customizing its own policy.  When we move from 
static policy to dynamic policy, we are going to need.

If we don't at least code up a unified policy file as an example, I 
don't think we will be able to determine what an unified strategy toward 
policy will look like.  I'll try to post a starting point shortly.