Bug 2142002

+++ This bug was initially created as a clone of Bug #2049319 +++

Description of problem:

This is an RFE to add support for fstype=efs to the ocf:heartbeat:Filesystem resource agent.

The RA fails with OCF_ERR_INSTALLED if the fstype_supported() function returns failure. fstype_supported() succeeds only if one of the following two conditions are met:
  - the fstype is already in /proc/filesystems
  - we find and load a kernel module called $FSTYPE and then it appears in /proc/filesystems

/proc/filesystems is normally a great way to check for supported filesystems, but it doesn't work for EFS. (Rather, it doesn't *fully* work. See note [1].)

Amazon provides a repo from which you can build package called amazon-efs-utils [2]. amazon-efs-utils provides the EFS mount helper (`mount.efs`). The EFS mount helper provides AWS-specific mount options like iam, accesspoint, awsprofile, etc. It also allows the user to configure added security [3]:

    When encryption of data in transit is declared as a mount option for your Amazon 
    EFS file system, the mount helper initializes a client stunnel process, and a 
    supervisor process called amazon-efs-mount-watchdog. ...
    
    Stunnel is an open-source multipurpose network relay. The client stunnel process 
    listens on a local port for inbound traffic, and the mount helper redirects NFS 
    client traffic to this local port.
    
    The mount helper uses TLS version 1.2 to communicate with your file system. 
    Using TLS requires certificates, and these certificates are signed by a trusted 
    Amazon Certificate Authority.

mount.efs is actually a wrapper for /sbin/mount.nfs4. When a user runs `mount -t efs` or `mount.efs`, it processes all of the extras that I alluded to above and then mounts the filesystem as nfs4. When you check /proc/mounts afterward, the FS looks like an NFS filesystem except for the server name.

This request is for the Filesystem resource agent to support fstype=efs so that users can take advantage of these extra features. We basically need to treat it as nfs4 except when we run the mount command during startup -- we should use `mount -t efs` rather than `mount -t nfs4`.


[1] An EFS filesystem can be mounted with fstype "nfs", which should work with the Filesystem resource agent but which doesn't provide the added features of the EFS mount helper.
[2] Manually installing the Amazon EFS client (https://docs.aws.amazon.com/efs/latest/ug/installing-amazon-efs-utils.html)
[3] Mounting file systems using the EFS mount helper (https://docs.aws.amazon.com/efs/latest/ug/efs-mount-helper.html)


EDIT: The fstype_supported() function is actually broken, and it has been since it was created 8 years ago. It returns success no matter what unless the OS is OpenBSD (the opposite of what it should do). The REAL reason for failure with fstype=efs is that it's treated as a non-cluster-safe filesystem whose device is a block device. I knew that would need to be fixed, but I assumed the fstype_supported() function would be the first issue.

-----

Version-Release number of selected component (if applicable):

resource-agents-4.1.1-98.el8_5.2

-----

How reproducible:

Always

-----

Steps to Reproduce:
1. Create an ocf:heartbeat:Filesystem resource with fstype=efs.

-----

Actual results:

"not installed" error at startup

-----

Expected results:

Filesystem resource starts and runs fine.

-----

Additional info:

We would want a z-stream for at least RHEL 8.4, for SAP support. If it's not too much trouble, it would be nice to get 8.1.z and 8.2.z for the same reason.

I hope RHEL 7 isn't necessary. People shouldn't be building new clusters on RHEL 7 at all, let alone clusters that require specific features that we've never supported.

https://github.com/ClusterLabs/resource-agents/commit/e2174244067b02d798e0f12437f0f499c80f91fe