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.
Feature added upstream by commit e217424.
Hello Felix, We are evaluating including this in RHEL 8 & 9, however with our current lifecycle having this in RHEL 7 can only happen if this is a high priority critical customer request. Can you confirm that this is specifically for supporting SAP on RHEL? Or is this for other use cases as well? Best Regards, Kris Nickel
https://github.com/ClusterLabs/resource-agents/commit/e2174244067b02d798e0f12437f0f499c80f91fe
Hi, Sorry for the delay in commenting here. > We are evaluating including this in RHEL 8 & 9, however with our current lifecycle having this in RHEL 7 can only happen if this is a high priority critical customer request. Can you confirm that this is specifically for supporting SAP on RHEL? Or is this for other use cases as well? Yes, this is mostly for SAP, and I'm confident that releasing for RHEL8 and RHEL9 will cover most of our customers looking for it (if not all). I wouldn't be worried about RHEL7 at this time.