Add ECS Metadata Integration Test for detect changes in ECS Container Agent Metadata Endpoint #458
Conversation
Codecov Report
@@ Coverage Diff @@
## master #458 +/- ##
=======================================
Coverage 57.28% 57.28%
=======================================
Files 370 370
Lines 17346 17352 +6
=======================================
+ Hits 9936 9940 +4
- Misses 6824 6826 +2
Partials 586 586
Continue to review full report at Codecov.
|
| mac: {}, | ||
| "ec2_windows": {""}, | ||
| "ec2_mac": {}, | ||
| "ecs_fargate": { |
There was a problem hiding this comment.
We should try to run this from the root dir so we can use ./
There was a problem hiding this comment.
I would agree at some point. However, it would pose a different question? Would the developers prefer to look at the root dir or from the current path since for ECS Fargate test, it use
resource "null_resource" "validator" {
provisioner "local-exec" {
command = <<-EOT
EOT
}
}
instead of like EC2
resource "aws_instance" "integration-test" {
provisioner "remote-exec" {
}
Therefore, would prefer this path over root_dir. One more addition point to support mine, since I use reduce the variables by using local, so it would be also a pain for using the root dir if don't do something to the root dir.
There was a problem hiding this comment.
I would prefer using root.
There was a problem hiding this comment.
If you guys prefer root module, then its fine by me also. Fixed it in the newest commit.
| @@ -0,0 +1,57 @@ | |||
| [ | |||
There was a problem hiding this comment.
For the ECS set up can you write a README for what it all does? It's not easy for me to gleam without ECS experience
There was a problem hiding this comment.
Reasonable. I added how ECS Fargate is setup in the README.doc. Let's me know if its cover enough details for everyone.
| mac: {}, | ||
| "ec2_windows": {""}, | ||
| "ec2_mac": {}, | ||
| "ecs_fargate": { |
There was a problem hiding this comment.
I would prefer using root.
| "github.com/aws/amazon-cloudwatch-agent/integration/test" | ||
| ) | ||
|
|
||
| // Purpose: Detect the changes in metadata endpoint for ECS Container Agent https://github.com/aws/amazon-cloudwatch-agent/blob/master/translator/util/ecsutil/ecsutil.go#L67-L75 |
There was a problem hiding this comment.
How does verifying the existence of the log group indicate that the v4 metadata endpoint worked? Does this imply that if you use an ECS cluster that doesn't have the v4 endpoint, the log group wouldn't be created?
There was a problem hiding this comment.
To be more specifically a bit, during the scrapping metadata endpoint, it would extract the Region, ClusterName, TaskARN. After extracting those variables, it would create a log group based on that format that includes the ClusterName. So to speak, if the clustername which scrapped from metadataendpointv4 does not exist, then it would fail the test. So to your point, yes. Also if the ECS cluster does have the v5 endpoint but we have not updated that, then it would fail the test based on the aforementioned points.
Fixed #118 and continue of #453
Description of the issue
Adding an integration test which detect the changes in scrapping metadata URL when Container Agent Version changes.
Description of changes
Able to detect unnoticed changes in URL with ECS Fargate or EC2.
License
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.
Tests
terraform apply -auto-approve -lock=false -var="test_dir=../../../test/ecs/ecs_metadata/"to confirm there is a log group which has theclusternamewhich is scrap from metadata.Requirements
Before commit the code, please do the following steps.
make fmtandmake fmt-shmake linter