Open scott-doyland-burrows opened 1 year ago
Voting for Prioritization
Volunteering to Work on This Issue
I'm seeing this when using "allow_overwrite" = true. I was unable to update a r53 entry as after 8 months it started with "Error: creating Route 53 Record: InvalidChangeBatch: [Tried to create resource record set [name='SOMEURL.', type='A'] but it already exists]. After setting "allow_overwrite" = true. It sets the correct r53 entry and tears it down right after. This is an alias record point to cloudfront. If I apply a second time it creates successfully but on next apply it will create then destroy.
module.api-gateway.aws_route53_record.route_53_record: Still creating... [10s elapsed] module.api-gateway.aws_route53_record.route_53_record: Still creating... [20s elapsed] module.api-gateway.aws_route53_record.route_53_record: Still creating... [30s elapsed] module.api-gateway.aws_route53_record.route_53_record: Creation complete after 32s [id=] module.api-gateway.aws_route53_record.route_53_record (deposed object 0ba71cfb): Destroying... [id=] module.api-gateway.aws_route53_record.route_53_record: Still destroying... [id=] module.api-gateway.aws_route53_record.route_53_record: Still destroying... [id=] module.api-gateway.aws_route53_record.route_53_record: Still destroying... [id=] module.api-gateway.aws_route53_record.route_53_record: Still destroying... [id=]
The +/-
"icon" on the proposed changes suggests that these resources are in a dependency chain with something that has create_before_destroy = true
set, and so they too must use that ordering of the replacement steps to make the resulting order of operations coherent.
However, you can't have two Route53 record objects with the same name at the same time. This should therefore fail at the create step due to the conflict with an existing object, except that these resources are all configured as allow_overwrite = true
which allows the create step to overwrite the existing object.
Therefore the effective order of operations is:
[redacted].theandpartnership.com.tandp.[redacted].digital
record with a new one.[redacted].theandpartnership.com.tandp.[redacted].digital
.Step 2 deleted the object created by step 1, leaving you with no records at all.
Therefore the observed behavior seems to be correct per the configuration, although of course I understand that it's undesirable.
Removing the allow_overwrite = true
argument should at least make step 1 fail and thus block step 2 from happening at all. But to make this actually work would require the destroy to happen before the create and thus for you to tolerate a brief interval where there's no DNS record at all, which might be problematic if the absence of a record gets cached somewhere.
I think this situation could only be improved by somehow arranging for aws_acm_certificate
to return a known value for the resource_record_name
attribute of each of the domain_validation_options
objects, which would therefore allow the aws_route53_record
resource instances to see that the Route53 record names are (presumably?) not actually changing and so could treat those as in-place update instead of replace. However, I don't know if the provider can gather enough information for aws_acm_certificate
to be able to predict the resource_record_name
during the planning step.
Terraform Core Version
v1.5.1
AWS Provider Version
v4.67.0
Affected Resource(s)
aws_route53_record
Expected Behavior
Route53 records do not get destroyed at the end of the apply.
Actual Behavior
Route53 records are getting destroyed.
Relevant Error/Panic Output Snippet
Terraform Configuration Files
Steps to Reproduce
terraform apply
Debug Output
Here is an apply when I am adding in a new
local.alternative_domains
to the list, as can be see, terraform destroys the route53 records, and there are mentions ofdeposed object
.It is a lot of output, but essentially at the end you can see it is destroying all the route53 records, even though they should be replaced (destroyed/created) according to the output from the plan.
Panic Output
N/A
Important Factoids
The code generates a certificate, route53 certificate validation records, and lastly a certificate validation.
There are a few other things that happen in other
.tf
files, essentially various AWS infrastructure uses the certifcates.If I update the
local.alternative_domains
by adding/deleting a domain, and then apply, it all works OK, except the route53 records are destroyed at the end of the apply, and I need a second apply to add them back again.I cannot work out why the route53 records are destroyed. The plan does not say this will happen.
Note the mention of various deposed object as well.
This happens every time I make a
local.alternative_domains
update - and of course I have made sure I start from clean environment to check there is nothing broken in the statefile.References
https://github.com/hashicorp/terraform/issues/33507#issuecomment-1630984060
Would you like to implement a fix?
None