-
Notifications
You must be signed in to change notification settings - Fork 808
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
Only bail to AttachVolume if volume is detached #2183
Only bail to AttachVolume if volume is detached #2183
Conversation
Signed-off-by: Connor Catlett <conncatl@amazon.com>
Code Coverage DiffThis PR does not change the code coverage |
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
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.
Subtle fix thank you
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.
looks good to me thank you will definitely help when looking through the logs
/approve |
[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?
Bug fix
What is this PR about? / Why do we need it?
In
WaitForAttachmentState
, we bail to callingAttachVolume
and immediately returning an error if the volume was reported as attached byDescribeInstances
(i.e. ifalreadyAssigned
is true), but the volume returns a state other thanattached
. This check exists to guard against the case whereDescribeInstances
is incorrect, bailing early allows us to get the attachment moving and avoid sitting in an infinite loop until a timeout occurs.However, this is incorrect - we should only perform this action if the volume is
detached
, not all states other thanattached
. This is for two reasons:AttachVolume
call when the volume is in a state other thandetached
will almost always fail.DescribeInstances
but still report asattaching
viaDescribeVolumes
for a short period of time. In this case, we repeatedly error out at the earliest possible opportunity, preventingWaitForAttachmentState
's exponential backoff from working and peppering the AWS API with spuriousAttachVolume
calls.What testing is done?
Added new unit test. Note that although depending on the test name is a horrible practice we should remove from this test, I have not spent the significant effort that would be required in this small PR to fix it.