Bug 1911617

Summary:	[CNV][UI] Failure to add source to VM template when no default storage class is defined
Product:	OpenShift Container Platform	Reporter:	Chen Yosef <cyosef>
Component:	Console Kubevirt Plugin	Assignee:	Gilad Lekner <glekner>
Status:	CLOSED ERRATA	QA Contact:	Guohua Ouyang <gouyang>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	4.7	CC:	aos-bugs, glekner, gouyang, yzamir
Target Milestone:	---	Keywords:	Reopened
Target Release:	4.7.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2021-02-24 15:49:11 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Chen Yosef 2020-12-30 12:01:09 UTC

Description of problem:
When adding a new source for a VM template while there is no default storage class defined in the cluster, the pvc of the data volume will remain in pending forever. 

Version-Release number of selected component (if applicable):
OCP 4.7 nightly build
CNV 2.5.2


How reproducible:
100%

Steps to Reproduce:
1. Make sure none of the defined storage class has "storageclass.kubernetes.io/is-default-class" annotation (no default storage class).
2. Go to VM template, and try to add source to one of the templates.
3. On the "Add boot source to template" dialog box, click advance - verify that the storage class field show one of the defined storage class (but don't touch that field)
4. Press "save and upload".

Actual results:
A new data volume is created, but the pvc spec doesn't include the storage class highlighted in the dialog box. As a result the PVC is pending as there are no available PVs.

Expected results:
The explicitly selected storage class should be used when creating the data volume for the template source. 


Additional info:
When opening the storage class scroll list and explicitly select a storage class, the DV will be created as expected.

Comment 1 Guohua Ouyang 2020-12-30 12:12:10 UTC

It should be duplicated with https://bugzilla.redhat.com/show_bug.cgi?id=1908180.

Comment 2 Yaacov Zamir 2020-12-30 17:45:44 UTC


*** This bug has been marked as a duplicate of bug 1908180 ***

Comment 3 Yaacov Zamir 2020-12-30 18:44:47 UTC

re-opening: this bug is about a specific case when we have no default storage class, 1908180 fixes the case when we have a default storage class

Comment 4 Chen Yosef 2020-12-31 09:37:01 UTC

@yzamir Additional info. When I don't modify the storage class field, this is the request sent to the backend for creating the DV:
{"kind":"DataVolume","apiVersion":"cdi.kubevirt.io/v1alpha1","metadata":{"name":"rhel8","namespace":"openshift-virtualization-os-images"},"spec":{"pvc":{"resources":{"requests":{"storage":"3Gi"}},"accessModes":["ReadWriteOnce"],"volumeMode":"Filesystem"},"source":{"http":{"url":"https://download.fedoraproject.org/pub/fedora/linux/releases/33/Cloud/x86_64/images/Fedora-Cloud-Base-33-1.2.x86_64.raw.xz"}}}}

While if I explicitly select a storage class from the drop down list in the storage class field, you can see it is sent to the backend:
{"kind":"DataVolume","apiVersion":"cdi.kubevirt.io/v1alpha1","metadata":{"name":"fedora","namespace":"openshift-virtualization-os-images"},"spec":{"pvc":{"resources":{"requests":{"storage":"20Gi"}},"storageClassName":"standard","accessModes":["ReadWriteOnce"],"volumeMode":"Filesystem"},"source":{"http":{"url":"https://download.fedoraproject.org/pub/fedora/linux/releases/33/Cloud/x86_64/images/Fedora-Cloud-Base-33-1.2.x86_64.raw.xz"}}}}

Comment 6 Guohua Ouyang 2021-01-04 01:21:23 UTC

verified on latest 4.7, when no default sc defined, the first SC in the list is used.
In QE environment, the first SC on UI is ocs-storagecluster-ceph-rbd, and upload source for template is successful.

Comment 9 errata-xmlrpc 2021-02-24 15:49:11 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 Container Platform 4.7.0 security, bug fix, and enhancement update), 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-2020:5633