Bug 2176422

Summary:	getting wrong error message when trying to upload dv when pvc already exist
Product:	Container Native Virtualization (CNV)	Reporter:	dalia <dafrank>
Component:	Storage	Assignee:	Álvaro Romero <alromero>
Status:	CLOSED ERRATA	QA Contact:	dalia <dafrank>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	4.13.0	CC:	alromero, yadu
Target Milestone:	---
Target Release:	4.13.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	v4.13.0.rhel9-1930	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2023-05-18 02:58:16 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 dalia 2023-03-08 11:03:42 UTC

Description of problem:
When trying to upload a dv/pvc via virtctl, and the pvc already exist but the dv was garbage collected, the wrong error message printed to screen.

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

How reproducible:
100%

Steps to Reproduce:
1. Create a DV and wait for it to success:

virtctl image-upload dv dv-name --size=18Gi --image-path=./Fedora... --block-volume --access-mode=ReadWriteOnce --storage-class=ocs-storagecluster-ceph-rbd --insecure

2. try to upload again:


Actual results:
error message:
No DataVolume is associated with the existing PVC default/dv-name


Expected results:
error message:
PVC dv-name already successfully imported/cloned/updated

Comment 1 Álvaro Romero 2023-03-16 13:07:20 UTC

Hey @dafrank 

I created this PR[1] to improve the error handling so it matches the expected results, but I think we first need some reviews to see if the team is happy with the change.

I think we can't simply change the current error message to match the expected result since we don't know if the PVC exists due to an already garbage-collected DV or if it was just created with the same name.

In the PR, I'm checking if the PVC contains the DeleteAfterCompletion annotation to determine if it was created by a DV or not. However, I'm also not 100% happy with that because the PVC could have been created by a completely different DV with the same name. I still think it's a good solution though. 

[1] https://github.com/kubevirt/kubevirt/pull/9445

Comment 2 Yan Du 2023-03-22 13:26:33 UTC

Alvaro, could you please cherrypick the main branch PR?

Comment 3 Álvaro Romero 2023-03-22 13:36:16 UTC

Sure, thanks for noticing.

Comment 4 Yan Du 2023-04-12 10:20:05 UTC

Test on CNV-v4.13.0.rhel9-2036

$ virtctl image-upload dv dv-name --size=18Gi --image-path=./Fedora...  --block-volume --access-mode=ReadWriteOnce --storage-class=ocs-storagecluster-ceph-rbd --insecure
DataVolume already garbage-collected: Assuming PVC default/dv-name is successfully populated

Comment 6 errata-xmlrpc 2023-05-18 02:58:16 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.13.0 Images 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-2023:3205

Comment 7 Red Hat Bugzilla 2023-09-19 04:34:21 UTC

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days