You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the feature you'd like to have.
Add a Validating Webhook to improve the validity checking of the SnapshotSchedule CR.
What is the value to the end user? (why is it a priority?)
The current openapi validation handles some validation, but not all field validation can be adequately expressed using openapi. Errors currently missed by openapi validation will only be discovered after the operator tries to reconcile, with error reporting limited to the .status field of the affected CR.
By adding a validating webhook, more (all?) errors can be found when the object is first created, so the create/update can be immediately rejected, providing more timely feedback to the user. This will also improve error reporting capabilities via the web console.
How will we know we have a good solution? (acceptance criteria)
.spec.schedule should be validated by parsing it to ensure it's a valid cronspec (i.e., all values are in range)
.spec.retention.expires should properly parse as a time.Duration
Additional context
This should be viewed as an enhancement on top of the openapi validation, not a substitute. The openapi validation should still be the first line of defense since those rules are exposed in the CRD, whereas the webhook's rules are opaque to the user.
Describe the feature you'd like to have.
Add a Validating Webhook to improve the validity checking of the SnapshotSchedule CR.
What is the value to the end user? (why is it a priority?)
The current openapi validation handles some validation, but not all field validation can be adequately expressed using openapi. Errors currently missed by openapi validation will only be discovered after the operator tries to reconcile, with error reporting limited to the
.status
field of the affected CR.By adding a validating webhook, more (all?) errors can be found when the object is first created, so the create/update can be immediately rejected, providing more timely feedback to the user. This will also improve error reporting capabilities via the web console.
How will we know we have a good solution? (acceptance criteria)
.spec.schedule
should be validated by parsing it to ensure it's a valid cronspec (i.e., all values are in range).spec.retention.expires
should properly parse as atime.Duration
Additional context
This should be viewed as an enhancement on top of the openapi validation, not a substitute. The openapi validation should still be the first line of defense since those rules are exposed in the CRD, whereas the webhook's rules are opaque to the user.
Starting point (from this tutorial at KubeConNA 2019):
https://github.com/jpbetz/KoT/tree/master/admission
The text was updated successfully, but these errors were encountered: