provider/aws: bug: When triggering a change which is ignored by lifecycle, instances are still recreated due to "false" => "0"

[mwinters0]

Steps to reproduce:

On terraform 0.6.14 from homebrew:

1. Create an instance with an old AMI and no lifecycle rules.

resource "aws_instance" "test_instance" {
  ami = "ami-61bbf104"
  instance_type = "t2.micro"
  subnet_id = "${var.subnet}"

  associate_public_ip_address = false

  tags {
    Name = "tf-test"
  }

}

2. Modify the instance AMI but add a lifecycle which ignores the change.

resource "aws_instance" "test_instance" {
  ami = "ami-6d1c2007"
  instance_type = "t2.micro"
  subnet_id = "${var.subnet}"

  associate_public_ip_address = false

  tags {
    Name = "tf-test"
  }

  lifecycle {
    ignore_changes = ["ami"]
  }

}

Expected result:

terraform plan should show no change.

Actual result:
Terraform wants to recreate the instance.

~ aws_instance.test_instance
    associate_public_ip_address: "false" => "0"
    source_dest_check:           "true" => "1"


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

My use case is that I don't want the existing instances to be recreated at this time, but if any other change should trigger a recreation, it should be done with the newest AMI.

I tested a few variants of this:

• Having a lifecycle present when the resource is first created, and then changing the AMI does still cause the reported issue.
• Adding a lifecycle without changing AMI does not cause recreation.

[mwinters0]

Perhaps related to #5627

[robholland]

Duplicate of #6005

[stack72]

Hi @MikeSchuette

I am going to close this as a duplicate of #6005 - it is easier to track this in 1 place

Thanks for the report!

Paul

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