Reduce calls to EFS API#1226
Conversation
|
|
|
Welcome @otorreno! |
|
Hi @otorreno. Thanks for your PR. I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
b36b4ef to
a80e7b0
Compare
a80e7b0 to
e2489a5
Compare
|
@mskanth972 you may want to review this one as it is in the same area of code of #1217 |
e2489a5 to
693fe84
Compare
|
@mskanth972 rebased on top of latest master. Commit message and original comment for the PR updated, as I had to change gidMax instead of gidMin (because #1217 flipped the overriden param in case the range is too wide) |
With kubernetes-sigs#850, the new way of allocating GIDs introduced a new call to the ListAccessPoints endpoint of EFS API, that is generating problems on systems where EFS CSI driver is under high load (lots of PVC created within a short time period). In this PR, we are extracting the ListAccessPoints call from gid_allocator, moving it one level up. In case of dynamic provisioining of GIDs we can reuse the ListAccessPoints call to check for the file system existence (thus removing the DescribeFileSystem call in such case). In case of a fixed UID/GID, we continue calling DescribeFileSystem, and no calls to ListAccessPoints. In addition to the change explained above, gidMin and gidMax have been converted to int64. kubernetes-sigs#850 made both uid and gid int64, but gidMin and gidMax were nout touched. Also changing the default value for gidMax, as the value of 7000000 was spamming the logs with a message coming from gid_allocator (i.e. range bigger than the max number of access points). Setting the value to 51000 (the value that gid_allocator was setting by adding 1000 to gidMin). Removing an unused function and field from gid_allocator too.
693fe84 to
dbbc733
Compare
|
/ok-to-test |
|
/lgtm |
|
/approve |
Thank you for the review! |
|
/test pull-aws-efs-csi-driver-unit |
|
/approve |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: mskanth972, otorreno The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Is this a bug fix or adding new feature?
Bug fix
What is this PR about? / Why do we need it?
With #850, the new way of allocating GIDs introduced a new call to the ListAccessPoints endpoint of EFS API, that is generating problems on systems where EFS CSI driver is under high load (lots of PVC created within a short time period). In this PR, we are extracting the ListAccessPoints call from gid_allocator, moving it one level up. In case of dynamic provisioining of GIDs we can reuse the ListAccessPoints call to check for the file system existence (thus removing the DescribeFileSystem call in such case). In case of a fixed UID/GID, we continue calling DescribeFileSystem, and no calls to ListAccessPoints.
In addition to the change explained above, gidMin and gidMax have been converted to int64. #850 made both uid and gid int64, but gidMin and gidMax were nout touched. Also changing the default value for gidMax, as the value of 7000000 was spamming the logs with a message coming from gid_allocator (i.e. range bigger than the max number of access points). Setting the value to 51000 (the value that gid_allocator was setting by adding 1000 to gidMin). Removing an unused function and field from gid_allocator too.
What testing is done?
Coverage with unit tests