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 }}
Repository navigation
kubevirt-csi wrapper unpublishHotplugVolume is a stale backport of kubevirt/csi-driver#184 #4450
The kubevirt-csi wrapper still carries its own hot-unplug path, and it looks like upstream now does the same job. The comment on unpublishHotplugVolume in packages/apps/kubernetes/images/kubevirt-csi-driver/controller.go calls it a backport of kubevirt/csi-driver#184. It says to drop it once that PR merges and the module is bumped past it. Both conditions are met: #184 merged on 2026-06-24, and the pinned module has contained it since then.
Upstream ControllerUnpublishVolume checks the VM spec and the VMI hotplug status before it detaches. When the VM is gone it falls back to the VMI-level removevolume. Then it polls EnsureVolumeRemoved until the VMI status no longer lists the volume. So when upstream returns success, the wrapper's re-read of the VMI should not find the volume. Its own RemoveVolumeFromVMI and second wait only run if the volume shows up again between the two reads.
I haven't proven it is dead code, so this needs a behaviour diff against upstream at the current pin first. After that, either delete the override and keep the NFS branch of ControllerUnpublishVolume, or rewrite the comment to say what the wrapper still adds. Deleting it also removes the wrapper's copy of ownedByVirtualMachine, which exists only to honour --enable-vmi-hotplug-fallback there.
Activity
feat(kubernetes): let kubevirt-csi detach without the HotplugVolumes …