Terraform-provider-aws: aws_ecs_service fails adding tags on resources created before AWS introduced tags on ECS

[ebarault]

Terraform Version

Terraform v0.11.11
terraform-aws-provider 1.57.0

Affected Resource(s)

• aws_ecs_service

Terraform Configuration Files

resource "aws_ecs_service" "example" {
  tags {
    tag1 = "value"
    tag2 = "value"
  }
}

Output

* aws_ecs_service.example: error tagging ECS Cluster (xxxxxxxx): InvalidParameterException: Long arn format must be used for tagging operations
    status code: 400, request id: xxxxxxxxxx

Expected Behavior

would create tags

Actual Behavior

fails with the above message

Steps to Reproduce

1. Opt-in for

Log in as root account, and opt in for new ARN and resource ID format.

1. Add tag to an ECS service created before AWS introduced tags on ECS services without the terraform aws_ecs_service module

2. terraform apply

References

https://github.com/terraform-providers/terraform-provider-aws/issues/6481

[bflad]

Hi @ebarault 👋 Sorry for the trouble here. Unfortunately this behavior is determined by the ECS service itself. While opting in to the longer format ARNs allows new ECS clusters and services to take advantage of the new tagging feature, existing ECS clusters and services must be migrated (e.g. recreated) to also utilize the same feature. Older ECS services in particular have an incompatible ARN for tagging due to its ambiguous format not including the cluster.

For more information about the ECS ARN changes and migration strategies, please see these AWS references:

• https://aws.amazon.com/blogs/compute/migrating-your-amazon-ecs-deployment-to-the-new-arn-and-resource-id-format-2/ (notably the blue/green deployment of an opted-in cluster and service)
• https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-resource-ids.html#ecs-resource-ids-working-with

Since the ECS service does not have functionality to automatically migrate existing infrastructure to the longer ARN format for the Terraform AWS provider to implement nor would we setup any form automatic ECS cluster/service recreation (causing downtime) or migration (complexity), I'm going to close this issue. Please do reach out if we are missing anything here though.

[pecigonzalo]

Wouldnt it be better to make it a "recreate" change if we detect the short to long format change? That way it does not "plan" fine but then break on apply.

[barnharts4]

Additionally, is there any way to have the tags element fail silently on ECS resources created with the older, short ARNs? I need my ECS module (including tags) to correctly tag if the ARN supports it, and to ignore tagging on accounts/roles that don't support it.

Or is there another, easier way to accomplish this?

[bflad]

Wouldnt it be better to make it a "recreate" change if we detect the short to long format change? That way it does not "plan" fine but then break on apply.

@pecigonzalo Are you suggesting that the aws_ecs_service resource, when it already exists with the short ARN notices a tags addition that it automatically mark the resource for recreation during plan?

Its technically possible via CustomizeDiff, but CustomizeDiff has a few caveats for its usage so it could only be implemented as "best effort" support for the behavior.

Additionally, is there any way to have the tags element fail silently on ECS resources created with the older, short ARNs? I need my ECS module (including tags) to correctly tag if the ARN supports it, and to ignore tagging on accounts/roles that don't support it.

@barnharts4 since Terraform is designed to be declarative, we strongly prefer the Terraform AWS provider to error in cases where it cannot perform the actions required to converge on a given configuration. Typically if a resource does not converge for a configuration, we would consider that a bug as that is a general design tenet for Terraform that operators have grown to expect.

If we were to bypass the specific InvalidParameterException: Long arn format must be used for tagging operations error, Terraform plans would constantly show a difference to add the tags for those resources to which it couldn't apply. The only option then for operators would be to use the lifecycle configuration of ignore_changes = ["tags"] on the resource.

Or is there another, easier way to accomplish this?

If you already have a Terraform module, you can do something like the below (sorry if its a little off, untested) to create a new boolean variable that is used to determine whether or not to include tags per module declaration.

# calling configuration
module "my_ecs_service" {
  # ... other configuration ...
  tagging_disabled = "true"
}

# module configuration
variable "tagging_disabled" {
  default = "false"
}

resource "aws_ecs_service" "example" {
  # ... other configuration ...
  tags = "${
    var.tagging_disabled == "true" ?
    map() :
    map(
      "TagKey1", "TagValue1",
    )
  }"
}

Omitting the new variable allows new ECS services to be appropriately tagged, while older ECS services age out over time and the flag can be removed when its no longer necessary.

---

As a side note: we will have the ability to display warnings instead of binary success/error after Terraform 0.12, the Terraform Provider SDK is updated with that enhancement, and then the Terraform AWS Provider is updated with that SDK. Although even with the ability for warnings, operators would be still receiving that warning every apply in this scenario, should the error be converted to a warning.

[hashibot[bot]]

I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.

If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thanks!