Repository navigation
VMDisk import with invalid URL stays in progress forever #4059
Description
What is wrong?
VMDisk created from HTTP URL never reaches failed state when source keeps returning an error (reproduced with HTTP 404). CDI importer exits with error, but pod uses restartPolicy: OnFailure, so kubelet restarts it without limit. DataVolume stays in ImportInProgress, and backing HelmRelease keeps timing out and retrying.
From user side disk creation stays in progress forever. Error is only visible in importer logs, and changing source in VMDisk does not update already created DataVolume because chart keeps its existing spec.
How to reproduce?
- Create VMDisk with HTTP source URL returning 404.
- Wait for importer pod to start.
- Check DataVolume, importer pod and HelmRelease status.
Importer continues to restart, DataVolume remains in ImportInProgress, and HelmRelease gets repeated action timeouts.
How it should work?
Cozystack should expose terminal failed state after bounded retries or timeout for persistent import errors. API and dashboard should show source error and provide explicit retry with corrected source, or require disk recreation with clear message.
CDI retry behavior makes sense for temporary source failures, so this issue is about import lifecycle in Cozystack, not CDI resource ownership.
Activity
lexfrei commentedon Sep 23, 2026
#4380 makes a stuck import visible through the API, but the import itself still never ends, so I'd keep this issue open for the rest.
With #4380 the vm-disk WorkloadMonitor lists the DataVolumes it selects and reports not operational while one of them is still in flight (
internal/controller/workloadmonitor_controller.go:103-130at b0ff186).ImportScheduledandImportInProgressare in that set, so a disk with a broken URL getsWorkloadsReady=Falseon the VMDisk (workloadmonitor_controller.go:866-868). The newvmdisk-unreachablee2e case checks exactly that with an.invalidURL (hack/e2e-chainsaw/vminstance/chainsaw-test.yaml:57-88). The ApplicationDefinition also stops Helm from waiting on the DataVolume (packages/system/vm-disk-rd/cozyrds/vm-disk.yaml:21-24). A new disk no longer produces the repeated HelmRelease timeouts, and an existing one picks this up on its next update.The retry loop is untouched. In CDI v1.66.1 the importer pod runs with
RestartPolicy: OnFailure(pkg/controller/import-controller.go:1036). A failed import moves the DataVolume toFailedonly when the error is marked fatal, (pkg/controller/datavolume/import-controller.go:290-295), and the only fatal case there is a checksum mismatch (pkg/controller/import-controller.go:397-407). A 404 or a DNS failure is retried forever and the DataVolume stays inImportInProgress. Nothing in #4380 puts a deadline on that from the cozystack side.The source error is still not shown anywhere. The condition message is the generic "One or more workloads are not operational" (
pkg/registry/apps/application/rest.go:1486). The dashboard reads onlyReady, andReadynow follows the HelmRelease, which succeeds. So in the UI a new disk with a broken URL will look healthy, while before it at least stayed in progress.Changing the source of an existing disk is already handled on main, outside #4380. Since 06624ba the chart fails the release on a
sourceedit and asks to delete and recreate the disk (packages/apps/vm-disk/templates/dv.yaml:44).What is left here: a terminal state for an import that keeps failing, the DataVolume error in the condition message, and a way for the dashboard to show it.
lexfrei commentedon Oct 7, 2026
#4802 fixes this for golden images only. It treats a DataVolume as stuck when it is not
Succeeded,status.restartCountis 3 or more and theRunningcondition isFalse. CDI v1.66.1 fillsrestartCountfrom the importer container restarts and setsRunning=Falsewhile the importer is down, back-off included, so a 404 or a DNS failure matches without parsing the error text.A VMDisk's own import can't be caught at render time, because the same render creates its DataVolume. The WorkloadMonitor looks like the right place:
isDataVolumeReadyininternal/controller/workloadmonitor_controller.gocould report a DataVolume matching this predicate as failed instead of in flight, and pass theRunningmessage into the VMDisk condition.