[KEP-5073] Update KEP with section of validation ratcheting #5292
Conversation
yongruilin
commented
May 8, 2025
yongruilin
commented
- One-line PR description: This PR updates the KEP about how we intend to handle validation ratcheting with Declarative Validation.
- Issue link: Declarative Validation Of Kubernetes Native Types With validation-gen #5073
|
Skipping CI for Draft Pull Request. |
k8s-ci-robot
added
do-not-merge/work-in-progress
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: yongruilin The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
k8s-ci-robot
added
the
size/M
k8s-ci-robot
removed
the
do-not-merge/work-in-progress
yongruilin
force-pushed
the
ratcheting
branch
2 times, most recently
from
912ee4e to
34dae9a
Compare
| | Struct fields<br/>`structType=atomic` | - | revalidate changed fields | [Issue #131566](https://github.com/kubernetes/kubernetes/issues/131566) (Alignment needed) | | ||
| | Slices | all elements are equivalent and the is order unchanged | revalidate the slice if any element changed or order changed | `listType=map`: no validate when re-order<br/>`listType=set`: re-validate when re-order<br/>`listType=atomic`: re-validate when re-order | | ||
| | Slice values<br/>`listType=atomic` | - | validate items which are not found (by value) in the old slice | Validate all elements (CRDs ratcheting may be expanded to match in-tree ratcheting) | | ||
| | Slice values<br/>`listType=map` | - | (re)validate items which are not found (by key) in the old slice or are changed | same | |
There was a problem hiding this comment.
if order of a slice that is a map changes, but all the keys and values are the same, do we skip validation? I would expect us to skip.
There was a problem hiding this comment.
it would skip for the validation on the individual element. But should we still validate the listmap as a whole? If it is declared with "immutable", we consider the order as part of the API and validate the order?
| A challenge arises if a cross-field validation rule (e.g. `X < Y`) is defined on a common ancestor struct, and an unrelated field (e.g. `Z`) within that same ancestor is modified. This change to `Z` makes the common ancestor “changed” overall, triggering re-validation of the `X < Y` rule. If this rule was recently evolved (e.g., made stricter), it might now fail even if `X` and `Y` themselves are not modified by the user’s update. This could violate the principle “Unchanged fields do not cause update rejections.” | ||
|
|
||
| For the initial implementation, this behavior will be documented. Furthermore, cross-field validation rules themselves must incorporate internal ratcheting logic. For instance, generated code for dedicated cross-field tags (like `+k8s:unionMember`) will be designed to only act upon changes to the specific fields they govern and were designed to validate. |
There was a problem hiding this comment.
Please build us an example as soon as we have enough merged so we can see how painful (or not) it seems to be.
