provider/aws: Route Table Data Source resource ordering

[grubernaut]

Terraform Version

0.8.3 and master

Affected Resource(s)

Please list the resources as a list, for example:

• data_source_aws_route_table

Terraform Configuration Files

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

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

resource "aws_subnet" "test" {
  cidr_block = "172.16.0.0/24"
  vpc_id = "${aws_vpc.test.id}"
}

resource "aws_route_table" "test" {
  vpc_id = "${aws_vpc.test.id}"
  tags {
    Name = "Private Route Table"
  }
}

resource "aws_route_table_association" "a" {
  route_table_id = "${aws_route_table.test.id}"
  subnet_id = "${aws_subnet.test.id}"
}

data "aws_route_table" "RTB" {
  depends_on = ["aws_route_table_association.a"]
  tags = {
    Name = "Private Route Table"
  }
}

Debug Output

https://gist.github.com/grubernaut/8343042b560fd88a1f08c247c5d499d7

Expected Behavior

The data resource be ordered after the aws_route_table and aws_route_table_association resources

Actual Behavior

The data resource was ordered before the route table resources, causing an error.

Steps to Reproduce

1. terraform plan
2. terraform apply

Important Factoids

Reason the acceptance test TestAccDataSourceAwsRouteTable is failing.

References

Are there any other GitHub issues (open or closed) or Pull Requests that should be linked here? For example:

• Discovered via aws_route_table crash on terraform plan #11134

[mitchellh]

To do this you should set depends_on explicitly on the data source. Terraform can't know about these implicit dependencies otherwise! :)

[grubernaut]

Sorry should have left depends_on in the above examples, but that's the cause of the issue.
The following acceptance test (written with depends_on on each data source) fails with the following:
https://github.com/hashicorp/terraform/blob/master/builtin/providers/aws/data_source_aws_route_table_test.go#L155-L178

=== RUN   TestAccDataSourceAwsRouteTable
--- FAIL: TestAccDataSourceAwsRouteTable (37.22s)
    testing.go:265: Step 0 error: After applying this step and refreshing, the plan was not empty:
        
        DIFF:
        
        CREATE: data.aws_route_table.by_filter
          associations.#:                      "" => "<computed>"
          filter.#:                            "0" => "1"
          filter.4095226016.name:              "" => "association.route-table-association-id"
          filter.4095226016.values.#:          "0" => "1"
          filter.4095226016.values.2774641665: "" => "rtbassoc-82b897ea"
          route_table_id:                      "" => "<computed>"
          routes.#:                            "" => "<computed>"
          subnet_id:                           "" => "<computed>"
          tags.%:                              "" => "<computed>"
          vpc_id:                              "" => "<computed>"
        CREATE: data.aws_route_table.by_id
          associations.#: "" => "<computed>"
          route_table_id: "" => "rtb-6c5edd04"
          routes.#:       "" => "<computed>"
          subnet_id:      "" => "<computed>"
          tags.%:         "" => "<computed>"
          vpc_id:         "" => "<computed>"
        CREATE: data.aws_route_table.by_subnet
          associations.#: "" => "<computed>"
          route_table_id: "" => "<computed>"
          routes.#:       "" => "<computed>"
          subnet_id:      "" => "subnet-406ff628"
          tags.%:         "" => "<computed>"
          vpc_id:         "" => "<computed>"
        CREATE: data.aws_route_table.by_tag
          associations.#: "" => "<computed>"
          route_table_id: "" => "<computed>"
          routes.#:       "" => "<computed>"
          subnet_id:      "" => "<computed>"
          tags.%:         "0" => "1"
          tags.Name:      "" => "terraform-testacc-routetable-data-source"
          vpc_id:         "" => "<computed>"
        
        STATE:
        
        aws_route_table.test:
          ID = rtb-6c5edd04
          propagating_vgws.# = 0
          route.# = 0
          tags.% = 1
          tags.Name = terraform-testacc-routetable-data-source
          vpc_id = vpc-86cc14ee
        
          Dependencies:
            aws_vpc.test
        aws_route_table_association.a:
          ID = rtbassoc-82b897ea
          route_table_id = rtb-6c5edd04
          subnet_id = subnet-406ff628
        
          Dependencies:
            aws_subnet.test
            aws_route_table.test
        aws_subnet.test:
          ID = subnet-406ff628
          availability_zone = eu-central-1a
          cidr_block = 172.16.0.0/24
          map_public_ip_on_launch = false
          tags.% = 1
          tags.Name = terraform-testacc-data-source
          vpc_id = vpc-86cc14ee
        
          Dependencies:
            aws_vpc.test
        aws_vpc.test:
          ID = vpc-86cc14ee
          cidr_block = 172.16.0.0/16
          default_network_acl_id = acl-d874ceb0
          default_route_table_id = rtb-685edd00
          default_security_group_id = sg-96776afe
          dhcp_options_id = dopt-3e0ec857
          enable_dns_hostnames = false
          enable_dns_support = true
          instance_tenancy = default
          main_route_table_id = rtb-685edd00
          tags.% = 1
          tags.Name = terraform-testacc-data-source

[grubernaut]

Believe this is now fixed.

[grubernaut]

Spoke too soon, still occurring.

[codycushing]

Experiencing same "plan was not empty" symptom with a data source using depends_on in acceptance tests in the Oracle provider as well. In actual use this causes subsequent plan/apply calls to refresh the data source.

[radeksimko]

I have extracted the config from linked acceptance test and upgraded to 0.12 syntax. I can't tell if this is still reproducible in the same way as (1) the report is quite old now, and (2) testing framework makes certain assumptions that Terraform itself may not.

That said I see that there's still something possibly weird happening.

Usually data sources themselves never trigger confirmation from the user, but that's exactly what's happening here. When you apply the config below and run apply again, you'll see plan with the following

  # data.aws_route_table.by_filter will be read during apply
  # (config refers to values not yet known)
 <= data "aws_route_table" "by_filter"  {
...

  # data.aws_route_table.by_id will be read during apply
  # (config refers to values not yet known)
 <= data "aws_route_table" "by_id"  {
...

  # data.aws_route_table.by_subnet will be read during apply
  # (config refers to values not yet known)
 <= data "aws_route_table" "by_subnet"  {
...

  # data.aws_route_table.by_tag will be read during apply
  # (config refers to values not yet known)
 <= data "aws_route_table" "by_tag"  {
...

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

---

terraform {
  required_version = ">= 0.12"
}

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

resource "aws_vpc" "test" {
  cidr_block = "172.16.0.0/16"
  tags = {
    Name = "terraform-testacc-data-source"
  }
}

resource "aws_subnet" "test" {
  cidr_block = "172.16.0.0/24"
  vpc_id     = aws_vpc.test.id
  tags = {
    Name = "terraform-testacc-data-source"
  }
}

resource "aws_route_table" "test" {
  vpc_id = aws_vpc.test.id
  tags = {
    Name = "terraform-testacc-routetable-data-source"
  }
}

resource "aws_route_table_association" "a" {
  subnet_id      = aws_subnet.test.id
  route_table_id = aws_route_table.test.id
}

data "aws_route_table" "by_filter" {
  filter {
    name   = "association.route-table-association-id"
    values = [aws_route_table_association.a.id]
  }
  depends_on = [aws_route_table_association.a]
}

data "aws_route_table" "by_tag" {
  tags = {
    Name = aws_route_table.test.tags["Name"]
  }
  depends_on = [aws_route_table_association.a]
}

data "aws_route_table" "by_subnet" {
  subnet_id  = aws_subnet.test.id
  depends_on = [aws_route_table_association.a]
}

data "aws_route_table" "by_id" {
  route_table_id = aws_route_table.test.id
  depends_on     = [aws_route_table_association.a]
}

---

If there is a bug related to ordering, it's core that decides how to order nodes in the graph anyway, so I'm going to migrate this back there.

[jbardin]

Thanks @radeksimko, not sure how this issue laid around open for so long.
The only problem here is that you can't use depends_on in a data source.

[grubernaut]

[jbardin]

@grubernaut, #17034 is a good reference, and will likely be the the solution to allow them.

[grubernaut]

most excellent, thanks! 😄

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