Import a new object in place of an existing object (combined "state rm" and "import")

[sj26]

Current Terraform Version

$ terraform version
Terraform v1.0.0
on darwin_arm64
+ provider registry.terraform.io/cloudflare/cloudflare v2.21.0
+ provider registry.terraform.io/datadog/datadog v2.26.1
+ provider registry.terraform.io/hashicorp/aws v3.43.0
+ provider registry.terraform.io/hashicorp/cloudinit v2.2.0

Use-cases

We have an aws_ecs_task_definition which is updated by an external tool to bump the container image version. But terraform is still responsible for the general shape of the task definition, including adding environment variables and secrets based on infrastructure requirements. This means we always have a dirty terraform resource despite there being no changes.

To avoid this, we're doing something like this before doing a plan/apply cycle in terraform:

terraform state rm aws_ecs_task_definition.acme
terraform import aws_ecs_task_definition.acme acme:latest

... but there's a potential race condition between these two commands.

Attempted Solutions

We've tried a few solutions for our underlying problem, this seems like the least worst compromise. I haven't found another way to do resource replacement without a potential race condition in the middle.

Proposal

What I'd really like to do is a single command which avoids the "already exists" failure mode of import and proceeds anyway:

terraform import -replace=true aws_ecs_task_definition.acme acme:latest

I don't think it needs to formally destroy any resources which are replaced.

References

The general shape of our underlying problem is this one: hashicorp/terraform-provider-aws#632

If there were a way to track the "latest" task definition version as a terraform resource this might not be a problem, but that seems like a hard sell in the aws provider. But allowing import to replace a resource still seems like a reasonable thing, too.

[apparentlymart]

Thanks for sharing this use-case, @sj26!

We're planning to redesign the import mechanism in a forthcoming release, to integrate with the normal plan/apply process in a similar way as we've been doing in recent releases with features like the -replace argument, and so when we do so we'll consider this use-case of potentially combining it with a request to "forget" an existing object and bind a different existing object in its place, as you've described here.

I expect that the final design of this will come as something additional during terraform plan and terraform apply rather than as continued additions to the terraform import command, because that's the way we're generally moving in design philosophy (to make sure all actions can potentially be committed to the state atomically), but we've not yet done detailed design for import in particular and so that does still remain to be seen.

Thanks again!