Bug 1927473 - virtctl image-upload dv to an empty pvc times out when using virtctl-2.6.0
Summary: virtctl image-upload dv to an empty pvc times out when using virtctl-2.6.0
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Container Native Virtualization (CNV)
Classification: Red Hat
Component: Storage
Version: 2.6.0
Hardware: Unspecified
OS: Unspecified
unspecified
low
Target Milestone: ---
: 4.8.0
Assignee: skagan
QA Contact: Alex Kalenyuk
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-02-10 20:09 UTC by Alex Kalenyuk
Modified: 2021-07-27 14:34 UTC (History)
4 users (show)

Fixed In Version: kubevirt 4.8.0-177
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-07-27 14:24:44 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github kubevirt kubevirt pull 5140 0 None closed handle image upload to data volume with existing pvc name 2021-03-11 07:11:40 UTC
Red Hat Product Errata RHSA-2021:2920 0 None None None 2021-07-27 14:34:20 UTC

Description Alex Kalenyuk 2021-02-10 20:09:28 UTC
Description of problem:
When using virtctl image-upload dv with --no-create to upload into an existing empty PVC, we get a timeout (used to work with both image-upload dv & pvc)

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

How reproducible:
100%

Steps to Reproduce:
1. Create an empty PVC
2. virtctl image-upload dv empty-pvc --image-path=./cirros-qcow2.img --insecure --no-create

Actual results:
virtctl times out

Expected results:
Upload successful

Additional info:
The same operation with virtctl that corresponds to CNV 2.5 succeeds (described in comment #1)

This might be a happy accident but the fact that it is not intentional kind of rings the alarm bell

[cnv-qe-jenkins@stg01-alex-rjlb7-executor virtctl-exist-pvc]$ cat empty_pvc.yaml 
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: empty-pvc
spec:
  volumeMode: Filesystem
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 3Gi
  storageClassName: nfs

Comment 2 Natalie Gavrielov 2021-02-17 13:27:28 UTC
Alex, in the old virtctl, when you upload to a DV when you have an existing PVC - did a DV get created?

Comment 3 Alex Kalenyuk 2021-02-17 15:31:40 UTC
(In reply to Natalie Gavrielov from comment #2)
> Alex, in the old virtctl, when you upload to a DV when you have an existing
> PVC - did a DV get created?
A DV doesn't get created in the old/current virtctl for this operation:

Downgraded:
  kubevirt-virtctl-2.5.4-107.el7_9.x86_64                                                                                                                                                                                                     

Complete!
[cnv-qe-jenkins@stg01-alex-rjlb7-executor virtctl-exist-pvc]$ oc create -f empty_pvc.yaml 
persistentvolumeclaim/empty-pvc created
(reverse-i-search)`virt': ^Crtctl image-upload dv empty-pvc --image-path=./cirros-qcow2.img --insecure --no-create
(reverse-i-search)`--in': virtctl image-upload dv empty-pvc --image-path=./cirros-qcow2.img ^Cinsecure --no-create
[cnv-qe-jenkins@stg01-alex-rjlb7-executor virtctl-exist-pvc]$ virtctl image-upload dv empty-pvc --image-path=./cirros-qcow2.img --insecure --no-create
Using existing PVC openshift-virtualization-os-images/empty-pvc
Waiting for PVC empty-pvc upload pod to be ready...
Pod now ready
Uploading data to https://cdi-uploadproxy-openshift-cnv.apps.stg01-alex.cnv-qe.rhcloud.com

 12.13 MiB / 12.13 MiB [==========================================================================================================================================================================================================] 100.00% 0s

Uploading data completed successfully, waiting for processing to complete, you can hit ctrl-c without interrupting the progress
Processing completed successfully
Uploading ./cirros-qcow2.img completed successfully
[cnv-qe-jenkins@stg01-alex-rjlb7-executor virtctl-exist-pvc]$ oc get dv -A
No resources found

Comment 5 Adam Litke 2021-02-24 13:46:59 UTC
The combination of options used in this scenario is invalid:

"virtctl image-upload dv empty-pvc --image-path=./cirros-qcow2.img --insecure --no-create"

"dv" means use a DataVolume.
--no-create means don't create the DataVolume because it already exists

But you have created a PVC with the same name.  So virtctl is looking for a DV which you said already exists and this eventually times out.  I think we can improve virtctl with better messages in the following scenarios:

1. "virtctl dv my-disk ... --no-create" where my-disk does not exist:
   - Continue waiting but print a message "DV my-disk not found..." each time it is checked
2. "virtctl pvc my-disk ... --no-create" where my-disk does not exist:
   - Continue waiting but print a message "PVC my-disk not found..." each time it is checked
3. "virtctl dv my-disk ... --no-create" where my-disk is a PVC but a DV of the same name does not exist:
   - Print a message "Error: No DataVolume is associated with the existing PVC my-disk" and exit immediately.

Comment 12 errata-xmlrpc 2021-07-27 14:24:44 UTC
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 (Moderate: OpenShift Virtualization 4.8.0 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/RHSA-2021:2920

Comment 13 errata-xmlrpc 2021-07-27 14:33:55 UTC
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 (Moderate: OpenShift Virtualization 4.8.0 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/RHSA-2021:2920


Note You need to log in before you can comment on or make changes to this bug.