[manila-csi-plugin] Wait for access rule to become active after granting#3136
[manila-csi-plugin] Wait for access rule to become active after granting#3136gouthampacha wants to merge 1 commit into
Conversation
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
5bdf397 to
1e8ec3a
Compare
|
@gouthampacha: The following test failed, say
Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR. 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-sigs/prow repository. I understand the commands that are listed here. |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
Manila's GrantAccess API is asynchronous. The access rule starts in "queued_to_apply" state and transitions through "applying" before reaching "active". Both the NFS and CephFS share adapters were proceeding to mount immediately after granting access, which could fail if the backend had not yet applied the rule. Add a shared waitForAccessRuleActive helper that polls until the access rule reaches "active" state. On "error" state or timeout, the helper revokes the failed rule so the next reconcile retries cleanly. Both adapters now call this helper after GrantAccess. For CephFS, this replaces the previous wait loop that only checked for AccessKey population without verifying the rule state itself. Signed-off-by: Goutham Pacha Ravi <gouthampravi@gmail.com>
0f47826 to
4a1bf29
Compare
What this PR does / why we need it:
Manila's
GrantAccessAPI is asynchronous — the access rule starts inqueued_to_applystate and transitions throughapplyingbefore reachingactive. Both the NFS and CephFS share adapters were proceeding to mount immediately after granting access, which could fail if the backend hadn't applied the rule yet.This PR adds a shared
waitForAccessRuleActivehelper that polls until the access rule reachesactivestate. Onerrorstate or timeout, the helper revokes the failed rule so the next reconcile retries cleanly. Both adapters now call this helper afterGrantAccess.For CephFS, this replaces the previous wait loop that only checked for
AccessKeypopulation without verifying the rule state. Waiting foractivestate implicitly guarantees the key is populated since Manila assigns the cephx key as part of applying the rule.Which issue this PR fixes(if applicable):
fixes #3000
Special notes for reviewers:
Tested on a DevStack with both LVM (NFS) and native CephFS backends. Both protocols show the
queued_to_apply→activetransition, confirming the race window this fixes.Release note: