Bug 2232347 - DataImportCron DVs do not respond to default storage class being set
Summary: DataImportCron DVs do not respond to default storage class being set
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Container Native Virtualization (CNV)
Classification: Red Hat
Component: Storage
Version: 4.13.3
Hardware: Unspecified
OS: Unspecified
high
medium
Target Milestone: ---
: 4.13.4
Assignee: Arnon Gilboa
QA Contact: Harel Meir
URL:
Whiteboard:
Depends On:
Blocks: 2235151
TreeView+ depends on / blocked
 
Reported: 2023-08-16 12:41 UTC by Alex Kalenyuk
Modified: 2023-09-19 11:42 UTC (History)
4 users (show)

Fixed In Version: v4.13.4.rhel9-101
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 2235151 (view as bug list)
Environment:
Last Closed: 2023-09-19 11:41:59 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github kubevirt containerized-data-importer pull 2860 0 None Merged Do not fail DV reconcile if storage class is not found 2023-08-27 07:09:19 UTC
Github kubevirt containerized-data-importer pull 2861 0 None Merged [release-v1.56] Do not fail DV reconcile if storage class is not found 2023-08-27 07:09:35 UTC
Red Hat Issue Tracker CNV-32118 0 None None None 2023-08-16 12:45:06 UTC
Red Hat Product Errata RHSA-2023:5233 0 None None None 2023-09-19 11:42:20 UTC

Description Alex Kalenyuk 2023-08-16 12:41:22 UTC
Description of problem:
DataImportCron DVs do not respond to default storage class being set

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

How reproducible:
100%

Steps to Reproduce:
1. If a default storage class is set, remove it, clean up DataImportCron DV/PVCs
2. Wait for DVs to get created (should be stuck in Pending)
3. Set default storage class back

Actual results:
DVs remain stuck in Pending

Expected results:
Imports begin and succeed

Additional info:
- This does not happen in 4.14 so maybe we could borrow the logic that
fixed it to 4.13
- This does not happen in 4.12
- The test for this scenario seems to succeed even though we have this issue
so potentially a true negative

Comment 2 Harel Meir 2023-08-28 13:11:42 UTC
Verified on 4.13:

1. remove the default storageclass with:

   oc patch storageclass hostpath-csi-basic -p '{"metadata": {"annotations": {"storageclass.kubernetes.io/is-default-class": "false"}}}'

2. deleted a pvc from NS=openshift-openshift-virtualization-os-images, with:

   oc delete pvc centos-stream8-ad852c1cc2d2 $NS
   result: persistentvolumeclaim "centos-stream8-ad852c1cc2d2" deleted,
           and the DV is in phase pending: 
           NAME                          PHASE     PROGRESS   RESTARTS   AGE
           centos-stream8-ad852c1cc2d2   Pending                         76s

3. set the default SC back to hostpath-csi-basic

And the import triggered:
[cloud-user@ocp-psi-executor-xl ~]$ oc get dv $NS
NAME                          PHASE              PROGRESS   RESTARTS   AGE
centos-stream8-ad852c1cc2d2   ImportInProgress   57.42%                2m30s

and eventually succeeded:
[cloud-user@ocp-psi-executor-xl ~]$ oc get pvc $NS
NAME                          STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS         AGE
centos-stream8-ad852c1cc2d2   Bound    pvc-ad0d912b-ecc9-4719-9382-93ee61f6dcdf   149Gi      RWO            hostpath-csi-basic   5m16s

Comment 8 errata-xmlrpc 2023-09-19 11:41:59 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.4 security and bug fix 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:5233


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