-
Notifications
You must be signed in to change notification settings - Fork 813
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use new client token when CreateVolume
returns IdempotentParameterMismatch
#2075
Use new client token when CreateVolume
returns IdempotentParameterMismatch
#2075
Conversation
dadb2ef
to
0aaf246
Compare
Code Coverage Diff
|
8725a56
to
f0bb44e
Compare
CreateVolume
returns IdempotentParameterMismatch
CreateVolume
returns IdempotentParameterMismatch
/retest |
1 similar comment
/retest |
1395040
to
c691175
Compare
Signed-off-by: Connor Catlett <[email protected]>
Signed-off-by: Connor Catlett <[email protected]>
…match Signed-off-by: Connor Catlett <[email protected]>
c691175
to
0a0d5ef
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: AndrewSirenko The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs 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?
Fixes #1951
What is this PR about? / Why do we need it?
If
CreateVolume
fails for any reason (examples: the user provides an invalid KMS key, due to an EBS-side issue, etc), we retry with the same client token. However, despite the fact that theCreateVolume
call corresponds to a volume that was never created, our client token is burned.In the scenario where we detect this has occurred, this PR tries again with a different token. However, to prevent volume leaks, the token must follow a predictable pattern. To do this, I append
-2
to the volume id pre-hashing for the token, and if that request fails, I instead append-3
,-4
, etc. This is done strictly in order, so a CSI driver that crashes (or restarts for any other reason, such as an upgrade) can consistently reuse the same tokens until it reaches the 'correct' token.To keep track of which token we have most recently used during runtime, I use an expiring cache, similar to the existing "likely bad names" cache implementation. In order to DRY up the code, the first two commits of this PR migrate that implementation to the
util
package (commit 1) and then migrate the existinglikelyBadNames
implementation to use theutil
version (commit 2). Finally, this PR implements the above described change using this cache (commit 3).What testing is done?
Added/updated unit tests, CI, manual