CDI is unable to schedule an import because the target PVC is acted upon by multiple controllers, causing it to transition directly to Bound instead of ImportScheduled

[rporanki]

What happened:
A DataVolume created by DataVolume template in vm.yaml spec has transitioned quickly into Bound State instead of ImportScheduled state when multiple controllers act simultaneously on the PVC created by DataVolume.

What you expected to happen:
CDI deployment operator must retry and reconcile so that PVC/DataVolume moves into ImportSchedule state even when multiple controllers act on the PVC managed by CDI.

How to reproduce it (as minimally and precisely as possible):

1. create a vm.yaml with DataVolumeTemplate
2. This would created a DataVolume backed by PVC
3. As soon as the PVC created another custom operator modifies/adds a custom annotiation to the PVC
4. Now CDI logs the below error message
   "error":"Operation cannot be fulfilled on datavolumes.cdi.kubevirt.io ... the object has been modified; please apply your changes to the latest version and try again"
5. Finally PVC quickly transitioned into Bound state instead of ImportScheduled state.

Additional context:
Add any other context about the problem here.

Environment:

• CDI version (use kubectl get deployments cdi-deployment -o yaml): v1.63.1
• Kubernetes version (use kubectl version): 1.3.0
• DV specification:

• Cloud provider or hardware configuration: N/A
• OS (e.g. from /etc/os-release): N/A
• Kernel (e.g. uname -a): N/A
• Install tools: N/A
• Others: N/A

[rporanki]

When the PVC is modified concurrently by multiple controllers, the corresponding DataVolume is reconciled multiple times in parallel.

During reconciliation, CDI attempts to update the DataVolume status subresource:

r.client.Status().Update(ctx, dataVolumeCopy)

However, because another controller has already modified the DataVolume (or triggered a status update via PVC binding), the resourceVersion becomes stale, causing the status update to fail with a conflict error.

{"level":"error","ts":"2026-01-27T04:47:19Z","logger":"controller.datavolume-import-controller","msg":"unable to update datavolume status","name":"litmusedge-vm-datavolume-2-1-0","error":"Operation cannot be fulfilled on datavolumes.cdi.kubevirt.io "xxxxxx": the object has been modified; please apply your changes to the latest version and try again","stacktrace":"kubevirt.io/containerized-data-importer/pkg/controller/datavolume.(*ReconcilerBase).emitEvent\n\tpkg/controller/datavolume/controller-base.go:1085\nkubevirt.io/containerized-data-importer/pkg/controller/datavolume.(*ReconcilerBase).updateStatus\n\tpkg/controller/datavolume/controller-base.go:982\nkubevirt.io/containerized-data-importer/pkg/controller/datavolume.(*ReconcilerBase).reconcile\n\tpkg/controller/datavolume/controller-base.go:466\nkubevirt.io/containerized-data-importer/pkg/controller/datavolume.(*ImportReconciler).Reconcile\n\tpkg/controller/datavolume/import-controller.go:184\nkubevirt.io/containerized-data-importer/vendor/sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller[...]).Reconcile\n\tvendor/sigs.k8s.io/controller-runtime/pkg/internal/controller/controller.go:116\nkubevirt.io/containerized-data-importer/vendor/sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller[...]).reconcileHandler\n\tvendor/sigs.k8s.io/controller-runtime/pkg/internal/controller/controller.go:303\nkubevirt.io/containerized-data-importer/vendor/sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller[...]).processNextWorkItem\n\tvendor/sigs.k8s.io/controller-runtime/pkg/internal/controller/controller.go:263\nkubevirt.io/containerized-data-importer/vendor/sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller[...]).Start.func2.2\n\tvendor/sigs.k8s.io/controller-runtime/pkg/internal/controller/controller.go:224"}

[mhenriks]

@rporanki thanks for the report.

Switching from updateStatus to status().patch() may reduce conflicts. And that is something we can consider implementing.

However, even if conflicts are eliminated, given the asynchronous nature of Kubernetes controllers, there is no way to guarantee that ImportScheduled ever gets reported. So please take that into consideration.

[akalenyu]

So apparently the issue here is that the entire operation doesn't converge to succeeded at all, not just missing importscheduled.. we're chatting on slack trying to figure it out.

[akalenyu]

/reopen

@rporanki please keep us updated about whether this ended up being the underlying issue. as we discussed offline, we suspect an entirely different issue where datasource/ref gets lost post external entity doing pvc mutation

[kubevirt-bot]

@akalenyu: Reopened this issue.

Details

In response to this:

/reopen

@rporanki please keep us updated about whether this ended up being the underlying issue. as we discussed offline, we suspect an entirely different issue where datasource/ref gets lost post external entity doing pvc mutation

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[rporanki]

@akalenyu thanks, will update as soon as I have an update.