Support Volume Expansion

[ekristen]

Since local-path-provisioner does not enforce capacity limitations, then I see no reason to throw errors in the event that someone changes the spec.capacity settings.

The following PR implements a partial fix that does away with the error messages. The remaining fix would be to simply update the PVC status to match the spec in a no-op function since it doesn't actually enforce or have to provision space.

Again since there is zero enforcement I see no reason to not simply set the setting that allows for volume expansion.

The error being only dynamically provisioned pvc can be resized and the storageclass that provisions the pvc must support resize

PR - #189

Other issues

• Does the local-path storageclass support AllowVolumeExpansion or dynamic resize/expansion the PVC?  #107
• Expand pvc #18

[ekristen]

Is there any reason to not do this? If the provisioner isn't actually enforcing or check data sizes, why not allow the size to be changed so it doesn't throw an error?

[michaelandrepearce]

Any update on this?

[quato666]

I'm also very interested in this enhancment - I'm successufly using provisioner with xfs quota feature and it really lacks the ability to resize pvc/pv - that way it would be possible to have consitancy between pv/pvc data on k8s and quotas set on directories. Adding additional section "resize" (besides setup and teardown) in local-path-config configmap, along with code changes needed for k8s to properly handle and notify volume expansion for storageclass with allowVolumeExpansion set to true, would be very useful.

[quato666]

By the way - xfs quota works great, because at the pod/container level it returns proper size values with df :)

[derekbit]

@quato666

Thanks for the feedback.
I don't have much time for this project at the moment, so the development and update will be slow.
If you're interested in this feature. Any contribution is welcomed. Thank you in advance.

[laurivosandi]

I am also interested in this

[jessebot]

It looks like #350 may no longer be in development, so if others are familiar enough to tackle this, it may be a good time to submit a PR. This feature would be incredibly useful.

[fs185143]

Any progress on this? Currently if I do the following:

• Add allowVolumeExpansion: true to the local-path StorageClass
• Create a VM with a local-path disk, e.g.,

  - metadata:
      name: os-vm-basic-disk
      namespace: os-example
    spec:
      pvc:
        accessModes:
        - ReadWriteOnce
        storageClassName: local-path
        resources:
          requests:
            storage: 80Gi

• Patch os-vm-basic-disk PersistentVolumeClaim and increase the value, e.g.,

spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 90Gi

Then the PVC just gets stuck in this state

Warning ExternalExpanding 7m3s volume_expand waiting for an external controller to expand this PVC

[manuschillerdev]

in the current state:

would it be a workaround to do the following?

• stop the pods
• move the files to a temporary directory
• delete the pvc/pv
• create a new pvc with a bigger size
• move the temp files to the new directory (bound to the pvc)
• bind the new pvc to the pod
• restart the pod

[sarendipitee]

Did anyone here ever figure out a workaround?

[Ethereal-O]

Based on Marjus Cako's work, I have submitted a new PR #529.