-
Bug
-
Resolution: Unresolved
-
Major
-
CNV v4.18.0
-
None
-
Quality / Stability / Reliability
-
2
-
False
-
-
False
-
CNV v4.99.0.rhel9-2288, CNV v4.18.2.rhel9-18
-
-
CNV Storage 267, CNV Storage 268, CNV Storage 269, CNV Storage 270, CNV Storage 272, CNV Storage 273, CNV Storage 274, CNV Storage 275
-
None
Description of problem:
Many tier-1 tests are doing VolumeSnapshot based cloning. When running the sig-storage tests on GCP cluster with 4.18.0, we found an issue in the clone populator VolumeSnapshots watch. If the snapshot wasn't Ready at the initial loop, it won't be re-queued. This is causing DataVolumes to get stuck in the CloneFromSnapshotSourceInProgress phase. It seems that in GCP it takes longer for VolumeSnapshots to become Ready, which revealed this issue.
Version-Release number of selected component (if applicable):
CNV 4.18.0
How reproducible:
Steps to Reproduce:
Run any snapshot-based cloning tier-1 test on GCP cluster, where VolumeSnaphot is cloned right after its creation, e.g: sig-storage] DataVolume Integration [rfe_id:3188][crit:high][vendor:cnv-qe@redhat.com][level:system] DataVolume clone permission checking using Alpine import/clone should resolve DataVolume sourceRef with Snapshot source
Actual results:
DataVolume will get stuck in the CloneFromSnapshotSourceInProgress phase and never get to Succeeded, and VMs will not get to Ready.
Expected results:
DataVolume clone should continue when VolumeSnaphot becomes Ready, until DataVolume is Succeeded.
Additional info:
- is blocked by
-
-
- ASSIGNED
-
-
CNV-59520 [4.19] Annotate specific provisioners StorageProfile with their minimum supported PVC size
-
- Closed
-
-
-
- Closed
-
- is cloned by
-
-
- Closed
-
- is duplicated by
-
-
- Closed
-
- links to
