+++ This bug was initially created as a clone of Bug #2152537 +++

Description of problem:
Better to have a more friendly error when missing storage size in clone

Version-Release number of selected component (if applicable):
CNV 4.12

How reproducible:
Always

Steps to Reproduce:
1. Clone from a pvc without setting storage size in DataVolume.spec.storage.resources

—
apiVersion: cdi.kubevirt.io/v1beta1
kind: DataVolume
metadata:
name: clone4
annotations:
cdi.kubevirt.io/cloneType: ""
cdi.kubevirt.io/storage.bind.immediate.requested: "true"
cdi.kubevirt.io/storage.deleteAfterCompletion: "false"
spec:
source:
pvc:
name: fedora-56ccabc01cbe
namespace: openshift-virtualization-os-images
storage:
resources: {}

Actual results:
1. The DV keeps in CloneScheduled status, no progress
2. Describe the dv, only got warning "The size detection pod is not finished yet"
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal SizeDetectionPodCreated 4m44s datavolume-controller Size-detection pod created
Normal CloneScheduled 4m44s datavolume-controller Cloning from openshift-virtualization-os-images/fedora-56ccabc01cbe into default/clone4 scheduled
Normal CloneScheduled 4m44s datavolume-controller No PVC found
Normal SizeDetectionPodNotReady 4m42s (x11 over 4m44s) datavolume-controller The size detection pod is not finished yet
Warning HostAssistedCloneSourceInUse 4m42s (x11 over 4m44s) datavolume-controller pod openshift-virtualization-os-images/size-detection-ae130582-c792-4677-86dd-f78c8c243ee8 using PersistentVolumeClaim fedora-56ccabc01cbe

cdi deployment pod log:
{"level":"debug","ts":1670816776.3534229,"logger":"events","msg":"Normal","object":

{"kind":"DataVolume","namespace":"default","name":"clone4","uid":"349bdb29-09e6-4a0a-9ade-ee4ac4582ade","apiVersion":"cdi.kubevirt.io/v1beta1","resourceVersion":"10785711"}

,"reason":"SizeDetectionPodNotReady","message":"The size detection pod is not finished yet"}
{"level":"debug","ts":1670816776.3534684,"logger":"events","msg":"Warning","object":

{"kind":"DataVolume","namespace":"default","name":"clone4","uid":"349bdb29-09e6-4a0a-9ade-ee4ac4582ade","apiVersion":"cdi.kubevirt.io/v1beta1","resourceVersion":"10785711"}

,"reason":"HostAssistedCloneSourceInUse","message":"pod openshift-virtualization-os-images/size-detection-ae130582-c792-4677-86dd-f78c8c243ee8 using PersistentVolumeClaim fedora-56ccabc01cbe"}

Expected results:
Better to have a more friendly error when missing storage size in clone
such as: missing storage size in DataVolume

Additional info:

— Additional comment from Red Hat Bugzilla on 2022-12-15 08:29:09 UTC —

Account disabled by LDAP Audit for extended failure

— Additional comment from Álvaro Romero on 2022-12-21 09:36:38 UTC —

Hi @yadu@redhat.com! I'm taking a look at this but everything seems to be working as expected.

We support creating clones without size: When a clone without storage size is created, we run a binary inside a 'size-detection' pod that checks the image size of the source and uses it in the target. You can check this in the events:

Type Reason Age From Message
---- ------ ---- ---- -------
Normal SizeDetectionPodCreated 4m44s datavolume-controller Size-detection pod created
Normal SizeDetectionPodNotReady 4m42s (x11 over 4m44s) datavolume-controller The size detection pod is not finished yet

The other events are also expected behavior, so everything implies that the clone will be successful. Is the DV frozen in CloneScheduled?

— Additional comment from Yan Du on 2022-12-22 06:00:48 UTC —

Hi, Alvaro

Yes, the DV keeps in CloneScheduled.
$ oc get dv
NAME PHASE PROGRESS RESTARTS AGE
clone4 CloneScheduled 23m

The dv yaml and describe log is in attachment.

— Additional comment from Yan Du on 2022-12-22 06:01:25 UTC —

— Additional comment from Álvaro Romero on 2022-12-22 09:12:17 UTC —

You are right @yadu@redhat.com, there seems to be a problem when using the size-detection pod in clones between different namespaces. I'll investigate it.

— Additional comment from Álvaro Romero on 2023-01-13 12:28:42 UTC —

Hi @yadu@redhat.com

I've just seen that the fix is already bundled.
The bug ended up being a pod-ownership error when cloning without size between namespaces.

Thanks for the report!

— Additional comment from Yan Du on 2023-01-20 09:02:23 UTC —

Hi, Alvara
I didn't see the PR includes in 4.12.0, so we may need to wait the downstream 4.12.1 build to verify the bug