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.