Bug 1949420
| Summary: | [azure csi driver operator] pvc.status.capacity and pv.spec.capacity are processed not the same as in-tree plugin | ||
|---|---|---|---|
| Product: | OpenShift Container Platform | Reporter: | Qin Ping <piqin> |
| Component: | Storage | Assignee: | Christian Huffman <chuffman> |
| Storage sub component: | Operators | QA Contact: | Qin Ping <piqin> |
| Status: | CLOSED ERRATA | Docs Contact: | |
| Severity: | medium | ||
| Priority: | unspecified | CC: | aos-bugs, chuffman |
| Version: | 4.8 | ||
| Target Milestone: | --- | ||
| Target Release: | 4.8.0 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2021-07-27 23:00:33 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: | |||
It looks like some rounding does occur for the backend disk:
[...]
capacityBytes := req.GetCapacityRange().GetRequiredBytes()
volSizeBytes := int64(capacityBytes)
requestGiB := int(volumehelper.RoundUpGiB(volSizeBytes))
if requestGiB < minimumDiskSizeGiB {
requestGiB = minimumDiskSizeGiB
}
[...]
Examining the `size` value for various sized disks, we're rounding up to the next GiB to ensure the backend disk of an appropriate size can be created:
[...]
volumeOptions := &azure.ManagedDiskOptions{
[...]
SizeGB: requestGiB,
[...]
}
diskURI, err := d.cloud.CreateManagedDisk(volumeOptions)
[...]
But we still use the original capacity from the spec in the CreateVolumeResponse:
return &csi.CreateVolumeResponse{
Volume: &csi.Volume{
VolumeId: diskURI,
CapacityBytes: capacityBytes,
I submitted https://github.com/kubernetes-sigs/azuredisk-csi-driver/pull/824 to fix this and allow the CSI driver to mirror the in-tree behavior, especially since we're already creating the larger disk.
Verified with: 4.8.0-0.nightly-2021-05-12-184904
...
"spec": {
"accessModes": [
"ReadWriteOnce"
],
"resources": {
"requests": {
"storage": "1M"
}
},
"storageClassName": "managed-csi",
"volumeMode": "Filesystem",
"volumeName": "pvc-5a3a6851-97e9-4b8e-a540-ea0c9340813f"
},
"status": {
"accessModes": [
"ReadWriteOnce"
],
"capacity": {
"storage": "1Gi"
},
"phase": "Bound"
}
...
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 Container Platform 4.8.2 bug fix and security 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-2021:2438 |
Description of problem: In azure csi driver, pvc.status.capacity and pv.spec.capacity are processed not the same as in-tree plugin Version-Release number of selected component (if applicable): 4.8.0-0.nightly-2021-04-13-171608 How reproducible: Always Steps to Reproduce: 1. Create a PVC with the following yaml file: $ cat pvc.yaml kind: PersistentVolumeClaim apiVersion: v1 metadata: name: test-pvc-b6 spec: storageClassName: managed-csi-test volumeMode: Filesystem accessModes: - ReadWriteOnce resources: requests: storage: 1M 2. Check the PV and PVC Actual results: $ oc get pv pvc-aa95a952-a395-41b3-8927-e98ac03c335b -ojson|jq .spec.capacity { "storage": "1M" } $ oc get pvc test-pvc-b6 -ojson| jq .status.capacity { "storage": "1M" } Expected results: For in-tree plugin, the capacity should be “1Gi” in both PV and PVC. In the cloud end, the azure disk size is 1Gi too. Master Log: Node Log (of failed PODs): PV Dump: PVC Dump: StorageClass Dump (if StorageClass used by PV/PVC): Additional info: