No test checks that a volume attached only to a running VMI stays attached when the platform moves to declarative volume hotplug. That move happens in #4453, which turns off the KubeVirt HotplugVolumes gate and so switches DeclarativeHotplugVolumes on. On its first reconcile virt-controller removes every hotpluggable VMI volume that VM.spec does not list. Migration 59 in that PR copies such volumes into VM.spec before the gate changes, so a tenant node whose disk an older kubevirt-csi attached at the VMI level keeps it.
The only coverage today is unit level. The migration has bats tests against a fake kubectl. No CI lane upgrades from the previous release, because every chainsaw suite installs the tree's own version. The upgrade lane in #3276 is not merged yet, and it does not cover this case either.
The test I have in mind:
- Install the previous release and start a VM.
- Hot-plug a volume through the VMI
addvolume subresource, for example with an older virtctl and no --persist, and write data to it.
- Upgrade.
- Check that the volume is still attached, the data is readable, the VM is not
RestartRequired, and the migration stamp advanced.
A kubevirt-csi detach on a tenant cluster after the upgrade belongs in the same test. After the upgrade the CSI controller runs with --enable-vmi-hotplug-fallback=false, and nothing exercises that path on a real cluster yet.
This fits the upgrade lane once it lands (Track B of #2847). Until then the check is manual.
No test checks that a volume attached only to a running VMI stays attached when the platform moves to declarative volume hotplug. That move happens in #4453, which turns off the KubeVirt
HotplugVolumesgate and so switchesDeclarativeHotplugVolumeson. On its first reconcile virt-controller removes every hotpluggable VMI volume thatVM.specdoes not list. Migration 59 in that PR copies such volumes intoVM.specbefore the gate changes, so a tenant node whose disk an older kubevirt-csi attached at the VMI level keeps it.The only coverage today is unit level. The migration has bats tests against a fake kubectl. No CI lane upgrades from the previous release, because every chainsaw suite installs the tree's own version. The upgrade lane in #3276 is not merged yet, and it does not cover this case either.
The test I have in mind:
addvolumesubresource, for example with an older virtctl and no--persist, and write data to it.RestartRequired, and the migration stamp advanced.A kubevirt-csi detach on a tenant cluster after the upgrade belongs in the same test. After the upgrade the CSI controller runs with
--enable-vmi-hotplug-fallback=false, and nothing exercises that path on a real cluster yet.This fits the upgrade lane once it lands (Track B of #2847). Until then the check is manual.