Terraform: aws_route_table: Inconsistency when using gateway_id / nat_gateway_id

Created on 9 May 2016  ·  6Comments  ·  Source: hashicorp/terraform

Terraform Version

➜  ~ terraform -v
Terraform v0.6.15

Affected Resource(s)

  • aws_route_table

    Terraform Configuration Files

An aws_route_table resource that incorrectly refers to an aws_nat_gateway using gateway_id instead of nat_gateway_id:

provider "aws" {
  region = "eu-west-1"
}

resource "aws_vpc" "test" {
  cidr_block = "10.0.0.0/16"
}

resource "aws_eip" "test" {
  vpc = true
}

resource "aws_subnet" "test" {
  vpc_id                  = "${aws_vpc.test.id}"
  cidr_block              = "${aws_vpc.test.cidr_block}"
  map_public_ip_on_launch = false
}

resource "aws_internet_gateway" "test" {
  vpc_id = "${aws_vpc.test.id}"
}

resource "aws_nat_gateway" "test" {
  allocation_id = "${aws_eip.test.id}"
  subnet_id     = "${aws_subnet.test.id}"
}

resource "aws_route_table" "test" {
  vpc_id = "${aws_vpc.test.id}"

  route {
    cidr_block = "0.0.0.0/0"
    gateway_id = "${aws_nat_gateway.test.id}"
  }
}

Expected Behavior

We could make it more user friendly in the face of incorrect configuration by doing one of either:

  • automatically converting the gateway_id/nat_gateway_id arguments during create or read based on the prefix of the ID, so that the resource isn't modified on subsequent apply runs
  • raising an error if an ID with an incompatible prefix is passed to gateway_id/nat_gateway_id
  • document the behaviour in the argument reference

I'm happy to raise a pull request and acceptance test if we can decide on the correct solution.

Actual Behavior

The aws_route_table resource is modified on every apply because the AWS API automatically converts our incorrect gateway_id to nat_gateway_id:

aws_route_table.test: Modifying...
  route.3342964847.cidr_block:                "" => "0.0.0.0/0"
  route.3342964847.gateway_id:                "" => "nat-058b4dd1636a09817"
  route.3342964847.instance_id:               "" => ""
  route.3342964847.nat_gateway_id:            "" => ""
  route.3342964847.network_interface_id:      "" => ""
  route.3342964847.vpc_peering_connection_id: "" => ""
  route.3629674017.cidr_block:                "0.0.0.0/0" => ""
  route.3629674017.gateway_id:                "" => ""
  route.3629674017.instance_id:               "" => ""
  route.3629674017.nat_gateway_id:            "nat-058b4dd1636a09817" => ""
  route.3629674017.network_interface_id:      "" => ""
  route.3629674017.vpc_peering_connection_id: "" => ""
aws_route_table.test: Modifications complete

Steps to Reproduce

  1. Take the example configuration from above
  2. Run terraform apply once to create the resources
  3. Runterraform apply again to observe the resource being modified
bug provideaws

Most helpful comment

I encountered this bug today. Confused me till I figured it out (took me about 45mins)

Had to change this section in my AWS_ROUTE_TABLE resource:

route {
    cidr_block = "10.0.1.0/24"
    gateway_id = "the_nat_gateway_id"
}

to

route {
    cidr_block = "10.0.1.0/24"
    nat_gateway_id = "the_nat_gateway_id"    <------ this line
}

Am putting this here in case anyone else encounters the same behavior. Hope it helps.

Am using this version:

$ terraform -v
Terraform v0.7.3

All 6 comments

Hi @dcarley

Thanks for the report here. I agree that this can be confusing. I don't think that we can auto-assign params based on prefixes though - this may cause issues with the state. I think this specific issue needs better documentation to point out that gateway_id is not a nat_gateway but an internet_gateway

thoughts?

Paul

Agree that we probably shouldn't auto-assign, but maybe we could throw a warning or error when using a gateway_id starting "nat-" ?

Sorry, I hadn't forgotten about this, was just undecided about what to do. I have a branch with the documentation changes but I'm not confident that people will see it early enough since the error itself is quite subtle.

I was originally thinking of something like ValidateFunc to raise an error, but that wouldn't help for computed values (which I expect everyone to be using). I like @hansnqyr suggestion of logging a warning though. I'll have a play around with doing that.

I can't see any other resources that have unit or integration tests for logging. Should it be tested? Any suggestions?

I've realised that a warning won't help because of how log levels are exposed to users as described in #1581.

We could return an error. Is that too extreme?

I encountered this bug today. Confused me till I figured it out (took me about 45mins)

Had to change this section in my AWS_ROUTE_TABLE resource:

route {
    cidr_block = "10.0.1.0/24"
    gateway_id = "the_nat_gateway_id"
}

to

route {
    cidr_block = "10.0.1.0/24"
    nat_gateway_id = "the_nat_gateway_id"    <------ this line
}

Am putting this here in case anyone else encounters the same behavior. Hope it helps.

Am using this version:

$ terraform -v
Terraform v0.7.3

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