-
Notifications
You must be signed in to change notification settings - Fork 457
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support Volume Expansion #190
Comments
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? |
Any update on this? |
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. |
By the way - xfs quota works great, because at the pod/container level it returns proper size values with df :) |
Thanks for the feedback. |
I am also interested in this |
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. |
Any progress on this? Currently if I do the following:
- metadata:
name: os-vm-basic-disk
namespace: os-example
spec:
pvc:
accessModes:
- ReadWriteOnce
storageClassName: local-path
resources:
requests:
storage: 80Gi
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 90Gi Then the PVC just gets stuck in this state
|
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
The text was updated successfully, but these errors were encountered: