[openstack-dev] Dynamic Policy for Access Control Subteam Meeting

Adam Young ayoung at redhat.com
Thu Jun 4 19:00:33 UTC 2015

On 06/04/2015 01:16 PM, Sean Dague wrote:
> It gets overwritten by the central store.
> And you are wrong, that gives me what I want, because we can emit a
> WARNING in the logs if the patch is something crazy. The operators will
> see it, and be able to fix it later.
> I'm not trying to prevent people from changing their policy in crazy
> ways. I'm trying to build in some safety net where we can detect it's
> kind of a bad idea and emit that information a place that Operators can
> see and sort out later, instead of pulling their hair out.
> But you can only do that if you have encoded what's the default, plus
> annotations about ways that changing the default are unwise.
When would you expect this warning to be emitted, and to whom?  I think 
you have the right idea, but I suggest that the appropriate time to give 
that warning would be back when the policy is written, which would be 
under the scope of the Database-Driven policy management.  I would think 
that, if a user changes a policy, it would go to a staged state, not 
deployed immediately, and at that point, we'd want a check to run.  That 
check would be what told the author they did something unexpected.  
Waiting until the policy hits the server is probably too late.

More information about the OpenStack-dev mailing list