Skip to content
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

Add default wait timeout for attachments from ACS #3914

Merged
merged 1 commit into from
Sep 22, 2023
Merged

Conversation

xxx0624
Copy link
Contributor

@xxx0624 xxx0624 commented Sep 20, 2023

Summary

Add a default wait timeout for handling attachment payload message from ACS if no waitTimeout is provided in the message. This can protect Agent from waiting for the attachment ready forever.

Implementation details

Add a the default wait timeout in attachment_resource_responder when processing the attachment payload message.

Testing

New tests cover the changes: no

Description for the changelog

Enhancement - add a default wait timeout for attachment payload messages.

Licensing

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

@xxx0624 xxx0624 requested a review from a team as a code owner September 20, 2023 00:25
@xxx0624 xxx0624 changed the title Add default wait timeout for attachments from ACS WIP - Add default wait timeout for attachments from ACS Sep 20, 2023
@xxx0624 xxx0624 changed the title WIP - Add default wait timeout for attachments from ACS Add default wait timeout for attachments from ACS Sep 20, 2023
ecs-agent/acs/session/attach_resource_responder.go Outdated Show resolved Hide resolved
@@ -194,7 +205,7 @@ func validateAttachmentAndReturnProperties(message *ecsacs.ConfirmAttachmentMess
return attachmentProperties, nil
}

// For "EphemeralStorage" and "ElasticBlockStorage", ACS is using resourceType to indicate its attachment type.
// For legacy EBS volumes("EphemeralStorage" and "ElasticBlockStorage"), ACS is using resourceType to indicate its attachment type.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: For my understanding, is it appropriate referring to these storage means as legacy? Are we planning to deprecate them at any point already?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are we planning to deprecate them at any point already?

I don't think so. I think we will continue to support both but won't change them much.

I will confirm with @fierlion since this comment is from this PR https://github.com/aws/amazon-ecs-agent/pull/3911/files/9597f968e447852d88a3fb7d75a7a550fba24ffb#r1327869451

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

non-blocking: My comment's intent was to remove the words EphemeralStorage altogether. This is a nit but we should follow up and fix this comment.

@fierlion fierlion merged commit 784f3a5 into aws:dev Sep 22, 2023
36 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants