Fix NodeExpandVolume#493
Conversation
ArielYehezkely
commented
May 27, 2026
- Fix NodeExpandVolume to continue to actually call lvextend when the requested capacity is larger than the current PV capacity to enable exapnsion.
- Advertise PluginCapability_VolumeExpansion_ONLINE so the external-resizer sidecar drives NodeExpandVolume per CSI spec.
- After a successful NodeExpandVolume, patch pv.Spec.CSI.VolumeAttributes[CapacityParam] with the new size via a client.MergeFrom patch so failover re-provisioning recreates the LV at the expanded size.
- Add unit tests and e2e tests for expanding PV.
|
Thanks for adding so many tests and thanks for thinking too of the case where we need to rehydrate the expanded PV. Can you also change controllerExpansion to true in |
ddfc418 to
26bc072
Compare
26bc072 to
4b91284
Compare
|
@jmclong The E2E tests revealed a problem that might require a wider change - the capacityParam is an immutable field which cannot be patched, this mean that re-provisioning after expansion will create the PV with the original size from creation time, I don't know if this is a blocker for the current change. |
| } | ||
| pv.Annotations[lvm.ExpandedCapacityParam] = fmt.Sprint(resp.GetCapacityBytes()) | ||
| if err := ns.k8sClient.Patch(ctx, &pv, client.MergeFrom(original)); err != nil { | ||
| log.Error(err, "failed to patch PV with expanded capacity annotation") |
There was a problem hiding this comment.
I suggest we return an error here since we know the PV exists and we would otherwise rehydrate with the wrong capacity.
| @@ -587,7 +603,21 @@ func (ns *Server) NodeExpandVolume(ctx context.Context, req *csi.NodeExpandVolum | |||
| return nil, status.Error(codes.Internal, err.Error()) | |||
There was a problem hiding this comment.
We are swallowing the errors that we create in the volume code, resulting in always returning internal. We can return the correct error type from resp. Otherwise I think we can get in a loop where nodeexpandvolume will keep being retried in some situations