provider/aws/aws_instance: template_file as user_data causes instance recreation

[smotti]

Update:

• Can be closed, provider/template: don't diff when there's no diff #1911 fixed it. Just ran a test with a dev version of the master branch.
• Version used is v0.5.0
• In IRC someone pointed me to this: provider/template: don't diff when there's no diff #1911 , i'll try and see if it works with master
• Ok this issue (provider/aws/aws_instance: template_file as user_data causes instance recreation #1962) seems to be a duplicate of: templates in user_data always cause a rebuild #1898
• Should also look at closed issues next time

Using template_file.myfile.rendered as user_data value always results in
recreation of the effected resource. The plan command shows a new hash
value for the user_data, but during the apply phase the hash value is again
the same as the old one.

For example we use a template_file to provide user_data to a new instance for
bootstrapping. The template file looks like this:

#!/bin/bash -xe

echo "${http_proxy}" > /tmp/http_proxy

The corresponding resource definition:

resource "template_file" "user_data_test" {
  filename = "user_data/test.txt"
  vars {
    http_proxy = "http://127.0.0.1:8888/"
  }
}

resource "aws_instance" "test" {
  ami = "ami-3238f032"
  instance_type = "t1.micro"
  user_data = "${template_file.user_data_test.rendered}"
  tags {
    Name = "Test Instance"
    Description = "Test template_file as user_data attribute value"
  }
}

The first apply looks like this:

$ terraform apply -target=aws_instance.test                                                                                                                                                                                                                                                               
template_file.user_data_test: Creating...
  filename:        "" => "user_data/test.txt"
  rendered:        "" => "<computed>"
  vars.#:          "0" => "1"
  vars.http_proxy: "" => "http://127.0.0.1:8888"
  template_file.user_data_test: Creation complete
  aws_instance.test: Creating...
  ami:                      "" => "ami-3238f032"
  availability_zone:        "" => "<computed>"
  ebs_block_device.#:       "" => "<computed>"
  ephemeral_block_device.#: "" => "<computed>"
  instance_type:            "" => "t1.micro"
  key_name:                 "" => "<computed>"
  placement_group:          "" => "<computed>"
  private_dns:              "" => "<computed>"
  private_ip:               "" => "<computed>"
  public_dns:               "" => "<computed>"
  public_ip:                "" => "<computed>"
  root_block_device.#:      "" => "<computed>"
  security_groups.#:        "" => "<computed>"
  subnet_id:                "" => "<computed>"
  tags.#:                   "" => "2"
  tags.Description:         "" => "Test template_file"
  tags.Name:                "" => "Test Instance"
  tenancy:                  "" => "<computed>"
  user_data:                "" => "f0fda1e1642030ab8e31861646b0cd37449b3e78"
  vpc_security_group_ids.#: "" => "<computed>"
  aws_instance.test: Creation complete

  Apply complete! Resources: 2 added, 0 changed, 0 destroyed.

Now we run a 'terraform plan' which refreshes that state and detects a
change in the user_data, and of course no change has been made to either
resource definition nor template_file or any of the vars:

$ terraform plan -target=aws_instance.test                                                                                                                                                                                                                                                       [49/1697]
Refreshing Terraform state prior to plan...

template_file.user_data_test: Refreshing state... (ID: e632bfdc2067790cd881)
aws_instance.test: Refreshing state... (ID: i-83822876)

The Terraform execution plan has been generated and is shown below.
Resources are shown in alphabetical order for quick scanning. Green resources
will be created (or destroyed and then created if an existing resource
exists), yellow resources are being changed in-place, and red resources
will be destroyed.

Note: You didn't specify an "-out" parameter to save this plan, so when
"apply" is called, Terraform can't guarantee this is what will execute.

-/+ aws_instance.test
    ami:                      "ami-3238f032" => "ami-3238f032"
    availability_zone:        "ap-northeast-1c" => "<computed>"
    ebs_block_device.#:       "0" => "<computed>"
    ephemeral_block_device.#: "0" => "<computed>"
    instance_type:            "t1.micro" => "t1.micro"
    key_name:                 "" => "<computed>"
    placement_group:          "" => "<computed>"
    private_dns:              "ip-172-31-27-23.ap-northeast-1.compute.internal" => "<computed>"
    private_ip:               "172.31.27.23" => "<computed>"
    public_dns:               "ec2-52-68-118-140.ap-northeast-1.compute.amazonaws.com" => "<computed>"
    public_ip:                "52.68.118.140" => "<computed>"
    root_block_device.#:      "1" => "<computed>"
    security_groups.#:        "0" => "<computed>"
    subnet_id:                "subnet-9d8381db" => "<computed>"
    tags.#:                   "2" => "2"
    tags.Description:         "Test template_file" => "Test template_file"
    tags.Name:                "Test Instance" => "Test Instance"
    tenancy:                  "default" => "<computed>"
    user_data:                "f0fda1e1642030ab8e31861646b0cd37449b3e78" => "c9717e77405425dc7c4165814d9c2f2be6c6a7ff" (forces new resource)
    vpc_security_group_ids.#: "1" => "<computed>"

+ template_file.user_data_test
    filename:        "" => "user_data/test.txt"
    rendered:        "" => "<computed>"
    vars.#:          "0" => "1"
    vars.http_proxy: "" => "http://127.0.0.1:8888"

At last we run a 'terraform apply' again and the output is the following:

$ terraform apply -target=aws_instance.test                                                                                                                                                                                                                                                               
aws_instance.test: Refreshing state... (ID: i-83822876)
template_file.user_data_test: Creating...
  filename:        "" => "user_data/test.txt"
  rendered:        "" => "<computed>"
  vars.#:          "0" => "1"
  vars.http_proxy: "" => "http://127.0.0.1:8888"
template_file.user_data_test: Creation complete
aws_instance.test: Destroying...
aws_instance.test: Destruction complete
aws_instance.test: Creating...
  ami:                      "" => "ami-3238f032"
  availability_zone:        "" => "<computed>"
  ebs_block_device.#:       "" => "<computed>"
  ephemeral_block_device.#: "" => "<computed>"
  instance_type:            "" => "t1.micro"
  key_name:                 "" => "<computed>"
  placement_group:          "" => "<computed>"
  private_dns:              "" => "<computed>"
  private_ip:               "" => "<computed>"
  public_dns:               "" => "<computed>"
  public_ip:                "" => "<computed>"
  root_block_device.#:      "" => "<computed>"
  security_groups.#:        "" => "<computed>"
  subnet_id:                "" => "<computed>"
  tags.#:                   "" => "2"
  tags.Description:         "" => "Test template_file"
  tags.Name:                "" => "Test Instance"
  tenancy:                  "" => "<computed>"
  user_data:                "" => "f0fda1e1642030ab8e31861646b0cd37449b3e78"
  vpc_security_group_ids.#: "" => "<computed>"
aws_instance.test: Creation complete

Apply complete! Resources: 2 added, 0 changed, 1 destroyed.

As we can see the new user_data shown by the apply command is still the same, but the plan command returns a totally different one. If we would do the same again the outcome will be also the same (new hash shown by plan, during apply resource gets recreated but user_data stays the same).

The recreation is of course acceptable, if the template_file or any of its variables changed, but this is not the case here. And this is also indicated by the resource recreation during the second apply command, which also shows the same hash value as the one provided by the first apply.

[AlexanderEkdahl]

I've noticed the same thing in the scenario you describe.

[smotti]

AlexanderEkdahl: What version do you use?

[AlexanderEkdahl]

v0.5.0

[AlexanderEkdahl]

This error is fixed in master. I recommend building Terraform from source.

[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.