terraform-provider-aws: EC2 instance recreation due to unexpected user_data change
Community Note
- Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
- Please do not leave “+1” or “me too” comments, they generate extra noise for issue followers and do not help prioritize the request
- If you are interested in working on this issue or have submitted a pull request, please leave a comment
Terraform Version
Terraform v0.11.3 AWS Provider: 1.20.0
Affected Resource(s)
- aws_instance
Description
Not really sure what happened as my plan (remote) was up to date. I did not change any resource definition nor updated terraform or aws provider. Those resources were written months ago, plus one of those EC2 instances is stopped on AWS.
When I run terraform plan suddenly I see my plan wants to recreate some of my EC2 instances (not sure why those not others). From the plan I see the reason is change/update to user_data. Note I do not use or rely on user_data I ommit it completely in my resources.
user_data: "da39a3ee5e6b4b0d3255bfef95601890afd80709" => "" (forces new resource)
I need to use:
lifecycle {
ignore_changes = ["user_data"]
}
in order to ignore this.
Not sure if AWS did something under the hood? Started returning something extra in the API response? No clue here.
Please advice.
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Reactions: 48
- Comments: 17 (8 by maintainers)
Fantastic! I’ll make sure #4991 gets in for release tomorrow.
The
user_data: "" => "da39a3ee5e6b4b0d3255bfef95601890afd80709" (forces new resource)fix has been merged and will release with version 1.33.0 of the AWS provider, likely middle of next week.For any other potential cases, please open new issues following the bug report issue template. Thanks.
@bflad I have tested your branch in three of our affected environments and it resolves it completely.
user_data change should stop instance, update user_data itself and start it again. But even in AWS provider 1.34 it wants to create new resource. BTW both options are dangerous on production. So user_data should be ignored in lifecycle as well as AMI
Hello @bflad , I was wondering is there any reason why #4991 is done only one way (hash -> empty string and not empty string -> hash)?
We have instances created before the API started returning the hash and we are using 1.25 AWS provider version and the affected instances are in us-west-2 region. This leads to such change set which this PR does not resolve.
user_data: "" => "da39a3ee5e6b4b0d3255bfef95601890afd80709" (forces new resource)