-
Notifications
You must be signed in to change notification settings - Fork 9.1k
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
Not idempotent for aws_route_table_association #6556
Comments
I think this is related to #561 . |
Hi folks 👋 My suggestion here would be to try this in Terraform 0.12 and later to see if the issue still persists. There are also notable improvements for the Of note: Terraform 0.12.6 which was just released, now has support for the resource-level |
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! |
This issue was originally opened by @RuBiCK as hashicorp/terraform#19435. It was migrated here as a result of the provider split. The original body of the issue is below.
Terraform Version
Terraform v0.11.10
Affected resources
aws_route_table_association
Expected Behavior
I have a var that defines subnets with tags to indicate if a subnet is public
I create a resource aws_route_table that I associate to certain subnets found by data aws_subnet_ids
It's expected to be idempotent if I run many times
terraform apply
The subnet id to be associated needs to be computed (in my case) and after gather all information, terraform should check that association exists or not instead of delete and create the same association.
Actual Behavior
Between first and second apply the route_table_association gets removed and recreated again for each apply:
plan:
apply:
Steps to Reproduce
terraform plan
terraform apply
terraform apply
Output
Debug log
Additional Context
References
The text was updated successfully, but these errors were encountered: