ignore_changes doesn't seem to work

[dwradcliffe]

Follow up from #2525

It seems that the new ignore_changes feature is not working. I've tried adding ignore changes to an aws instance like this:

    lifecycle {
        ignore_changes = ["ami"]
    }

And when the ami has changed, I see the normal destroy/create diff like I would have in previous versions, except that the line of text for ami is missing. So it seems that it's removing ami from the visual diff but not the diff that determines what terraform will do.

[djaboxx]

I'm seeing a similar issue with regards to tags. We use Ansible to configure our ec2 instances. Ansible targets the correct new hosts (we dont want to touch the previously configured hosts) by the presence of a tag. I'd like Terraform to be able to initially create a tag on an ec2 instance, let Ansible remove the tag, and then have Terraform ignore the tag when it's not longer present.

[mzupan]

I'm not seeing it destroy as I haven't tested it but what I have in my tf is

  lifecycle {
    ignore_changes = [
      "ami",
      "instance_type"
    ]
  }

Then I get the following in plan

-/+ aws_instance.ci
    availability_zone:                 "us-east-1d" => "<computed>"
    ebs_block_device.#:                "2" => "<computed>"
    ephemeral_block_device.#:          "0" => "<computed>"
    iam_instance_profile:              "WEB-ci" => "WEB-ci"
    key_name:                          "urthecast-prod-admin" => "urthecast-prod-admin"
    placement_group:                   "" => "<computed>"
    private_dns:                       "ip-10-120-2-20.ec2.internal" => "<computed>"
    private_ip:                        "10.120.2.20" => "10.120.2.20"
    public_dns:                        "" => "<computed>"
    public_ip:                         "" => "<computed>"
    root_block_device.#:               "0" => "<computed>"
    security_groups.#:                 "0" => "<computed>"
    source_dest_check:                 "true" => "1"
    subnet_id:                         "subnet-26029c7f" => "subnet-26029c7f"
    tags.#:                            "3" => "3"
    tags.CostCenter:                   "web" => "web"
    tags.Name:                         "WEB ci.prod" => "WEB ci.prod"
    tags.Roles:                        "ci" => "ci"
    tenancy:                           "default" => "<computed>"
    user_data:                         "5e506463f257044f47bcbf02ea2d7e50cd5282a8" => "5e506463f257044f47bcbf02ea2d7e50cd5282a8"
    vpc_security_group_ids.#:          "2" => "2"
    vpc_security_group_ids.2022992139: "sg-f5351091" => "sg-f5351091"
    vpc_security_group_ids.2343995649: "sg-f1351095" => "sg-f1351095"

The final line is

Plan: 7 to add, 22 to change, 7 to destroy.

Without the ignore option in lifecycle I got the same 7 destroy. It makes me thinks that even though its an update, terraform will still destroy that instance.

[ketzacoatl]

I am seeing the same behavior as well. ignore_changes appears to work for one of my resources, but not the other. The only difference I can spot between the two resources is that in one case, there is only one change proposed by TF, and in the other, TF sees multiple changes. The one change succeeds with ignore_change, the one with multiple changes fails to ignore changes.

This bug is made all the more frustrating by the limitations of #3874.

[ketzacoatl]

To confirm if this was a regression, and to see if I could work around this bug, I downloaded an older version of Terraform to run some tests:

~/bin/terraform version 
Terraform v0.6.5

Your version of Terraform is out of date! The latest version
is 0.6.6. You can update by downloading from www.terraform.io

I can confirm this appears to be a regression - ignore_changes is definitely working better in v0.6.5. Interestingly, it is not working 100% as expected, here is the plan output using v0.6.5:

-/+ aws_instance.host-a
    ami:                                       "ami-0f15a29c" => "ami-0f15a29c"
    associate_public_ip_address:               "true" => "1"
    availability_zone:                         "us-east-2a" => "us-east-2a"
    ebs_optimized:                             "true" => "1"
    ephemeral_block_device.#:                  "0" => "<computed>"
    instance_type:                             "c4.2xlarge" => "c4.2xlarge"
    key_name:                                  "my-key" => "my-key"
    placement_group:                           "" => "<computed>"
    private_dns:                               "ip-10-10-10-2.us-east-2.compute.internal" => "<computed>"
    private_ip:                                "10.10.10.2" => "<computed>"
    public_dns:                                "ec2-a-b-c-d.us-east-2.compute.amazonaws.com" => "<computed>"
    public_ip:                                 "a.b.c.d" => "<computed>"
    root_block_device.#:                       "1" => "1"
    root_block_device.0.delete_on_termination: "false" => "0"
    root_block_device.0.iops:                  "45" => "<computed>"
    root_block_device.0.volume_size:           "15" => "15"
    root_block_device.0.volume_type:           "gp2" => "gp2"
    security_groups.#:                         "1" => "1"
    security_groups.2141652863:                "sg-abc856ef" => "sg-abc856ef"
    source_dest_check:                         "true" => "1"
    subnet_id:                                 "subnet-90ae8fa7" => "subnet-90ae8fa7"
    tags.#:                                    "1" => "1"
    tags.Name:                                 "host-a0-us-east-2" => "host-a0-us-east-2"
    tenancy:                                   "default" => "<computed>"
    vpc_security_group_ids.#:                  "1" => "<computed>"


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

What is interesting?

• The above lists no resource attributes expected to change, but TF wants to destroy it anyway, and lists it as such (Plan: 1 to add, 0 to change, 1 to destroy.)
• If I comment out my lifecycle block and re-run the above, TF lists the attributes with changes and makes note of the attributes causing the destroy/create (eg (forces new resource))

I will go back one more release and retest..

[ketzacoatl]

v0.6.4 seemed to have the same issue. v0.6.3 is where things got interesting again:

• Testing the plan with ignore_changes results in Terraform wanting to change my resource (EBS), but not destroy:

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

• When I try to apply the plan, TF actually tries to destroy my resource, rather than change it (I have termination protection enabled, so AWS/TF failed that attempt)
• TF is still not listening to the ignore_changes here.

[dwradcliffe]

@phinze @catsby Any ideas here?

[scalp42]

We removed the ignore_changes as well as we're running into the diff issues :(

[stevenewey]

Same here. Thanks to ignore_changes plan doesn't highlight any change for an aws_route_table which has received new entries after deployment. But on running apply...

* aws_route_table.route-public: diffs didn't match during apply. This is a bug with Terraform and should be reported.

[scalp42]

I can report that ignore_changes is now working for us using master, this PR exactly:

#4965

[phinze]

Thanks for following up, @scalp42! I'm going to close this issue as fixed in master (and therefore will be fixed in the next 0.6.12 release)- anybody else on the thread still having issues on master feel free to follow up. 👌

[ahodges22]

I'm on 0.6.14 and I still seem to have this issue where Terraform wants to destroy instances despite having ignore_changes set.

[onlyanegg]

I'm having the same issue in 0.8.1

resource "aws_instance" "instance" {
...
  lifecycle {
    ignore_changes = ["tags", "ami"]
  }
...
}

$ terraform plan
...
-/+ aws_instance.instance.0
    ami:                                               "ami-e50b70f2" => "ami-7a81876d" (forces new resource)
...

[mabushey]

Works correctly on Terraform v0.9.8 using same config as @onlyanegg

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