search

intel / pmem-csi

Persistent Memory Container Storage Interface Driver
Apache License 2.0
164 stars 55 forks source link

CapacityRange limit_bytes not handled according to CSI spec, size semantics not correct #399

Open okartau opened 5 years ago

okartau commented 5 years ago

Current PMEM-CSI implementation handling of CapacityRange.{required_bytes,limit_bytes} is only partial implementation of what CSI spec requires. What is required by spec: both fields are optional, but one of two MUST be present. PMEM-CSI: does not check this properly. We use required_bytes for "asked" and assume it is present. limit_bytes presence or value we never check (but we log the value).

Creation sizes semantics is respectively also not correct. Spec says, if limit_bytes is present, volume MUST not be larger. PMEM_CSI does not implement that. Use of same value in both req. and limit values is a method to specify exact volume size in request. This is not attempted nor checked by PMEM_CSI either. Created PMEM Volume is usually bigger than request, caused by alignment requirements on underlying device. Requested exact allocation (both sizes set to same in request) can lead to situation where PMEM-CSI has to return error if Volume of such exact size can not be created. In this case PMEM-CSI has to return "OUT OF RANGE" error (not currently done).

If I look through current e2e, sanity test logs (LVM case), most creation requests do specify required_bytes=N and limit_bytes=0. Some requests however specify required_bytes=1MB and limit_bytes=1MB. PMEM-CSI creates a 4MB file system (which is miminum by LVM volume sizes) in return, which is clearly violating CSI spec, as 1MB volume should get created. However, test code does not complain.

okartau commented 5 years ago

The fact that current PMEM-CSI code passes e2e and sanity tests, is a sign that this scenario is not tested.

pohly commented 3 years ago

Maximum size is unused in Kubernetes, see https://github.com/kubernetes-csi/external-provisioner/issues/616