core: "diffs didn't match during apply" error message.

[dharrisio]

Fix ignore_changes issue with error message diffs didn't match during apply.

This error shows up when using ignore_changes for attributes that may be modified outside of Terraform. As an example see version_label in #3871.
I also checked #4912 and it seemed to fix the issue there too.

Other issues I haven't checked into but look like they may be effected too.
#4819
#4790
#4696
#4045
#3869
#3739
#3738
#3566
#4859 (not a fix, but maybe related)

I think the issue is that only the plan diff was using EvalIgnoreChanges. Because this was not occurring in the apply step, the diffs were not equal when ignore_changes was being used.

Sample Terraform document with to reproduce error message.

variable "cidr" {
  default = "10.10.0.0/16"
}

variable "cidrs" {
  default = "10.10.0.0/24,10.10.1.0/24"
}

variable "azs" {
  default = "us-east-1a,us-east-1b"
}

variable "region" {
  default = "us-east-1"
}

variable "name" {
  default = "diffs_dont_match"
}

variable "instance_type" {
  default = "t2.micro"
}

provider "aws" {
  region = "us-east-1"
}

resource "aws_vpc" "default" {
  cidr_block           = "${var.cidr}"
  enable_dns_support   = true
  enable_dns_hostnames = true
}

resource "aws_internet_gateway" "public" {
  vpc_id = "${aws_vpc.default.id}"

  tags {
    Name = "${var.name}"
  }
}

resource "aws_subnet" "public" {
  vpc_id            = "${aws_vpc.default.id}"
  cidr_block        = "${element(split(",", var.cidrs), count.index)}"
  availability_zone = "${element(split(",", var.azs), count.index)}"
  count             = "${length(split(",", var.cidrs))}"

  map_public_ip_on_launch = true

  tags {
    Name = "${var.name}.${element(split(",", var.azs), count.index)}"
  }
}

resource "aws_route_table" "public" {
  vpc_id = "${aws_vpc.default.id}"

  route {
    cidr_block = "0.0.0.0/0"
    gateway_id = "${aws_internet_gateway.public.id}"
  }

  tags {
    Name = "${var.name}.${element(split(",", var.azs), count.index)}"
  }
}

resource "aws_route_table_association" "public" {
  count          = "${length(split(",", var.cidrs))}"
  subnet_id      = "${element(aws_subnet.public.*.id, count.index)}"
  route_table_id = "${aws_route_table.public.id}"
}

resource "aws_security_group" "allow_all" {
  name        = "allow_all"
  description = "Allow all inbound traffic"
  vpc_id      = "${aws_vpc.default.id}"

  ingress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

resource "aws_instance" "default" {
  ami                    = "ami-fbb9c991"
  instance_type          = "${var.instance_type}"
  subnet_id              = "${aws_subnet.public.0.id}"

  tags {
    "Key" = "Value"
  }

  lifecycle {
    ignore_changes = ["tags"]
  }
}

[jen20]

Hi @dharrisio! Thanks for opening this pull request and for the research that has gone into it. It sounds like a good explanation for this range of bugs. I'm going to pull this now and see what I can find and hopefully merge.

[jen20]

This certainly fixes several reproductions of this problem. I'll go ahead and merge it and then work my way through the open issues to determine which can be closed. Thanks @dharrisio!

[dharrisio]

@jen20 Thanks!

[jen20]

Coming back to this to try to add some test coverage prior to release - prior to the patch being applied the following configuration is a minimal reproduction:

provider "aws" {
    region = "us-east-1"
}

resource "aws_instance" "default" {
    ami = "ami-fbb9c991"
    instance_type = "t2.nano"

    tags {
        Name = "Repro 4965"
    }

    lifecycle {
        ignore_changes = ["tags"]
    }
}

[jen20]

Even better in lieu of implementing a test provider here, this also replicates it:

resource "template_file" "test" {
    template = "The template text"

    vars {
        key1 = "value1"
    }

    lifecycle {
        ignore_changes = ["vars"]
    }
}

[jen20]

See #5227 for tests covering this.

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