Open Stack

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.