fix(vm-disk): report DataVolume readiness through WorkloadsReady - #4380

What this PR does

Nothing on a vm-disk application tells whether CDI ever finished populating the disk. Its WorkloadMonitor has no pods to count, and Ready follows the Helm release. So an import or clone that never completes can leave a green application over a disk nobody can use. #2908 is one way to get there: a clone into a StorageClass that cannot place a replica where the source data sits. The expensive part there was the silence, not the stuck clone.

The disk state was in the DataVolume phase all along, and nothing read it. With this change the WorkloadMonitor in cozystack-controller reads it. The monitor lists the DataVolumes its selector matches and reports not operational while any of them is in flight, Failed, Unknown or has no phase. An upload counts as in flight until it completes. That surfaces on the application as WorkloadsReady=False with reason DataVolumeNotReady and a message that names the DataVolume and its phase, for example DataVolume vm-disk-x is ImportInProgress.

Ready still follows the HelmRelease, as for any other kind (convertHelmReleaseToApplication in pkg/registry/apps/application/rest.go), and for a vm-disk it no longer waits on the DataVolume at all. So the disk state has to be visible outside Ready, and this PR puts it where operators look by default:

• kubectl get on any application kind gets a WORKLOADS column next to READY. It shows the WorkloadsReady status, or <none> when the application has no WorkloadMonitor.
• The console badge turns amber and reads DataVolumeNotReady while Ready is True and WorkloadsReady is not True for that reason. A failing Ready still wins. The console shows only the disk case: other kinds need a separate decision, because a stopped VM legitimately has no pod and reports WorkloadsReady=False too.

A Helm readiness gate on the DataVolume would be the obvious alternative, and it is not used on purpose. helm-controller runs that wait inside its reconcile, so an importing disk would hold one of the shard's worker slots for the whole install window, and a disk stuck for good would keep taking the slot back. #4145 has the details. The monitor costs no slot, keeps watching after install, and covers existing disks without anyone writing to them.

Without any gate, the install would still wait on the DataVolume. helm-controller's default poller falls back to a resource's Ready condition for kinds it has no rule for (checkReadyCondition in fluxcd/cli-utils pkg/kstatus/status/status.go), so a vm-disk install could hold a worker slot for the whole install timeout. The ApplicationDefinition therefore gets a healthCheckExprs entry for DataVolume with current: "true", the same idiom postgres-rd uses for its ScaledObject. With it Helm never waits on the DataVolume. The entry is pinned by a helm-unittest in packages/system/vm-disk-rd, which gets a test target for it.

Release settings reach a HelmRelease only when the application is created or updated, so an existing disk gets the entry on its next update. The reconciler that syncs definitions onto existing releases copies chartRef, valuesFrom and labels only. That affects any kind with release settings, so it is filed as #4409 and not fixed here. WorkloadsReady covers every disk right away, since the monitor needs no write to the application.

CDI copies the DataVolume labels onto the PVC it creates and makes the DataVolume its controller, so the monitor also publishes a pvc-<name> Workload for the disk. That Workload reads not operational while its DataVolume is not ready, even though the PVC is already Bound, so kubectl get workloads agrees with WorkloadsReady. While the DataVolumes cannot be read it keeps the verdict it has, like the monitor.

The WorkloadMonitor CRD now requires at least one selector label. An empty selector would match every Pod, PVC, Service and DataVolume in the namespace. No chart renders one.

When an application has several monitors that are not operational and only some of them name a cause, WorkloadsReady carries the named messages and reason only. A vm-disk has one monitor, so it does not hit this.

Which phases count as ready

Settled phases pass: Succeeded, PendingPopulation, WaitForFirstConsumer, Paused. A disk with bindImmediately: false on a WaitForFirstConsumer class rests in PendingPopulation or WaitForFirstConsumer until a VM consumes it. A multi-stage import rests in Paused until its next checkpoint, and the vm-disk chart renders no checkpoint source. These report ready while holding no data, because that is where such a disk is supposed to sit.

UploadReady is not one of them. CDI enters it when the upload server pod is running and ready, and leaves it for Succeeded only when that pod succeeds (updateStatusPhase in pkg/controller/datavolume/upload-controller.go at v1.66.1), so the one phase covers a disk nobody has uploaded to and a half-uploaded one. A source: upload disk therefore reports WorkloadsReady=False from creation until virtctl image-upload completes.

A phase the controller does not know also reads as ready, so a CDI release that adds or renames a phase cannot turn working disks red. The cost goes the other way: a renamed in-flight phase silently reads as settled. The list wants a re-read whenever the CDI version moves. It matches the named phases of the CDI v1.66.1 API, the version vendored in packages/system/kubevirt-cdi-operator.

Clusters without CDI

CDI comes with the IaaS bundle, while cozystack-controller runs everywhere, and CDI can be installed while the controller is running. A watch on a kind whose CRD is absent never syncs, and then the whole controller does not start. So the watch is not set up at startup. A runnable adds the DataVolume watch once the kind is served. It waits for the first reconcile, because only from then on does a new watch start at once, and then checks discovery right away and every 30s after that. It installs the DataVolume reader only after the DataVolume informer has synced within a timeout, because a reconcile context has no deadline and a List on an informer that never syncs would block every WorkloadMonitor reconcile. The watch source is started once: a controller-runtime Kind source adds an event handler to the informer and never removes it, so on a timeout the next check waits on the source it already has instead of starting another one. RBAC needs no change: the controller's ClusterRole already has read on everything.

When the DataVolumes cannot be read, because the reader is not installed yet or the List fails, the monitor still publishes its replica counts and keeps its last DataVolume verdict, and a List error is returned so the request is retried and recorded as a DataVolumesUnavailable Warning event on the monitor. The status of a monitor without DataVolumes is not affected by a failing List. A disk whose verdict is already recorded does not read as ready in the window after a controller restart. A monitor with no recorded verdict yet, which is every monitor right after the upgrade that brings this change and any disk created right after a restart, reads ready until the DataVolume watch has synced. Because the watch starts on the first reconcile rather than on the next discovery tick, that window is the time to sync the DataVolume informer plus at most one 5s requeue, not a 30s poll interval. The window is not zero, since a monitor reconciled in it is published before its DataVolumes can be read. From then on, a reconcile that runs before the watch has synced is requeued after a few seconds, so the DataVolume events that queue it are not lost. A pass that changes nothing in the monitor status does not write it, so that requeue sends no status writes to the API server. Once the reader is installed, every monitor that holds a DataVolume verdict is queued once more. So a verdict whose DataVolume was deleted while the controller was down is recomputed then, not at the periodic resync.

Tests

The table test in workloadmonitor_controller_test.go covers the named phases of CDI v1.66.1, plus Failed, Unknown, an empty phase and a missing status. A second table checks the message and reason for an importing, a failed, a phaseless and a populated disk, and a third test lists two stuck DataVolumes in both orders and expects one message. It also covers a DataVolume outside the selector, the kind not being served, a List error that still publishes the replica counts, and a missing reader that keeps the last verdict. The watch tests check that the watch starts on the first reconcile and not before it. A source that never syncs leaves no reader and is retried on the same source, with the reconciles in between still requeued. A List failure records the Warning event, the sync window records none, and an unchanged pass writes no status. A manager that stops during the wait gets the cancellation back, and a reconcile that runs while the watch syncs is requeued without an error. A table test covers the PVC Workload: importing, populated, a PVC with no DataVolume controller or a controller of another kind or group, and the unread cases. A helm-unittest in packages/system/cozystack-controller pins the selector's minProperties. rest_table_test.go pins the WORKLOADS column, rest_workloads_test.go the condition message and reason, and status.test.ts the console badge, including a halted VM that stays green.

In hack/e2e-chainsaw/vminstance the existing VMDisk scenarios now wait for the DataVolume to be Ready, then for Ready and WorkloadsReady on the VMDisk itself. That replaces the wait on the HelmRelease. Those asserts would pass even if the monitor ignored DataVolumes, so a new scenario imports from an .invalid URL. It first waits for the importer to have failed, which CDI reports on the DataVolume as Running=False with reason Error, and then for Ready=True with WorkloadsReady=False and reason DataVolumeNotReady on the VMDisk. Without the first wait the VMDisk assert passed in about a second, on a DataVolume that had no phase yet. The e2e runs on a fresh install only, so nothing here exercises an existing release across an upgrade.

What it does not do

#2908 lists possible fix directions, and none of them is here. The cross-class clone still never completes, it just stops being invisible. Keep the issue open.

While the DataVolume watch syncs, every monitor is still requeued. Only the ones whose selector reaches a DataVolume need it, but the controller cannot tell which those are before it can read DataVolumes.

Closes #4449

Screenshots

There is no screenshot: I had no running console to take one from. The badge change is pinned by the vitest cases in packages/system/dashboard/images/console/apps/console/src/lib/status.test.ts: a VMDisk whose WorkloadsReady has reason DataVolumeNotReady goes amber, and a halted VMInstance with the generic reason stays green.

Downstream repositories

I walked the trigger map against the diff. cozystack/terraform-provider-cozystack is affected: its wait_for_ready reads only Ready, so on a cozystack_vmdisk it returns before the disk is populated once this lands. That needs a decision on the provider side, so it is an issue there. The release-time bot regenerates packages/apps/vm-disk/README.md into the website's virtualization pages, and vm-disk is in the VMS list that generator reads, so the website needs no follow-up. The ApplicationDefinition keeps its kind, plural, prefix and path.

• No downstream repository is affected by this change
• cozystack/website - follow-up:
• cozystack/terraform-provider-cozystack - follow-up: wait_for_ready on cozystack_vmdisk returns before the disk is populated terraform-provider-cozystack#59
• cozystack/ansible-cozystack - follow-up:
• cozystack/ccp - follow-up:
• cozystack/talm - follow-up:
• cozystack/cozyhr - follow-up:
• cozystack/cozy-proxy - follow-up:
• cozystack/cozystack-telemetry-server - follow-up:
• cozystack/external-apps-example - follow-up:
• cozystack/examples - follow-up:
• cozystack/community - follow-up:

Release note

fix(vm-disk): report whether CDI finished populating a disk in the WorkloadsReady condition, which names the stuck DataVolume and its phase. kubectl get shows WorkloadsReady in a new WORKLOADS column for every application kind, and the console badge turns amber while a disk is not populated, so a disk whose import or clone never completes no longer looks healthy. Ready of a new or updated vm-disk no longer waits for the DataVolume, so wait on WorkloadsReady to know the disk is populated.