Closed tghfly closed 5 months ago
Hey @tghfly, thanks for opening this issue.
When it comes to retaining pods, we allow it for debugging purposes and thus only allow retaining CDI transfer pods: importer, uploader, and cloner. CDI may create other pods such as the size-detection pod or the prep pod for different purposes but since they don't play an active role in the data population they are not affected by the annotation.
That said, if created, the cloner pod should be retained if the DV contains the retainAfterCompletion
annotation. This pod is only created during host-assisted clones, so in your case, another cone type is probably happening instead: For example, CSI clones don't require a CDI-managed pod. You can check the clone type used by CDI by checking the cdi.kubevirt.io/cloneTypep
annotation in the cloned DV.
For more info about clone types, you can check smart-clone, csi-clone.md and clone-datavolume.
Hope this helps!
Thanks @alromeros
What happened: Annotation: cdi.kubevirt.io/storage.pod.retainAfterCompletion set to true specifies that the CDI data transfer pod should remain intact following successful completion of the operation, but this behavior applies exclusively when the data source is an HTTP source. When the source is a PVC, even if this annotation is present, pods with names starting with 'prep-' will be automatically deleted upon successful completion, not retained.
What you expected to happen: When the source is a PVC, the pods starting with 'prep-' should be retained after completion.
How to reproduce it (as minimally and precisely as possible): The following YAML, upon execution,the pods starting with 'prep-' should be retained after completion.
The following YAML, upon execution, results in the Pod being retained after its completion.
Additional context: Add any other context about the problem here.
Environment:
kubectl get deployments cdi-deployment -o yaml
): v1.58.1kubectl version
): 1.27.6uname -a
): 5.10.0-136