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 ECS Task Metadata client #2813

Open
2 tasks
mdomsch-seczetta opened this issue Jan 6, 2023 · 3 comments
Open
2 tasks

Add ECS Task Metadata client #2813

mdomsch-seczetta opened this issue Jan 6, 2023 · 3 comments
Labels
feature-request A feature should be added or improved.

Comments

@mdomsch-seczetta
Copy link

mdomsch-seczetta commented Jan 6, 2023

Describe the feature

Similar to the existing Aws::EC2Metadata client class, it would be helpful to have a metadata client class that retrieves and presents data from the ECS Task Metadata endpoint described here: https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-metadata-endpoint-v4.html

While I could retrieve the response from the ECS Task Metadata endpoint and parse the Cluster field from it, having a built-in method to retrieve this would be simpler and cleaner, and is in keeping with how I get the EC2 instance ID already.

Use Case

I want to use this client class to let an application running in ECS on EC2 retrieve the name of the ECS Cluster name it is a part of, for use when calling UpdateContainerInstancesState https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateContainerInstancesState.html
. This method requires passing in the cluster name, as well as the EC2 instance ID, to set the status to a value. I want to set the status to DRAINING to prevent ECS from placing a task on an EC2 instance that is in one of the Terminating states, but ECS is not aware of this. Because I can control when an EC2 instance is put into a Terminating state, I can also put the ECS container instance state to DRAINING at the same time.

Proposed Solution

Implement similar to the Aws::EC2Metadata client class.

Other Information

No response

Acknowledgements

  • I may be able to implement this feature request
  • This feature might incur a breaking change

SDK version used

3.165.0

Environment details (OS name and version, etc.)

Ruby 3.1.2 on Linux, e.g. ruby:3.1.2-slim-bullseye from docker hub

@mdomsch-seczetta mdomsch-seczetta added feature-request A feature should be added or improved. needs-triage This issue or PR still needs to be triaged. labels Jan 6, 2023
@mullermp
Copy link
Contributor

mullermp commented Jan 6, 2023

Thanks for opening up a feature request. I do think this is a valid feature request for SDKs, but I am unsure on timeline of delivery and priority. I will share this with the organization.

@mullermp mullermp removed the needs-triage This issue or PR still needs to be triaged. label Jan 6, 2023
@tomdionysus
Copy link

It's worth mentioning that the current classes use the V2 Endpoint which is no longer maintained:

Screenshot 2024-03-21 at 12 06 07 PM

The endpoint still either defaults to - or is hardcoded to - 169.254.170.2 at multiple points in the SDK:

Screenshot 2024-03-21 at 12 04 32 PM

This should be refactored to use the V4 endpoint. I have encountered an issue in the last few days where the client can't connect to 169.254.170.2 for some containers.

@mullermp
Copy link
Contributor

mullermp commented Mar 21, 2024

This feature request is for a metadata client, similar to EC2Metadata that we provide in the SDK. The classes above are for credentials and are not supposed to hardcode a versioned endpoint. Neither of the V2 or V4 documentation linked mention usage for credentials fetching.

ECSCredentials should look at AWS_CONTAINER_CREDENTIALS_FULL_URI or AWS_CONTAINER_CREDENTIALS_RELATIVE_URI environment variables and those URIs may already have a v4 path.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature-request A feature should be added or improved.
Projects
None yet
Development

No branches or pull requests

3 participants