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
{{ message }}
This repository was archived by the owner on Jun 21, 2026. It is now read-only.
It's fairly common for operators to perform some additional validation of their "parent" resources on top of what can be done in the schema attached to the CRD. Given that they're already doing this validation anyway, it can be desirable to validate the parent resources before allowing them to be modified. Kubernetes has supported this for a while now, in the form of Validating Admission Webhooks. The goal is to add optional configuration that would allow roperator to setup a new http route for validating admission webhooks.
If enabled, users would be expected to pass some sort of validation function that would accept a &ValidationRequest struct (which would include the fields described here) and would return a ValidationResponse (which would include these fields).
This feature would not change the current behavior of the operator at all, and would be totally optional. We also could not guarantee that the webhook would be called, or even respected, so we still wouldn't want to make any assumptions about the parent resources in a SyncRequest.
It's fairly common for operators to perform some additional validation of their "parent" resources on top of what can be done in the schema attached to the CRD. Given that they're already doing this validation anyway, it can be desirable to validate the parent resources before allowing them to be modified. Kubernetes has supported this for a while now, in the form of Validating Admission Webhooks. The goal is to add optional configuration that would allow roperator to setup a new http route for validating admission webhooks.
If enabled, users would be expected to pass some sort of validation function that would accept a
&ValidationRequeststruct (which would include the fields described here) and would return aValidationResponse(which would include these fields).This feature would not change the current behavior of the operator at all, and would be totally optional. We also could not guarantee that the webhook would be called, or even respected, so we still wouldn't want to make any assumptions about the parent resources in a
SyncRequest.