Bug 1469001 - [RFE] Allow to specify global default FSType for volumes
[RFE] Allow to specify global default FSType for volumes
Status: CLOSED ERRATA
Product: OpenShift Container Platform
Classification: Red Hat
Component: Storage (Show other bugs)
3.5.0
Unspecified Unspecified
unspecified Severity low
: ---
: 3.7.0
Assigned To: Jan Safranek
Jianwei Hou
: NeedsTestCase
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-07-10 04:28 EDT by Eduardo Minguez
Modified: 2017-11-28 17:00 EST (History)
4 users (show)

See Also:
Fixed In Version: v3.7.0-0.158.0
Doc Type: Enhancement
Doc Text:
Feature: Storage classes now support configuration of filesystem that should be created on dynamically provisioned volumes. In previous releases it was hardcoded to "ext4", which might not be optimal for some applications.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-11-28 17:00:46 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
master api and controller logs, node logs. (15.43 MB, application/x-xz)
2017-07-10 04:34 EDT, Eduardo Minguez
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Bugzilla 1500247 None CLOSED Azure disk: Failed to provision if storage class has no parameters 2018-03-22 06:05 EDT

  None (edit)
Description Eduardo Minguez 2017-07-10 04:28:22 EDT
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
Comment 1 Eduardo Minguez 2017-07-10 04:34 EDT
Created attachment 1295728 [details]
master api and controller logs, node logs.
Comment 2 Eduardo Minguez 2017-07-10 04:35:35 EDT
I think there is an upstream PR related https://github.com/kubernetes/kubernetes/pull/45345
Comment 3 Jan Safranek 2017-07-10 10:32:04 EDT
Indeed, we're working on this upstream and we need it merged there first, as it changes API.
Comment 4 Bradley Childs 2017-07-12 10:22:36 EDT
The feature wont be available until 1.8 and is RFE.
Comment 5 Jan Safranek 2017-09-08 04:20:26 EDT
Origin PR: https://github.com/openshift/origin/pull/16232
Comment 7 Jianwei Hou 2017-10-09 06:30:11 EDT
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
```
Comment 8 Jan Safranek 2017-10-17 09:21:37 EDT
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.
Comment 13 Jianwei Hou 2017-11-16 22:03:52 EST
Verified that fstype is supported in the storageclass and works for the block devices.
Comment 16 errata-xmlrpc 2017-11-28 17:00:46 EST
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

Note You need to log in before you can comment on or make changes to this bug.