-
Epic
-
Resolution: Unresolved
-
Normal
-
None
-
None
Goal
Since webhooks are racy and fragile, feature gate validation should not depend on them
User Stories
- As a VM owner I would like to see my VM report a clear condition in case it requests a feature that is currently gated out.
- As a cluster admin, I would like to turn OpenShift Virtualization feature gates on and off whenever I see this fit, regardless if VMs using this feature are currently define or running. I expect such VMs to report a clear condition and eventually stop.
- As a software architect, I would like to limit the usage of webhooks. Validations must take place in a reconcile loop and reported in VM status. In rare cases when there is a clear benefit for users, quick-though-racy feedback from webhook is acceptable. Yet nothing should depend on it succeeding.
Non-Requirements
- List of things not included in this epic, to alleviate any doubt raised during the grooming process.
Notes
- The issue was raised and discussed in https://groups.google.com/g/kubevirt-dev/c/D9fKloOKGzk/m/xoULML5nAAAJ . This epic tracks Red Hat's opinion on the matter.
- Webhooks should be frown upon https://docs.google.com/presentation/d/1LkR_8nMhWD9QU-mnYnLLFP9wl4DP2TlyJfUhWf-5ZD8/
Race Condition Example
- VM owner starts a VM that requires feature X
- Webhook ensures that feature X is enabled
- Cluster admin disables feature
- VMI starts with feature X despite it being disabled.