Red Hat Bugzilla – Bug 1469001
[RFE] Allow to specify global default FSType for volumes
Last modified: 2017-11-28 17:00:46 EST
Description of problem: When a storageclass is created, you cannot specify fstype therefor, the volumes are created using ext4 (the default filesystem) In Azure using ext4 a 10gi volumes takes ~7,5 minutes, so the deploy fails. I've tried by setting the parameter in the storageclass definition but it complains: 2017-07-10 08:10:26 +0000 UTC 2017-07-10 08:10:26 +0000 UTC 1 mypvc PersistentVolumeClaim Warning ProvisioningFailed {persistentvolume-controller } Failed to provision volume with StorageClass "default": invalid option Version-Release number of selected component (if applicable): oc v3.5.5.26 kubernetes v1.5.2+43a9be4 features: Basic-Auth GSSAPI Kerberos SPNEGO Server https://emingueztst.eastus2.cloudapp.azure.com:8443 openshift v3.5.5.26 kubernetes v1.5.2+43a9be4 How reproducible: Create an OCP environment with the latest released bits in Azure, create a storageclass with fsType: xfs parameter and observe the logs Steps to Reproduce: 1. cat <<EOF | oc create -f - kind: StorageClass apiVersion: storage.k8s.io/v1beta1 metadata: name: "default" annotations: storageclass.beta.kubernetes.io/is-default-class: "true" volume.beta.kubernetes.io/storage-provisioner: kubernetes.io/azure-disk provisioner: kubernetes.io/azure-disk parameters: storageAccount: sapv1emingueztst fsType: xfs EOF 2. cat <<EOF | oc create -f - apiVersion: v1 kind: PersistentVolumeClaim metadata: name: mypvc spec: accessModes: - ReadWriteOnce resources: requests: storage: 10Gi EOF 3. oc get events -w LASTSEEN FIRSTSEEN COUNT NAME KIND SUBOBJECT TYPE REASON SOURCE MESSAGE 2017-07-10 08:16:08 +0000 UTC 2017-07-10 08:10:26 +0000 UTC 24 mypvc PersistentVolumeClaim Warning ProvisioningFailed {persistentvolume-controller } Failed to provision volume with StorageClass "default": invalid option "fsType" for volume plugin kubernetes.io/azure-disk Actual results: No PV is created and the PVC is stucked in "pending" Expected results: PV is created and formated with the proper "fsType" Master Log: Attached Node Log (of failed PODs): Attached PV Dump: no pv is created PVC Dump: See up StorageClass Dump (if StorageClass used by PV/PVC): See up Additional info: Upstream issue: https://github.com/kubernetes/kubernetes/issues/37804
Created attachment 1295728 [details] master api and controller logs, node logs.
I think there is an upstream PR related https://github.com/kubernetes/kubernetes/pull/45345
Indeed, we're working on this upstream and we need it merged there first, as it changes API.
The feature wont be available until 1.8 and is RFE.
Origin PR: https://github.com/openshift/origin/pull/16232
Tested on v3.7.0-0.143.1 On OpenStack and vSphere it works well. On Azure, it failed with 'invalid option "fstype" for volume plugin kubernetes.io/azure-disk': Name: pvc-454ge Namespace: 454ge StorageClass: storageclass-454ge Status: Pending Volume: Labels: name=dynamic-pvc Annotations: volume.beta.kubernetes.io/storage-provisioner=kubernetes.io/azure-disk Capacity: Access Modes: Events: FirstSeen LastSeen Count From SubObjectPath Type Reason Message --------- -------- ----- ---- ------------- -------- ------ ------- 19s <invalid> 3 persistentvolume-controller Warning ProvisioningFailed Failed to provision volume with StorageClass "storageclass-454ge": invalid option "fstype" for volume plugin kubernetes.io/azure-disk StorageClass: ``` --- apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: storageclass-454ge annotations: storageclass.beta.kubernetes.io/is-default-class: 'false' provisioner: kubernetes.io/azure-disk parameters: fstype: xfs ```
I checked the code in v3.7.0-0.158.0 and it looks like this has been fixed in rebase to latest Kubernetes 1.7.x.
Verified that fstype is supported in the storageclass and works for the block devices.
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/RHSA-2017:3188