Tainted resource not recreated if ignore_changes used.

[sl1pm4t]

Problem:

If a resource has ignore_changes attribute set, and becomes tainted (either manually or due to an error during creation), Terraform does not include the tainted resource in the next diff.

Steps to Reproduce

Use the following terraform config:

resource "template_file" "taint-test" {
  template = <<EOT
Hello ${world}
EOT

  vars {
    world = "world"
  }

  lifecycle {
    ignore_changes = ["vars"]
  }

  provisioner "local-exec" {
    command = "echo ${self.rendered}"
  }

  // run "false" so provisioner fails and resource is tainted
  provisioner "local-exec" {
    command = "false"
  }
}

and run terraform apply.
The local-exec with command = "false" provisioner will cause the resource creation to error, and the resource will be tainted, e.g.:

MMORRISON-MBP:tf-taint-test-2 mmorrison$ terraform apply
template_file.taint-test: Creating...
  rendered:   "" => "<computed>"
  template:   "" => "Hello ${world}\n"
  vars.%:     "" => "1"
  vars.world: "" => "world"
template_file.taint-test: Provisioning with 'local-exec'...
template_file.taint-test (local-exec): Executing: /bin/sh -c "echo Hello world
template_file.taint-test (local-exec): "
template_file.taint-test (local-exec): Hello world
template_file.taint-test: Provisioning with 'local-exec'...
template_file.taint-test (local-exec): Executing: /bin/sh -c "false"
Error applying plan:

1 error(s) occurred:

* Error running command 'false': exit status 1. Output:

Terraform does not automatically rollback in the face of errors.
Instead, your Terraform state file has been partially updated with
any resources that successfully completed. Please address the error
above and apply again to incrementally change your infrastructure.
MMORRISON-MBP:tf-taint-test-2 mmorrison$

However, when terraform plan is run, there is no diff:

MMORRISON-MBP:tf-taint-test-2 mmorrison$ terraform plan
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but
will not be persisted to local or remote state storage.

template_file.taint-test: Refreshing state... (ID: 1894a19c85ba153acbf743ac4e43fc004c891604b26f8c69e1e83ea2afc7c48f)

No changes. Infrastructure is up-to-date. This means that Terraform
could not detect any differences between your configuration and
the real physical resources that exist. As a result, Terraform
doesn't need to do anything.

This is tested with master branch (0.7) commit 70999b1

Solution

After the committed change, the plan output is:

MMORRISON-MBP:tf-taint-test-2 mmorrison$ terraform plan
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but
will not be persisted to local or remote state storage.

template_file.taint-test: Refreshing state... (ID: 1894a19c85ba153acbf743ac4e43fc004c891604b26f8c69e1e83ea2afc7c48f)

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. Cyan entries are data sources to be read.

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.

-/+ template_file.taint-test (tainted)
    rendered:   "Hello world\n" => "<computed>"
    template:   "Hello ${world}\n" => "Hello ${world}\n"
    vars.%:     "1" => "1"
    vars.world: "world" => "world"


Plan: 1 to add, 0 to change, 1 to destroy.

[sl1pm4t]

Ping @stack72 @mitchellh - any chance we can get eyes on this one.

The bug causes some frustrating problems (even beyond what I've shown above, e.g. dependency graph is messed up if one tries to destroy -target <resource using ignore_changes>) and has a very simple fix.

[mitchellh]

I'm taking a look now, on first look this looks right, but we need to add a test case for this but I agree its a pretty not great bug so doing this now.

[mitchellh]

Got it, good fix: 9e9779e

Thanks!

[sl1pm4t]

Awesome, thanks @mitchellh !

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