This is the part 2 of this feature as we faced multiple challenges while rebasing this feature to the current EFS CSI driver during the 4.17 cycle.

Epic Goal

Implement a new PV provisioning method with AWS EFS CSI driver. Instead of creating EFS access points, this new provisioning method would create sub-directories per PV.

An open PR from Jan 2022 aims to implement this but it is lacking reviews and needs some work to rebase and confirm it works as expected.

https://github.com/kubernetes-sigs/aws-efs-csi-driver/pull/732 

In part 2, we rebased the original epic and restructured the code to make it work as well as ensuring it passes unit tests. The upstream is up for reviews upstream

https://github.com/kubernetes-sigs/aws-efs-csi-driver/pull/1497

Since Red Hat is not a core approver of the EFS CSI git repo, the goal of this part 3 is to get reviews, apply any required changes and it get merged.

 
Why is this important? (mandatory)

There are two major limits with AWS EFS drivers

• 1000 PVs per SC due to the limitation of number of EFS access point. (less concerns)
• Limitations on setting UID/GID & permissions (i.e chown/chmod) because current dynamic provisioning create a sub EFS access point and it's not possible to chown from a top level access point.

The limitation on applying ownership/permissions is what bring the most complains from the field. A KB with more details is available https://access.redhat.com/solutions/7011821

The current provisioning method creates an EFS Access Points by default when dynamically provisioning Persistent Volumes. In these EFS Access Points, the PosixUser is set automatically, there is currently no possibility to disable this behaviour as this is managed on the EFS side.

Also see RFE-2907 for additional customer's requirements.

 
Scenarios (mandatory) 

Provide details for user scenarios including actions to be performed, platform specifications, and user personas.  

1. As an openshift user i want to be able to dynamically provisioning EFS volumes with CSI while still being able to control ownership / permission on a per volume fashion.

 
Dependencies (internal and external) (mandatory)

We need to workaround AWS EFS that prevents changing ownership.

This is a new feature in the EFS CSI driver, 

Contributing Teams(and contacts) (mandatory) 

Our expectation is that teams would modify the list below to fit the epic. Some epics may not need all the default groups but what is included here should accurately reflect who will be involved in delivering the epic.

• Development - STOR
• Documentation - STOR
• QE - STOR
• PX - 
• Others -

Acceptance Criteria (optional)

Code for new provisioning is merged and included in OCP EFS CSI driver

It passes the same tests as the current "efs-ap" provisioning mode. Assess product-ability if there is any feature regressions, security or performances impacts.

Drawbacks or Risk (optional)

New mode introduces any feature regressions, security or performances impacts that are not acceptable

Done - Checklist (mandatory)

The following points apply to all epics and are what the OpenShift team believes are the minimum set of criteria that epics should meet for us to consider them potentially shippable. We request that epic owners modify this list to reflect the work to be completed in order to produce something that is potentially shippable.

• CI Testing -  Basic e2e automationTests are merged and completing successfully
• Documentation - Content development is complete.
• QE - Test scenarios are written and executed successfully.
• Technical Enablement - Slides are complete (if requested by PLM)
• Engineering Stories Merged
• All associated work items with the Epic are closed
• Epic status should be "Release Pending"