Description
I have made this comment on a few PRs so maybe it's time to document and/or build a mechanism.
You cannot generally make validation tighter, because any existing objects that violate the new rule will not be able to be updated, and in many cases, deleted (because deletions involving finalizers require a sequence of updates).
This is because, to validate updates, we validate BOTH the transition, AND the final state of the object. It's this last part that is problematic.
It should be possible to address this by adding a new class of validation function that ONLY gets called on new objects, but then we have these problems:
- When is it safe to promote the logic into the main validation function? There's no way to know.
- This solves the problem for apiserver, but not for any clients that were sending invalid objects. Especially automated clients will suddenly and without recourse be quite broken.
Even at version boundaries it's hard to tighten validation, since objects have to be round-trippable and there are still old objects in the system.
So, new API authors: start out with restrictive validation; it's easier to relax than to tighten.
Existing API authors: prepare to write defensive clients.
/kind bug
/sig api-machinery
Metadata
Metadata
Assignees
Labels
Type
Projects
Status