"diffs didn't match during apply" after updating to Terraform 0.7.7 #9444
Comments
|
It's a bit difficult to provide a code snippet to reproduce, but this is what the Terraform configuration looks like: |
|
^ yes, this! I was about to raise a ticket, I'm having the same issue and have debugged a bit. It looks like the list returned by splat (either when using element or the resource.*.id[count.index] syntax) is sorted lexicographically. terraform plan returns a list in numerical order of ID like: terraform apply seems to return a list in lexicographical order: Therefore, on apply, when count.index is 2, it's returning the 10th (indexed) resource when I was expecting the 3rd. Aside from configuring all the resources individually (in my case 32 of them 5 times) - I have not found a workaround and I am stuck with a partially applied state I cannot resolve. note: in my case, I'm having an issue with linking route53 resources to an aws_rds_instance resource with the same index. Since mine already exist, I'm getting a mismatch error, but if I were CREATING resources this would be even more problematic since 'mydb.2' record would be pointing at rds_instance.11 without my knowledge. |
|
Same issue as above but with template_file.user_data This is a very dangerous bug - just downed some production machines because of this. 😞 TF state file stores the data in lexicographical order When expanding in aws_instance resorce with splat: Everything that gets assigned to an instances gets shifted by number of entries if you have a count greater than 10. Our user_data script is customized based on the count index. Caused an issue in prod when all except 2 machines got wrong user-data scripts upon creation. |
|
Yeah. I gotta throw my dime in here too. Given so many folks rely on the behavior of |
|
Also trying to see how this fits with: From the 0.7.0 CHANGELOG:
|
|
Thanks for the pointer @jamtur01! Nope. Just tried sort() for the splatted list. Same issue. The resources are still being created with wrong user_data. |
|
Sample code that reproduces the issue. With count of 13 instances for example, everything above second instance gets skewed. Instance 3 gets userdata from 10 due to the sort below. |
|
We're experiencing this issue as well when there are more than 10 instances with interpolation, interpolation gets them in lexographical order. Thus, aws_instance.name.*.id with > 10 instances interpolates to aws_instance.name.0, .1, .10, .11, ... terraform plan gets it right, but terraform apply does not. This results in the above mismatch error when the apply realizes that the created instance does not match the one plan anticipated. I've verified that this is working in terraform 0.7.6 but broken in terraform 0.7.7. |
|
I'm still seeing this issue in Terraform 0.7.8 |
|
Got it reproduced, this is definitely not good behavior. |
|
In-memory reproduction: The output |
Fixes #9444 This appears to be a regression from 0.7.0, but there were no tests covering it so we missed it and changed the behavior at some point! Oh no. This PR make the ordering of multi-var access: `resource.name.*.attr` consistent: it is the ordering of the count, not the lexical ordering of the value. This allows behavior where two lists are indexed by count index and can be assumed to be related (for example user data for an aws instance, as shown in the above referenced issue). Two new context tests added to cover this case.
|
Fix in referenced PR, covered by regression tests now. |
Fixes hashicorp#9444 This appears to be a regression from 0.7.0, but there were no tests covering it so we missed it and changed the behavior at some point! Oh no. This PR make the ordering of multi-var access: `resource.name.*.attr` consistent: it is the ordering of the count, not the lexical ordering of the value. This allows behavior where two lists are indexed by count index and can be assumed to be related (for example user data for an aws instance, as shown in the above referenced issue). Two new context tests added to cover this case.
|
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. |
ghost
locked and limited conversation to collaborators
I just updated Terraform from 0.7.6 to 0.7.7. Running
terraform planon Terraform 0.7.6, but on Terraform 0.7.7 it shows the following changes:What's worse is that Terraform fails when trying to apply these changes:
The text was updated successfully, but these errors were encountered: