Description of problem: When deploying OpenShift 4.7.0-fc.2, the default StorageClass does not set allowVolumeExpansion: true, disabling volume resize functionality. Documentation draft states it will be deployed with allowVolumeExpansion: true. Version-Release number of selected component (if applicable): OpenShift 4.7.0-fc.2 OpenStack 16.1.3 (AIO) How reproducible: Steps to Reproduce: 1. Deploy 4.7.0-fc.2 2. Check Storage class "standard-csi" Actual results: { "apiVersion": "storage.k8s.io/v1", "kind": "StorageClass", "metadata": { "annotations": { "storageclass.kubernetes.io/is-default-class": "true" }, "name": "standard-csi", }, "provisioner": "cinder.csi.openstack.org", "reclaimPolicy": "Delete", "volumeBindingMode": "WaitForFirstConsumer" } Expected results: { "apiVersion": "storage.k8s.io/v1", "kind": "StorageClass", "metadata": { "annotations": { "storageclass.kubernetes.io/is-default-class": "true" }, "name": "standard-csi", }, "provisioner": "cinder.csi.openstack.org", "reclaimPolicy": "Delete", "volumeBindingMode": "WaitForFirstConsumer", "allowVolumeExpansion": true } Additional info: I ran a quick test as part of the 4.7 hackathon of this and it seems the StorageClass is created without ~~~ allowVolumeExpansion: true ~~~ As this can not be changed without recreating the StorageClass and it is a very handy feature, I wanted to make sure that this is intended as it is shown as "ALLOWVOLUMEEXPANSION" true in the documentation draft. 4.7.0-fc.2 ShiftStack IPI on 16.1: ~~~ [stack@osp16amd ocp-test1]$ oc get storageclass NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE standard (default) kubernetes.io/cinder Delete WaitForFirstConsumer true 8h standard-csi cinder.csi.openstack.org Delete WaitForFirstConsumer false 8h ~~~ Documentation: ~~~ NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE standard(default) cinder.csi.openstack.org Delete WaitForFirstConsumer true 46h standard-csi kubernetes.io/cinder Delete WaitForFirstConsumer true 46h ~~~
Notes from bug scub: * a workaround exists * this is not a regression, as 4.6 did not have this functionality We still tentatively target 4.7, with low priority.
*** This bug has been marked as a duplicate of bug 1906274 ***