Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ignore_changes doesn't seem to work #3555

Closed
dwradcliffe opened this issue Oct 19, 2015 · 14 comments
Closed

ignore_changes doesn't seem to work #3555

dwradcliffe opened this issue Oct 19, 2015 · 14 comments

Comments

@dwradcliffe
Copy link
Contributor

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
Copy link

djaboxx commented Oct 21, 2015

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
Copy link
Contributor

mzupan commented Nov 6, 2015

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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor Author

@phinze @catsby Any ideas here?

@scalp42
Copy link
Contributor

scalp42 commented Jan 11, 2016

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

@stevenewey
Copy link

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
Copy link
Contributor

scalp42 commented Feb 8, 2016

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

#4965

@phinze
Copy link
Contributor

phinze commented Feb 8, 2016

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

@phinze phinze closed this as completed Feb 8, 2016
@ahodges22
Copy link

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
Copy link

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
Copy link

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

@ghost
Copy link

ghost commented Apr 8, 2020

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.

@ghost ghost locked and limited conversation to collaborators Apr 8, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests