Terraform: Roll up issue for known ignore_changes problems

[phinze]

I'm currently diving into the active ignore_changes issues and I'm opening this to consolidate the open issues that will be handled for this effort.

Current known issues I'm working on:

• [x] Does not work with ForceNew attributes (resource still gets replaced w/ attr filtered out of the diff)
• [x] Does not work with Required attributes (attr filtered out and not present on creation, causing failure)
• [ ] Causes a diffs didn't match error if upstream attribute changes and a state refresh catches it (#4953, #4696)
• [ ] Causes a diffs didn't match error on Opsworks changes following the repro steps in #4790

[spiffxp]

@phinze still able to repro #3739 as described, using terraform 0.6.12

[phinze]

Thanks for checking, @spiffxp - I believe that it falls under the ForceNew bucket but I'll make sure it checks out before I close this issue.

[spiffxp]

Actually... scratch that, it works in terraform 0.6.12, sorry for the confusion. Turns out I was in fact using terraform 0.6.11.

[phinze]

@spiffxp Oh cool! Thanks for following up :grinning:

[nickithewatt]

Thanks @phinze, looking forward to this. What are your thoughts wrt whether this may make it into the next release or not?

[phinze]

Okay, v0.6.14 contains several improvements to the ignore_changes behavior. I'm checking off the first two items from the list above and checking up on repro steps for the second two now. Take 0.6.14 for a spin and let me know what you find!

[mtougeron]

ya! I'll upgrade today! :)

[nickithewatt]

Thanks @phinze

I did test with 0.6.14 (using the same setup as described in my original issue https://github.com/hashicorp/terraform/issues/5294) and unfortunately it still does not work for me :( Infact it actually breaks slightly worse now ....

Having done a successful terraform apply, I modified a variable within one of the the template resources which in turn serves to generate the input for the user_data of various aws_instance resources. The aws_instance is configured with lifecycle { ignore_changes = [ "user_data" ] } and, in a more desperate attempt to stop this happening I also added lifecycle { ignore_changes = [ "vars" ] } to the template itself.

Doing a terraform plan, just seems to report the wrong info i.e. it says it was going to destroy and add 15 resources and change one, but that is not supported by the textual output which only seems to list 10. i.e.

-/+ template_file.output_info_a
    ...
    vars.#:                 "6" => "<computed>" (forces new resource)
    ...

-/+ template_file.output_info_b
    ...
    vars.#:                 "11" => "<computed>" (forces new resource)
    ...

-/+ template_file.output_info_b
    ...
    vars.#:            "6" => "<computed>" (forces new resource)
    ...

~ module.mgt-lite.aws_eip.myeip
    instance: "i-bob07672" => "${aws_instance.myvm.id}"

~ module.mgt-lite.aws_instance.myvm
    associate_public_ip_address: "true" => "1"
    source_dest_check:           "false" => "0"

~ module.web.aws_instance.vm.0
    root_block_device.0.delete_on_termination: "true" => "1"
    source_dest_check:                         "true" => "1"

~ module.web.aws_instance.vm.1
    root_block_device.0.delete_on_termination: "true" => "1"
    source_dest_check:                         "true" => "1"

~ module.web.aws_instance.vm.2
    root_block_device.0.delete_on_termination: "true" => "1"
    source_dest_check:                         "true" => "1"

~ module.app.aws_instance.vm.0
    root_block_device.0.delete_on_termination: "true" => "1"
    source_dest_check:                         "true" => "1"

~ module.app.aws_instance.vm.1
    root_block_device.0.delete_on_termination: "true" => "1"
    source_dest_check:                         "true" => "1"

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

Not sure exactly what it would do here, I did a terraform apply anyway to see.

This resulted in quite a few errors, all of the same variety as noted below

* aws_instance.vm.1: diffs didn't match during apply. This is a bug with Terraform and should be reported as a GitHub Issue.

Please include the following information in your report:

    Terraform Version: 0.6.14
    Resource ID: aws_instance.vm.1
    Mismatch reason: attribute mismatch: root_block_device.0.delete_on_termination
    Diff One (usually from plan): *terraform.InstanceDiff{Attributes:map[string]*terraform.ResourceAttrDiff{"source_dest_check":*terraform.ResourceAttrDiff{Old:"true", New:"1", NewComputed:false, NewRemoved:false, NewExtra:interface {}(nil), RequiresNew:false, Type:0x0}, "root_block_device.0.delete_on_termination":*terraform.ResourceAttrDiff{Old:"true", New:"1", NewComputed:false, NewRemoved:false, NewExtra:interface {}(nil), RequiresNew:false, Type:0x0}}, Destroy:false, DestroyTainted:false}
    Diff Two (usually from apply): *terraform.InstanceDiff{Attributes:map[string]*terraform.ResourceAttrDiff(nil), Destroy:false, DestroyTainted:false}

Also include as much context as you can about your config, state, and the steps you performed to trigger this error.

[mtougeron]

For me adding the ignore of image_name (using the openstack_compute_instance_v2 resource) worked as expected.

  lifecycle {
    create_before_destroy = true
    ignore_changes = ["image_name"]
  }

[davidblewett]

@phinze Still having trouble with ignore_changes with 0.6.14. I initially created an aws_instance with a single ebs_block_device. I then went back and added a 2nd ebs_block_device to the config, so that I could optionally setup a software RAID. I added the following, but Terraform still wants to destroy the instances and re-create them to add the 2nd device:

  lifecycle {
    prevent_destroy = true
    ignore_changes = ["ebs_block_device"]
  }

* aws_instance.default: the plan would destroy this resource, but it currently has lifecycle.prevent_destroy set to true. To avoid this error and continue with the plan, either disable lifecycle.prevent_destroy or adjust the scope of the plan using the -target flag.

[WZ]

Another issue is that, after I apply ignore_changes to resources, I see no +, -, or ~ in the plan anymore but still see changes reflected to the counter:
...
Plan: 20 to add, 3 to change, 20 to destroy.

[WZ]

Too be more clear... the counter is wrongly aggregated when there is other change in the plan. The following shows only one ~ change but the counters are wrong.

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

~ module.data_nodes.postgresql.aws_instance.postgresql
disable_api_termination: "true" => "1"

Plan: 20 to add, 3 to change, 20 to destroy.

[theturtle32]

Also -> #5956

[stack72]

Also #6296

[nickithewatt]

@phinze its great that we got the first half of these fixes out with 0.6.14 - thanks! I see that 0.6.15 is out now as well however looks like these last set of ignore issues are still there, which is still causing me great grief unfortunately and thus I can't use the feature as a result. Are these last scenarios more complicated to resolve, i.e. my real question here is: are the fixes for these likely to make it into a next minor release or do they need more fundamental attention, and thus may still be some way off?

[glasser]

Looks like #6446 is an ignore_changes issue.

[glasser]

Yup, #6446 is definitely ignored_changes and I've made a pretty minimal reproduction of how using ignore_changes with aws_autoscaling_group desired_capacity breaks you.

[glasser]

For a more abstract ignore_changes question: I've read the docs and I don't understand what the intended semantics of ignore_changes is. There are two things I could imagine it being:

(1) After creating, fully ignore this field's configuration and always preserve what exists in the resource's actual state.

(2) Do a three-way diff between the previous value in the tfstate A, the value in the config file B, and the value in the actual resource C. If A=B, preserve the state as C, otherwise set to B.

It would be great if the answer was (2), but I can't tell from the docs or the source if that's the intention.

Our specific goal is for desired_capacity (ie, number of instances to run) on an aws_autoscaling_group that has autoscaling policies. It would be great if explicitly editing the field and applying changed the number of instances, and if applying when the field hasn't been edited didn't revert changes made in production by the autoscaling policies. Is ignore_changes intended for this?

[Fodoj]

Here is another one, not listed there: https://github.com/hashicorp/terraform/issues/6746

[gozer]

I've been keeping an eye on #5911, and I was hopeful today, but nope.

Not sure if I should create a separate issue with this, but I caught another one against tip of master today.

resource "aws_s3_bucket" "uuid" {
  bucket = "gozer-test-${uuid()}"
  lifecycle {
    ignore_changes = [
      "bucket"
    ]
  }
}

Worked fine on creation and subsequent plans showed nothing to do.

However, if I changed the resource like so:

resource "aws_s3_bucket" "uuid" {
  bucket = "gozer-test-${uuid()}"
  acl = "public-read"
  lifecycle {
    ignore_changes = [
      "bucket"
    ]
  }
}

I get an error thrown:

1 error(s) occurred:

* aws_s3_bucket.uuid: diffs didn't match during apply. This is a bug with Terraform and should be reported as a GitHub Issue.

Please include the following information in your report:

    Terraform Version: 0.7.0
    Resource ID: aws_s3_bucket.uuid
    Mismatch reason: diff: Destroy; old: false, new: true
    Diff One (usually from plan): *terraform.InstanceDiff{Attributes:map[string]*terraform.ResourceAttrDiff{"acl":*terraform.ResourceAttrDiff{Old:"private", New:"public-read", NewComputed:false, NewRemoved:false, NewExtra:interface {}(nil), RequiresNew:false, Type:0x0}}, Destroy:false, DestroyTainted:false}
    Diff Two (usually from apply): *terraform.InstanceDiff{Attributes:map[string]*terraform.ResourceAttrDiff{"website_endpoint":*terraform.ResourceAttrDiff{Old:"", New:"", NewComputed:true, NewRemoved:false, NewExtra:interface {}(nil), RequiresNew:false, Type:0x0}, "acl":*terraform.ResourceAttrDiff{Old:"private", New:"public-read", NewComputed:false, NewRemoved:false, NewExtra:interface {}(nil), RequiresNew:false, Type:0x0}, "force_destroy":*terraform.ResourceAttrDiff{Old:"false", New:"false", NewComputed:false, NewRemoved:false, NewExtra:interface {}(nil), RequiresNew:false, Type:0x0}, "arn":*terraform.ResourceAttrDiff{Old:"arn:aws:s3:::gozer-test-434b8b12-9660-cd5e-31f8-5027da62803b", New:"", NewComputed:true, NewRemoved:false, NewExtra:interface {}(nil), RequiresNew:false, Type:0x0}, "acceleration_status":*terraform.ResourceAttrDiff{Old:"", New:"", NewComputed:true, NewRemoved:false, NewExtra:interface {}(nil), RequiresNew:false, Type:0x0}, "hosted_zone_id":*terraform.ResourceAttrDiff{Old:"Z3AQBSTGFYJSTF", New:"", NewComputed:true, NewRemoved:false, NewExtra:interface {}(nil), RequiresNew:false, Type:0x0}, "region":*terraform.ResourceAttrDiff{Old:"us-east-1", New:"", NewComputed:true, NewRemoved:false, NewExtra:interface {}(nil), RequiresNew:false, Type:0x0}, "website_domain":*terraform.ResourceAttrDiff{Old:"", New:"", NewComputed:true, NewRemoved:false, NewExtra:interface {}(nil), RequiresNew:false, Type:0x0}}, Destroy:true, DestroyTainted:false}

Also include as much context as you can about your config, state, and the steps you performed to trigger this error.

[apparentlymart]

Hi all! Thanks for the great discussion here, and sorry for leaving this unattended for so long.

Given the rather open-ended nature of this issue, and that there have been some significant changes to Terraform's core since this issue was opened, I'm going to close this issue for now. If anyone is still seeing issues that they suspect come until the former scope of this ticket I suggest to open them as new top-level issues and we can triage each one independently.

Thanks again for all the help here in gathering theses issues!

[hashibot[bot]]

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.