Bug 2219774
| Summary: | The "snapshot" clone-strategy may not choose the correct VolumeSnapshotClass if there are multiple VolumeSnapshotClasses with the same driver | ||
|---|---|---|---|
| Product: | Container Native Virtualization (CNV) | Reporter: | nijin ashok <nashok> |
| Component: | Storage | Assignee: | Arnon Gilboa <agilboa> |
| Status: | NEW --- | QA Contact: | Natalie Gavrielov <ngavrilo> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 4.13.1 | ||
| Target Milestone: | --- | ||
| Target Release: | 4.15.0 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 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 of problem: Hitachi storage can have multiple storage pools on the backend storage. Each storage pool corresponds to a StorageClass in OpenShift. Also, there is a corresponding VolumeSnapshotClass for each StorageClass. However, they will be having the same driver and provisioner. ~~~ # oc get volumesnapshotclasses.snapshot.storage.k8s.io snapshotclass-gold -o json | jq '.driver' "hspc.csi.hitachi.com" # oc get volumesnapshotclasses.snapshot.storage.k8s.io snapshotclass-silver -o json | jq '.driver' "hspc.csi.hitachi.com" # omg get sc sc-gold -o yaml |yq '.provisioner' hspc.csi.hitachi.com # omg get sc sc-silver -o yaml |yq '.provisioner' hspc.csi.hitachi.com ~~~ The CDI finds the VolumeSnapshotClass by listing the VolumeSnapshotClass and by matching the driver with the provisioner of StorageClass. If there are multiple VolumeSnapshotClasses with the same driver, it can incorrectly pick the VolumeSnapshotClass of another SC. ~~~ 722 func (r *PvcCloneReconciler) getSnapshotClassForSmartClone(dataVolume *cdiv1.DataVolume, targetStorageSpec *corev1.PersistentVolumeClaimSpec) (stri ng, error) { ... ... 748 scs := &snapshotv1.VolumeSnapshotClassList{} 749 if err := r.client.List(context.TODO(), scs); err != nil { 750 log.Info("Cannot list snapshot classes, falling back to host assisted clone") 751 return "", err 752 } 753 for _, snapshotClass := range scs.Items { <<< 754 // Validate association between snapshot class and storage class 755 if snapshotClass.Driver == srcStorageClass.Provisioner { <<< 756 log.Info("smart-clone is applicable for datavolume", "datavolume", 757 dataVolume.Name, "snapshot class", snapshotClass.Name) 758 return snapshotClass.Name, nil 759 } ~~~ Since they will be having different parameters like poolID, the VolumeSnapshotClass of one SC doesn't work with the other and the snapshot will fail. Version-Release number of selected component (if applicable): OpenShift Virtualization 4.13.1 How reproducible: 100% Steps to Reproduce: The issue is always reproducible for the customer. It can be also reproducible in a lab environment by creating a dummy VolumeSnapshotClass for any existing storage class where it will pick one among them while creating the snapshot. Actual results: The "snapshot" clone-strategy may not choose the correct VolumeSnapshotClass if there are multiple VolumeSnapshotClasses with the same driver Expected results: Ability to detect the correct VolumeSnapshotClass if there are multiple VolumeSnapshotClasses with the same driver. Maybe allow the user to configure the VolumeSnapshotClasses in the StorageProfile? Additional info: