user-data forces new resource when you move from windows to linux

[davyt10]

Terraform v0.7.1

user-data forces new resource when you move terraform apply from windows to linux and vice versa

When I launch infrastructure on a windows platform and commit to code commit and a colleague on a linux platform pulls down down latest commit, user_data will want to force a new resource. I have verified this also happens from Linux to windows when the apply is done from the linux OS and latest commit pulled down from to windows.

I have ensured the file line endings are CRLF when running in windows and LF in in Linux as I had seen this mentioned as a potential issue.

This is a hindrance as I have to comment out user-data once an environment is launched to allow users on linux platforms platforms to manage the infrastructure without destroying the entire infrastructure with a terraform apply. This has obvious consequences if I ever want to increase the count of my instances since user-data is then commented out.

Anyone seeing this?

[levenaux]

My team is having this issue as well. Passing modules with user-data between MacBooks will cause the SHA to change. To stop this, we just add:
lifecycle { ignore_changes = [ "user_data" ] }

[davyt10]

Tested and working, thanks!

[mitchellh]

Are you specifying user data as a direct string or via the file function call?

[davyt10]

I am using the file function call.

On Aug 30, 2016, at 22:50, Mitchell Hashimoto notifications@github.com wrote:

Are you specifying user data as a direct string or via the file function call?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[Dchamard]

Having the same problem here in 7.0.1 using template_file resource in userdata.

[PeteGoo]

Same thing using template_file on 0.7.10. Windows users are getting a forced change to e.g. policies. Probably due to git autocrlf.

[jgeorgeson]

Still seeing this in 0.9.2. @PeteGoo I think it's definitely line endings. When I flip the script file's line endings the checksum once again matches the before side of the terraform plan output. But instead of saying nothing to do plan now says it has to deploy everything new. ☹️

[jgeorgeson]

I was able to recover by running terraform list and then running terraform state refresh -target=... on every resource after fixing the eol on the userdata script. So it wasn't just the eol but that was definitely the instigator.

[dtelaroli]

Same problem with terraform 1.11.11
It's not about new line char, because I use LF in both with vscode.

[teamterraform]

Hi all,

Terraform explicitly does not normalize line endings by platform, so you must ensure that nothing else in your workflow is causing line endings to be different by platform. Terraform does not automatically normalize line endings specifically because files loaded in to Terraform are often intended to be submitted to a remote system that may be running a different operating system and thus Terraform cannot predict with certainty which line ending convention would be appropriate.

In particular, it's important to ensure that your version control system is not rewriting line endings when pushing and pulling changes between platforms. For Git, one way to force that is to tell Git to treat the files in question as binary by placing a file called .gitattributes in the root of the repository, with content like the following:

*.tmpl binary
*.sh binary

You can find more details on this in GitHub's guide to line endings in Git.

We're going to close this now because unfortunately Terraform is working as expected here and the problem is with some other system (often Git) making unexpected changes to the files. Terraform itself cannot detect that this has happened or prevent it, so there's unfortunately nothing we can do within Terraform itself to avoid this problem.

Sorry for the long delay in responding. Hopefully the above is helpful to those who have encountered this problem.

[ghost]

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.