+++ This bug was initially created as a clone of Bug #2101954 +++ Description of problem: Smart-clone and CSI clone across namespace leaves orphan unbound PVC in source namespace. Also, the corresponding ObjectTransfer resource is not deleted until the target DataVolume is deleted. This issue was originally submitted in github here: https://github.com/kubevirt/containerized-data-importer/issues/2323 Version-Release number of selected component (if applicable): How reproducible: 100% Steps to Reproduce: 1. Create DataVolume in namespace A populated by http import 2. Clone above DataVolume to Namespace B Actual results: There is a tmp unbound PVC in namespace A There is completed ObjectTransfer Expected results: No unexpected resources Additional info: https://github.com/kubevirt/containerized-data-importer/issues/2323
This is not an issue in 4.10
Close the bug according #Comment 1
Hi, Michael we can reproduce the bug on CNV-v4.10.3 and CNV-v4.10.4-12 $ oc get pvc NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE cdi-tmp-1535a93c-e982-4b18-93ef-181a59e5372a Pending ocs-storagecluster-ceph-rbd 14s golden-centos-dv Bound pvc-fd2b1f41-d1c1-4e27-bab1-06091c10b416 10Gi RWO ocs-storagecluster-ceph-rbd 3m54s I think we may need to backport to 4.10.z
Also tried on CNV-v4.9.6-27, issue can not be reproduced.
Interesting! Is the ObjectTransfer left around as well?
Yes: $ oc get ObjectTransfer NAME AGE PHASE cdi-tmp-b4c6699c-b517-4529-9785-11f04db7ab77 8h Complete
I see now, the issue was not originally in 4.10 but the bug was backported to it
*** Bug 2128243 has been marked as a duplicate of this bug. ***
Michael, do you plan to fix it in 4.10.6?
Fix was merged: https://github.com/kubevirt/containerized-data-importer/pull/2415
Version-Release number of selected component (if applicable): CNV-v4.10.6-9 Steps to Reproduce: 1. Create a datavolume with a source url in A namespace, and the yaml file is below: apiVersion: cdi.kubevirt.io/v1beta1 kind: DataVolume metadata: name: golden-centos-dv namespace: fuhui spec: source: http: url: "http://cloud.centos.org/centos/7/images/CentOS-7-x86_64-GenericCloud.qcow2" pvc: storageClassName: ocs-storagecluster-ceph-rbd volumeMode: Block accessModes: - ReadWriteOnce resources: requests: storage: 10Gi 2. Verify the status of dv & pvc: [cnv-qe-jenkins@n-yoss-410-flwdp-executor ~]$ oc get dv NAME PHASE PROGRESS RESTARTS AGE golden-centos-dv Succeeded 100.0% 4m7s [cnv-qe-jenkins@n-yoss-410-flwdp-executor ~]$ oc get pvc NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE golden-centos-dv Bound pvc-d86232a8-c0fa-435c-80ba-d73f0d518b27 10Gi RWO ocs-storagecluster-ceph-rbd 4m10s 3. Clone this dv into B namespace, the yaml file is below: apiVersion: cdi.kubevirt.io/v1beta1 kind: DataVolume metadata: name: clone-centos-dv-customer1 namespace: test spec: source: pvc: namespace: fuhui name: golden-centos-dv pvc: storageClassName: ocs-storagecluster-ceph-rbd volumeMode: Block accessModes: - ReadWriteOnce resources: requests: storage: 10Gi 4. Verify the DV & PVC & ObjectTransfer in A and B namespace: [cnv-qe-jenkins@n-yoss-410-flwdp-executor ~]$ oc get dv NAME PHASE PROGRESS RESTARTS AGE clone-centos-dv-customer1 Succeeded N/A 17s [cnv-qe-jenkins@n-yoss-410-flwdp-executor ~]$ oc get pvc NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE clone-centos-dv-customer1 Bound pvc-e0d3d009-b8dc-4fc6-9801-6f48d2234e9a 10Gi RWO ocs-storagecluster-ceph-rbd 12s [cnv-qe-jenkins@n-yoss-410-flwdp-executor ~]$ oc get pvc -n fuhui NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE golden-centos-dv Bound pvc-d86232a8-c0fa-435c-80ba-d73f0d518b27 10Gi RWO ocs-storagecluster-ceph-rbd 25m [cnv-qe-jenkins@n-yoss-410-flwdp-executor ~]$ oc get objecttransfer No resources found
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (OpenShift Virtualization 4.10.6 Images), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2022:7179