Description of problem: Creating StorageClass with AllowVolumeExpansion=true or AllowVolumeExpansion=false, or no AllowVolumeExpansion field. PVC resize always successfully. Version-Release number of selected component (if applicable): oc v3.9.0-0.15.0 openshift v3.9.0-0.15.0 kubernetes v1.9.0-beta1 How reproducible: always Steps to Reproduce: 1. Create StorageClass with AllowVolumeExpansion=true | AllowVolumeExpansion=false | no AllowVolumeExpansion field. 2. Create a PVC using the StorageClass 3. Edit PVC to expand PVC size from 10G to 20G Actual results: PVC expand successfully. Expected results: When AllowVolumeExpansion=false or no AllowVolumeExpansion field, PVC expand should be failed. Additional info: # cat sc.yaml apiVersion: storage.k8s.io/v1beta1 kind: StorageClass metadata: name: glusterprovisioner provisioner: kubernetes.io/glusterfs parameters: resturl: "http://10.8.241.21:9991" restuser: "admin" restuserkey: "test" AllowVolumeExpansion: true
As I wrote in another BZ - this is a new feature and it requires feature gate to be enabled. Also field name is "allowVolumeExpansion" not "AllowVolumeExpansion".
Hi Hemant, 1. Enabled feature gates ExpandPersistentVolumes, admission controller PersistentVolumeClaimResize, and set allowVolumeExpansion to false, PVC can be expanded successfully. 2. Just enable feature gates ExpandPersistentVolumes, not enable admission controller PersistentVolumeClaimResize, and set allowVolumeExpansion to false, PVC can be expanded successfully. So reopen this bug. # oc get sc glusterfs -o yaml allowVolumeExpansion: false apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: creationTimestamp: 2018-01-04T10:23:06Z name: glusterfs resourceVersion: "546629" selfLink: /apis/storage.k8s.io/v1/storageclasses/glusterfs uid: 41157a28-f139-11e7-9c0c-0050569f5abb parameters: resturl: http://172.30.102.160:8080 provisioner: kubernetes.io/glusterfs reclaimPolicy: Delete
This is again by design - the volume expansion feature is supposed to work in conjunction with admission controller. Without the admission controller - k8s doesn't offer a way of blocking edit/update of a resource based on querying a different resource. Basically - anything that requires a etcd lookup to validate an object has to be performed in admission plugin and can't be done in validations.
Fixed via https://github.com/openshift/origin/pull/18146 Problem was - admission plugin was not getting enabled.
This bug is targeted to 3.9.0, while it was attached to 3.7/3.6/3.5 errata, move correct it.
Verified on OCP version: v3.9.0-0.31.0
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2018:0489
I still think this issue is not completely solved. As the current documentation for OpenShift 3.9 states [1]: > Once the OpenShift Container Platform administrator has created a StorageClass with allowVolumeExpansion set to true, you can create a PVC from that class, and afterwards, whenever needed, you can edit the PVC and request a new size. So that seems to be wrong, reading through the history of this issue. [1] https://docs.openshift.com/container-platform/3.9/dev_guide/expanding_persistent_volumes.html#expanding_glusterfs_pvc
Why you think issue is still not solved? Are you able to expand PVCs without the `allowVolumeExpansion` flag in SC when admission controller is enabled? Can you list steps that reproduces the bug?
Closing the BZ. I have verified that issue is indeed solved if admission controller is enabled. Also in 3.11 - since the feature has moved to beta, the admission controller should be enabled by default.