-
Notifications
You must be signed in to change notification settings - Fork 9.7k
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
aws_route53_record keeps wanting to change when passing aws_elb.dns_name #10004
Comments
Having this issue, too. |
I'm seeing, based on a comment from #9628, that there is a difference in the to/from DNS names - namely a dot at the end. However, it's the Route53 record that apparently has the dot? Not what is calculated from the aws_elb.dns_name. Even if I manually inject a '.' in the alias.name, it isn't coming through to the plan. |
So - I don't know what's going on with the '.' in the record. I have 26 Route53 resources defined, all identically. I've added a lower(...) on the aws_elb.name reference, because the ELB has uppercase characters and Route53 internally converts to lower. However, 5/26 (only 5!) still have this "dot at the end" churn between what the internal state is and what's defined in the config. If I add a |
We are also seeing this issue in Terraform 0.7.13. |
Seeing this as well. I think it has something to do with elb zone_id - In looking at my ELBs, I see one zone_id across all my internal ELBs and a different one across all my external ELBs. For a diff that I see on an route53 record for an internal ELB, the diff seems to indicate that it needs to change from the external zone_id back to the internal one - no idea why it has the external one in the state. |
I'm seeing the same problem on Terraform 0.7.13 as well. |
I'm still seeing this issue in Terraform v0.8.2 |
@wr0ngway is right. Seems like AWS automatically assigns the elb zone_id and terraform is fighting to change it. Manually configuring zone_id resolves this issue. For example, when seeing this issue
manually set the zone_id.
This isn't ideal, wondering if alias zone_id should be required when assigning it to elb? Or is this an AWS issue not revealing the right zone_id? |
I struggled with this exact same issue for quite a while before discovering that there's a case-sensitive compare between the load balancer name and the Route53 record that can cause this. I had used a capital letter in naming my load balancer Using the example provided by @deanmraz Route53 always wanted to make the following changes: Making the name of the load balancer all lowercase in Terraform resolved the issue for me. |
@rts-rob you've also got the |
Confirmed on TF 0.9.2. Our ELB has an all lowercase name already. |
i installed 0.9.4 but i still get this issue...can someone please post a fix method that was verified... |
@CpuID The name isn't the issue. Its the zone_id. After the first terraform apply, state's get updated with a zone id that is not used on subsequence requests. Updating to the zone id to the "changed" value manual resolves the issue, so maybe terraform isn't storing the right zone id? Also, wondering if private VPC layers are causing this issue for a few and not for others. |
@deanmraz seems legit, haven't traced the code but sounds logical. |
Use the
Also use the built-in |
Using the |
@albanf please edit your recent comment to use Markdown code blocks. Thank you. |
Terraform Version
I am still experiencing the issue.
|
I had this problem too. Turned out that the same DNS entry was being created twice, each pointing to a different thing. Naturally, one of the entries would always see that it had been overwritten every time I ran a terraform plan. |
I'm also having this issue. I'm on 0.11.8. |
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 have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further. |
Terraform Version
Confirmed on 0.7.9 and 0.7.10
Affected Resource(s)
Debug Output
Expected Behavior
Not require a change, display message: No changes...
Actual Behavior
Always requires a change. Notice the appending "." in alias.555.name compared to alias.777.name. Applying then running plan will continue this endless loop of this change.
Steps to Reproduce
Please list the steps required to reproduce the issue, for example:
Important Factoids
References
The text was updated successfully, but these errors were encountered: