wonko
commented
5 months ago Some drivers allow the resize to happen, but then note that the pod should be cycled to allow the volume to expand. Here, it seems that the driver actually denies the resize if the volume is still in use. The former flow is much more user-friendly, as you can just resize the PVCs and then do a k rollout restart of whatever is using the volumes.
Also, the error is ugly:
│ Normal ProvisioningSucceeded 9m42s csi.exoscale.com_exoscale-csi-controller-7578c45864-xrs77_f1b35fa8-11f4-4657-94e3-a3c2f327ec5f Successfully provisioned volume pvc-e8d997d5-6b38-44ac-a113-08524cd35733 │
│ Warning ExternalExpanding 11s volume_expand waiting for an external controller to expand this PVC │
│ Normal Resizing 7s (x4 over 11s) external-resizer csi.exoscale.com External resizer is resizing volume pvc-e8d997d5-6b38-44ac-a113-08524cd35733 │
│ Warning VolumeResizeFailed 7s (x4 over 11s) external-resizer csi.exoscale.com resize volume "pvc-e8d997d5-6b38-44ac-a113-08524cd35733" by resizer "csi.exosca │
│ le.com" failed: rpc error: code = Unknown desc = ResizeBlockStorageVolume: http response: invalid request: bad request(i assume the "bad request" is the consequence of not having detached the volume).
What feature would you like to have in the provider?
Unfortunately, due to limitations in the current Exoscale Block Storage design, the CSI cannot support online resizing. This means that to resize a volume, it would need to be detached from the Kubernetes node first. As a consequence, workloads that mount the volume will have to be stopped temporarily to detach the volume before resizing.
For the foreseeable future we cannot implement this feature but you are welcome to communicate your interest and need for this feature here through comments or reactions.
Thank you for understanding.