kubevirt-cdi: the CDI CR enables ExpandDisks, which is a KubeVirt gate and not a CDI one #4112

packages/system/kubevirt-cdi/templates/cdi-cr.yaml:23 lists ExpandDisks under spec.config.featureGates. CDI has no gate by that name. At v1.66.1 pkg/feature-gates/feature-gates.go declares exactly three — HonorWaitForFirstConsumer, DataVolumeClaimAdoption, and WebhookPvcRendering, the last kept only so that an older CR still parses. ExpandDisks is KubeVirt's, registered there as ExpandDisksGate and GA since v1.8.0.

Nothing rejects the stray entry. isFeatureGateEnabled walks the list looking for one specific string, so a name no caller asks about is read and dropped. The CR has carried it since 2024-08-30 without a complaint from any cluster, which is what an ignored value looks like rather than evidence that it does something.

The commit that introduced it added ExpandDisks to packages/system/kubevirt/templates/kubevirt-cr.yaml in the same edit, and there it is right: that is the CR the gate is for, and disk expansion works because of that line. Only the CDI copy is misplaced.

The fix is to delete the line, and it is worth doing rather than shrugging at. Someone reading the CDI CR to find out which gates the platform turns on gets a wrong answer, and anyone later tracing why disk expansion works can credit the wrong component and then "fix" the wrong one.

Timing matters slightly. #4107 makes templates/cdi-cr.yaml explicitly hand-maintained and adds a suite over it, so after that lands the deletion has an obvious place to be pinned; doing it first would collide with that PR in the same file.