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.
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
