#4380 was approved with four follow-up notes on the DataVolume readiness in WorkloadMonitor. They are not blocking, so they land here instead of in that PR. Review:
A watch that keeps missing its sync leaves an event handler on the DataVolume informer each time. Every attempt builds a fresh source.Kind and calls Watch; controller-runtime v0.23.1 adds the handler and never removes it, and the startCancel() that WaitForSync calls on timeout only cancels its context. It needs the DataVolume informer to sync while the wait on the whole manager cache misses the timeout, so it is narrow, but it accumulates.
A DataVolume read failure leaves no trace on the object. The monitor keeps its last verdict and returns the error for a retry, and the only signal is a log line. A monitor with no verdict yet reads operational while its disks are unreadable. The same file already records a Warning event for the bucket metrics case, and the same call, or a Reason held while the read fails, would make it visible.
The new WORKLOADS column and the disk's own Workload can disagree. CDI copies DataVolume labels onto the PVC, so the monitor also publishes a pvc-<name> Workload whose readiness is bind state alone. Mid-import that Workload reads operational while WorkloadsReady is False with DataVolumeNotReady.
The sync window requeues every monitor of every kind every 5s, and each pass writes status unconditionally. If the DataVolume kind is served but cannot be listed, the window repeats (60s sync wait, 30s poll gap), so a cluster with many monitors gets a steady stream of status writes. Skipping the write when nothing changed, or scoping the requeue to monitors that can match DataVolumes, would bound it.
Also from the same review: a WorkloadMonitor with selector: {} would select every DataVolume in its namespace. No chart renders one, but the CRD does not forbid it (selector is required without minProperties).
#4380 was approved with four follow-up notes on the DataVolume readiness in WorkloadMonitor. They are not blocking, so they land here instead of in that PR. Review:
A watch that keeps missing its sync leaves an event handler on the DataVolume informer each time. Every attempt builds a fresh
source.Kindand callsWatch; controller-runtime v0.23.1 adds the handler and never removes it, and thestartCancel()thatWaitForSynccalls on timeout only cancels its context. It needs the DataVolume informer to sync while the wait on the whole manager cache misses the timeout, so it is narrow, but it accumulates.A DataVolume read failure leaves no trace on the object. The monitor keeps its last verdict and returns the error for a retry, and the only signal is a log line. A monitor with no verdict yet reads operational while its disks are unreadable. The same file already records a Warning event for the bucket metrics case, and the same call, or a
Reasonheld while the read fails, would make it visible.The new WORKLOADS column and the disk's own Workload can disagree. CDI copies DataVolume labels onto the PVC, so the monitor also publishes a
pvc-<name>Workload whose readiness is bind state alone. Mid-import that Workload reads operational whileWorkloadsReadyis False withDataVolumeNotReady.The sync window requeues every monitor of every kind every 5s, and each pass writes status unconditionally. If the DataVolume kind is served but cannot be listed, the window repeats (60s sync wait, 30s poll gap), so a cluster with many monitors gets a steady stream of status writes. Skipping the write when nothing changed, or scoping the requeue to monitors that can match DataVolumes, would bound it.
Also from the same review: a WorkloadMonitor with
selector: {}would select every DataVolume in its namespace. No chart renders one, but the CRD does not forbid it (selectoris required withoutminProperties).