Bug 2033518

Summary:	[aws-efs-csi-driver]Should not accept invalid FSType in sc for AWS EFS driver
Product:	OpenShift Container Platform	Reporter:	Rohit Patil <ropatil>
Component:	Storage	Assignee:	Roman Bednář <rbednar>
Storage sub component:	Operators	QA Contact:	Rohit Patil <ropatil>
Status:	CLOSED ERRATA	Docs Contact:
Severity:	low
Priority:	unspecified	CC:	aos-bugs, jsafrane, wduan
Version:	4.10
Target Milestone:	---
Target Release:	4.10.0
Hardware:	All
OS:	All
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2022-03-10 16:34:34 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Comment 3 Wei Duan 2021-12-20 03:56:43 UTC

@Jan, yes I agree the root cause is the CSI Driver doesn't respect the fsType, every fsType will be propagate to pv info even using a invaild value like "aaaa", and the fix should be reject such provisioning.
On the other hand, EFS actually don't support the XFS or EXT3/4, so FSType: "" also stands for the same meaning here? Is it possible to disable it to avoid the confusing?

Comment 4 Jan Safranek 2021-12-20 13:53:49 UTC

I think that FSType: "" is OK to show that it's not known / default. For block volume based volumes it's useful to show if it's ext4 or XFS (if Kubernetes knows it), because it may behave differently, but for EFS there is no such choice, it's always NFS.

Comment 8 Rohit Patil 2022-01-28 15:20:34 UTC

Verified. 
Status: PASS

Release Version: 4.10.0-0.nightly-2022-01-27-221656
EFS Version: 4.10.0-202201261535

Tests:
1) With fstype: efs: pod running fine. 
rohitpatil@ropatil-mac dynamicprovi_done % oc describe pv pvc-952c5342-13e1-48e8-9fa2-6c58c1c8993c -n testefs
Source:
    Type:              CSI (a Container Storage Interface (CSI) volume source)
    Driver:            efs.csi.aws.com
    FSType:            efs
    VolumeHandle:      fs-041b39066187fbf36::fsap-0011da27dc6d91cc9


2) With nonfstype parameter: pod running fine.
rohitpatil@ropatil-mac dynamicprovi_done % oc describe pv  pvc-873afa64-066d-4e9f-8df0-08b1320d1a07 -n testefs
Source:
    Type:              CSI (a Container Storage Interface (CSI) volume source)
    Driver:            efs.csi.aws.com
    FSType:            
    VolumeHandle:      fs-041b39066187fbf36::fsap-05699bded0750b1cc


3) With any other fstypes parameter: pod/pvc will be in pending state with error message:
rohitpatil@ropatil-mac dynamicprovi_done % oc describe pvc efs-claim -n testefs
Events:
  Type     Reason                Age               From                                                                 Message
  ----     ------                ----              ----                                                                 -------
  Normal   Provisioning          3s (x6 over 34s)  efs.csi.aws.com_ip-10-0-79-158_6489a227-f449-47b5-9b31-1e8f0ab81f92  External provisioner is provisioning volume for claim "testefs/efs-claim"
  Warning  ProvisioningFailed    3s (x6 over 34s)  efs.csi.aws.com_ip-10-0-79-158_6489a227-f449-47b5-9b31-1e8f0ab81f92  failed to provision volume with StorageClass "efs-sc": rpc error: code = InvalidArgument desc = Volume capabilities not supported: invalid fstype: nfs

Comment 11 errata-xmlrpc 2022-03-10 16:34:34 UTC

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 (Moderate: OpenShift Container Platform 4.10.3 security update), 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-2022:0056