Terraform: aws_route_table recreated each refresh

Created on 2 Oct 2016  ยท  11Comments  ยท  Source: hashicorp/terraform

Terraform Version

Terraform v0.7.5-dev (88c3554dda189bb38ae27483d4c122dbdb4e6235+CHANGES)

Affected Resource(s)

  • aws_route_table

    Terraform Configuration Files

https://github.com/h4ck3rm1k3/terraform-aws-vpc/blob/9f1e9ffb76d51963a6eb5acda49a85a53e324d6b/aws-vpc.tf

Expected Behavior

Do nothing

Actual Behavior

object destroyed and recreated

Output

~/experiments/ccore/bin/terraform plan -var-file terraform.tfvars -out terraform.tfplan
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but
will not be persisted to local or remote state storage.

aws_vpc.default: Refreshing state... (ID: vpc-843500e3)
aws_subnet.us-east-1d-private: Refreshing state... (ID: subnet-f7963cbe)
aws_subnet.us-east-1c-private: Refreshing state... (ID: subnet-8a57aca7)
aws_internet_gateway.default: Refreshing state... (ID: igw-1f57af78)
aws_subnet.us-east-1d-public: Refreshing state... (ID: subnet-f4963cbd)
aws_subnet.us-east-1c-public: Refreshing state... (ID: subnet-8557aca8)
aws_route_table.us-east-1-public: Refreshing state... (ID: rtb-160b9e70)
aws_security_group.nat: Refreshing state... (ID: sg-ee693694)
aws_route_table_association.us-east-1d-public: Refreshing state... (ID: rtbassoc-6c65e515)
aws_route_table_association.us-east-1c-public: Refreshing state... (ID: rtbassoc-6f65e516)
aws_instance.nat: Refreshing state... (ID: i-5a51566b)
aws_network_interface.eth0: Refreshing state... (ID: eni-0c45241e)
aws_route_table.us-east-1-private: Refreshing state... (ID: rtb-e20b9e84)
aws_route_table_association.us-east-1d-private: Refreshing state... (ID: rtbassoc-4a65e533)
aws_route_table_association.us-east-1c-private: Refreshing state... (ID: rtbassoc-4b65e532)

The Terraform execution plan has been generated and is shown below.
Resources are shown in alphabetical order for quick scanning. Green resources
will be created (or destroyed and then created if an existing resource
exists), yellow resources are being changed in-place, and red resources
will be destroyed. Cyan entries are data sources to be read.

Your plan was also saved to the path below. Call the "apply" subcommand
with this plan file and Terraform will exactly execute this execution
plan.

Path: terraform.tfplan

aws_route_table.us-east-1-private
    route.262475047.cidr_block:                 "0.0.0.0/0" => ""
    route.262475047.gateway_id:                 "" => ""
    route.262475047.instance_id:                "i-5a51566b" => ""
    route.262475047.nat_gateway_id:             "" => ""
    route.262475047.network_interface_id:       "eni-0c45241e" => ""
    route.262475047.vpc_peering_connection_id:  "" => ""
    route.3286695220.cidr_block:                "" => "0.0.0.0/0"
    route.3286695220.gateway_id:                "" => ""
    route.3286695220.instance_id:               "" => ""
    route.3286695220.nat_gateway_id:            "" => ""
    route.3286695220.network_interface_id:      "" => "eni-0c45241e"
    route.3286695220.vpc_peering_connection_id: "" => ""


Plan: 0 to add, 1 to change, 0 to destroy.
~/experiments/ccore/bin/terraform apply -var-file terraform.tfvars
aws_vpc.default: Refreshing state... (ID: vpc-843500e3)
aws_subnet.us-east-1c-private: Refreshing state... (ID: subnet-8a57aca7)
aws_subnet.us-east-1d-private: Refreshing state... (ID: subnet-f7963cbe)
aws_subnet.us-east-1d-public: Refreshing state... (ID: subnet-f4963cbd)
aws_subnet.us-east-1c-public: Refreshing state... (ID: subnet-8557aca8)
aws_internet_gateway.default: Refreshing state... (ID: igw-1f57af78)
aws_route_table.us-east-1-public: Refreshing state... (ID: rtb-160b9e70)
aws_security_group.nat: Refreshing state... (ID: sg-ee693694)
aws_route_table_association.us-east-1d-public: Refreshing state... (ID: rtbassoc-6c65e515)
aws_route_table_association.us-east-1c-public: Refreshing state... (ID: rtbassoc-6f65e516)
aws_instance.nat: Refreshing state... (ID: i-5a51566b)
aws_network_interface.eth0: Refreshing state... (ID: eni-0c45241e)
aws_route_table.us-east-1-private: Refreshing state... (ID: rtb-e20b9e84)
aws_route_table_association.us-east-1c-private: Refreshing state... (ID: rtbassoc-4b65e532)
aws_route_table_association.us-east-1d-private: Refreshing state... (ID: rtbassoc-4a65e533)
aws_route_table.us-east-1-private: Modifying...
  route.262475047.cidr_block:                 "0.0.0.0/0" => ""
  route.262475047.gateway_id:                 "" => ""
  route.262475047.instance_id:                "i-5a51566b" => ""
  route.262475047.nat_gateway_id:             "" => ""
  route.262475047.network_interface_id:       "eni-0c45241e" => ""
  route.262475047.vpc_peering_connection_id:  "" => ""
  route.3286695220.cidr_block:                "" => "0.0.0.0/0"
  route.3286695220.gateway_id:                "" => ""
  route.3286695220.instance_id:               "" => ""
  route.3286695220.nat_gateway_id:            "" => ""
  route.3286695220.network_interface_id:      "" => "eni-0c45241e"
  route.3286695220.vpc_peering_connection_id: "" => ""
aws_route_table.us-east-1-private: Modifications complete

Apply complete! Resources: 0 added, 1 changed, 0 destroyed.

The state of your infrastructure has been saved to the path
below. This state is required to modify and destroy your
infrastructure, so keep it safe. To inspect the complete state
use the `terraform show` command.

State path: terraform.tfstate

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

  1. git clone https://github.com/h4ck3rm1k3/terraform-aws-vpc/
  2. terraform apply
bug provideaws waiting-response

Most helpful comment

@rhartkopf What you're seeing is expected behaviour.

In your config, you're setting gateway_id but the actual value stored in AWS (once parsed by AWS) is nat_gateway_id

All 11 comments

upgraded terraform to head and after some changes to my file this does not occur. If you want I can dig into this more.

Hi @h4ck3rm1k3

What version of terraform were you seeing this on originally?

P.

The one that I mentioned in my bug report : Terraform v0.7.5-dev (88c3554+CHANGES)

This issue doesn't reproduce on v0.7.6.

I am seeing this behaviour as well (0.76). No "aws_route" objects exist in my tf files (only aws_route_table with sub route objects) yet this continually occurs. Is it because there is a route modification inside the "default" route table?

EDIT: If I extrapolate all the route instances into their own "aws_route" resources and remove the sub route objects from the "aws_route_table" resource, this issue disappears. It does, however, mean that I had to delete the routes in AWS first in order for terraform to apply the configuration without "RouteAlreadyExists" errors.

I am having the same issue, every time I run plan or apply it tries to modify the route table. Tried changing the order of the routes, didn't help.

~ aws_route_table.r
    route.3147254500.cidr_block:                "" => "10.20.64.0/20"
    route.3147254500.gateway_id:                "" => "pcx-ddb107b4"
    route.3147254500.instance_id:               "" => ""
    route.3147254500.nat_gateway_id:            "" => ""
    route.3147254500.network_interface_id:      "" => ""
    route.3147254500.vpc_peering_connection_id: "" => ""
    route.4022726914.cidr_block:                "10.20.64.0/20" => ""
    route.4022726914.gateway_id:                "" => ""
    route.4022726914.instance_id:               "" => ""
    route.4022726914.nat_gateway_id:            "" => ""
    route.4022726914.network_interface_id:      "" => ""
    route.4022726914.vpc_peering_connection_id: "pcx-ddb107b4" => ""
    route.443074692.cidr_block:                 "0.0.0.0/0" => "0.0.0.0/0"
    route.443074692.gateway_id:                 "igw-051b5460" => "igw-051b5460"
    route.443074692.instance_id:                "" => ""
    route.443074692.nat_gateway_id:             "" => ""
    route.443074692.network_interface_id:       "" => ""
    route.443074692.vpc_peering_connection_id:  "" => ""


Plan: 0 to add, 1 to change, 0 to destroy.
resource "aws_route_table" "r" {
  vpc_id = "${aws_vpc.main.id}"

  route {
      cidr_block = "${var.bais_vpc_cidr}"
      gateway_id = "${aws_vpc_peering_connection.bridge.id}"
  }

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

I'm seeing the same results with terraform v0.7.13 with a NAT gateway.

aws_route_table.redacted: Modifying...
  route.3699578275.cidr_block:                "" => "0.0.0.0/0"
  route.3699578275.gateway_id:                "" => "nat-0432e19b14274aa9e"
  route.3699578275.instance_id:               "" => ""
  route.3699578275.nat_gateway_id:            "" => ""
  route.3699578275.network_interface_id:      "" => ""
  route.3699578275.vpc_peering_connection_id: "" => ""
  route.4234255068.cidr_block:                "0.0.0.0/0" => ""
  route.4234255068.gateway_id:                "" => ""
  route.4234255068.instance_id:               "" => ""
  route.4234255068.nat_gateway_id:            "nat-0432e19b14274aa9e" => ""
  route.4234255068.network_interface_id:      "" => ""
  route.4234255068.vpc_peering_connection_id: "" => ""
  route.477658159.cidr_block:                 "172.30.16.0/21" => "172.30.16.0/21"
  route.477658159.gateway_id:                 "" => ""
  route.477658159.instance_id:                "" => ""
  route.477658159.nat_gateway_id:             "" => ""
  route.477658159.network_interface_id:       "" => ""
  route.477658159.vpc_peering_connection_id:  "pcx-c13ea8a8" => "pcx-c13ea8a8"
aws_route_table.redacted: Modifications complete
resource "aws_route_table" "redacted" {
  provider = "aws.nonprod"
  vpc_id = "${aws_vpc.redacted.id}"
  route {
    cidr_block = "0.0.0.0/0"
    gateway_id = "${aws_nat_gateway.redacted.id}"
  }
  route {
    cidr_block = "${var.vpc_bastion_cidr}"
    vpc_peering_connection_id = "${aws_vpc_peering_connection.redacted.id}"
  }
  tags {
    Name = "redacted"
    Group = "dev"
  }
}

@rhartkopf What you're seeing is expected behaviour.

In your config, you're setting gateway_id but the actual value stored in AWS (once parsed by AWS) is nat_gateway_id

Must have glossed right over that in the docs. Thank you!

Thanks @stroebs. Closing this out!

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.

Was this page helpful?
0 / 5 - 0 ratings