Open cumirror opened 3 years ago
I have managed to resize the volume in call CreateVolume
when it's a block volume, but this still has issue when it's a filesystem volume: the filesystem can not be resized in call CreateVolume
, it should be done by kubelet calling the NodeExpandVolume
, which I can not do that in the CSI driver code.
I have submitted a issue to community to address this issue https://github.com/kubernetes-csi/external-resizer/issues/131
And I also looked at other open source CSI drivers, they don't have a solution for such case either. For example, ceph. They will force user to specify an exact same size for the new PVC, otherwise an size mismatch
error will be threw. After the clone volume done, user can expand the volume as usual. Maybe we should do that too, in that way we make sure the resize is on purpose and can be done successfully, for both block volume and filesystem volume.
This is a very general and popular problem, not only neonsan-csi, but also qingcloud-csi and many other csi drivers have this problem too. See the comments in https://github.com/kubernetes-csi/external-resizer/issues/131, a discussion is ongoing about this with the K8S SIG-STORAGE team and CSI SPEC team. Currently there is no conclusion/decision and ETA.
I will NOT fix this issue or change any code util the above discussion has a closure. We will keep current behaviour.
Please check latest csi spec and the progress of https://github.com/kubernetes-csi/external-resizer/issues/131. Regarding this issue, the decision is NOT allow cloning a volume to large size. User must start a new resize request after cloning done if expansion is needed.
source pvc's size is 4Gi:
clone pvc's size is 6Gi:
after clone, pvc info:
after clone, clone volume size is 4Gi not 6Gi:
After cloning is complete, the size of underlying storage volume should be consistent with the requested PVC.