-
Bug
-
Resolution: Done-Errata
-
None
-
False
-
-
False
-
CLOSED
-
---
-
---
-
-
-
Storage Core Sprint 230
-
None
Description of problem:
When a DataVolume/PVC is being restored by a backup program (say Velero) the following should be true:
1. DataVolume has "cdi.kubevirt.io/storage.prePopulated" annotation
2. PVC has "cdi.kubevirt.io/storage.populatedFor" annotation
3. Doesn't matter if DV or PVC is restored first
4. PVC does not have to initially be owned by the DataVolume
This bug deals with 4
Version-Release number of selected component (if applicable): 4.10.X
How reproducible:
Steps to Reproduce:
1. Create DataVolume
apiVersion: cdi.kubevirt.io/v1beta1
kind: DataVolume
metadata:
annotations:
cdi.kubevirt.io/storage.prePopulated: populated-dv
name: populated-dv
namespace: default
spec:
pvc:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 2Gi
storageClassName: rook-ceph-block
volumeMode: Filesystem
source:
http:
url: http://doesnotexist/disk.img
2. Create PVC
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
annotations:
cdi.kubevirt.io/storage.populatedFor: populated-dv
name: populated-dv
namespace: default
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 2Gi
storageClassName: rook-ceph-block
volumeMode: Filesystem
Actual results:
DataVolume will stay pending until DV is reconciled again
Expected results:
DataVolume will go to succeeded phase
Additional info:
- blocks
-
CNV-23030 [2149671] [4.10] Backup program integration: DataVolume/PVC restore should not require PVC initially owned by DV
- Closed
- external trackers