Terraform-provider-aws: Feature request: (AWS Provider) Data Source for aws_route_table_ids

[hashibot]

_This issue was originally opened by @consultantRR as hashicorp/terraform#13936. It was migrated here as part of the provider split. The original body of the issue is below._

---

It would be really great to have a Data Source for aws_route_table_ids, similar to the currently-available aws_subnet_ids Data Source.

One of several use cases I can think of would be to introspect an existing VPC, produce a list of all route table ids in that VPC so that one could then add a particular route to all route tables in the VPC by using an aws_route Resource with count. One workaround I tried was to produce a list of VPC subnets using
the aws_subnet_ids Data Source, and then discover all route table ids by using the aws_route_table Data Source with count and subnet_id as a parameter for each iteration, but this does not always work, because if there are one or more subnets that are (non-explictly) associated with the Main route table, TF will error as follows:

Your query returned no results. Please change your search criteria and try again.

[fawaf]

very much +1

[artburkart]

I've begun the necessary additions but still need to add tests before opening PR.
https://github.com/artburkart/terraform-provider-aws/commit/0205ad99fc067b47e06eb9ed3698e5ff77ea3c7e

[artburkart]

I forgot I was working on this. I probably won't add those tests, but if someone else is interested in getting it across the finish line and opening a PR, then by all means take the code, I'll leave it there for you.
😉 😘

[thalesac]

This is the same as #3409

[thalesac]

@artburkart Is there any docs / tutorial on how to write those tests?
What are the requirements for the PR to be accepted?
I'd like to contribuite since I hit a wall because of this.

[artburkart]

Good question @thalesac! When I first started contributing code, there weren't any docs on this, so I'd use the following query to reverse-engineer the process. Please note, this is an arbitrary example:
is:issue is:open acc test
The first search result for that link as of Feb 19, 2018 is: https://github.com/terraform-providers/terraform-provider-aws/issues/3001
Which would lead me to make this query.
Which would lead me to this snippet:
https://github.com/terraform-providers/terraform-provider-aws/blob/b8d4e1570fc43a2acee6b6e47f63c9db6b067fa2/aws/resource_aws_inspector_assessment_target_test.go#L14-L40

Each Config section uses a variable that represents a completed config for the given resource. For example, testAccAWSInspectorTargetAssessment corresponds to: https://github.com/terraform-providers/terraform-provider-aws/blob/b8d4e1570fc43a2acee6b6e47f63c9db6b067fa2/aws/resource_aws_inspector_assessment_target_test.go#L83-L94

Once the config is instantiated and the resource is created, the Check section verifies that what you expected to happen actually happened. So in this case, they've written a function (testAccCheckAWSInspectorTargetExists) that validates the state that resulted from the terraform apply against what they expected (this pattern of reinventing the wheel for basic validation functions is super common in the terraform code base): https://github.com/terraform-providers/terraform-provider-aws/blob/b8d4e1570fc43a2acee6b6e47f63c9db6b067fa2/aws/resource_aws_inspector_assessment_target_test.go#L72-L81

Finally, it's common to write functions that validate whether the resource was actually destroyed or not at the end of the test. This is the purpose of the testAccCheckAWSInspectorTargetAssessmentDestroy function in the first snippet.

I hope this helps. If you'd like more details, it looks like someone added contributing guidelines in June 2017. They can be found here: https://github.com/terraform-providers/terraform-provider-aws/blob/23f0892fd16f0611463f170e78ceb598385d16de/.github/CONTRIBUTING.md#writing-acceptance-tests

If you're blocked now and want to use this functionality before you finish the PR, you could always take my code and apply it to a local copy of terraform and build it for your own purposes. I believe you can do that by following the instructions here: https://github.com/terraform-providers/terraform-provider-aws/blob/23f0892fd16f0611463f170e78ceb598385d16de/.github/CONTRIBUTING.md#writing-acceptance-tests

It's been a while, so I don't remember all the details. As of version 0.10.8, you can pass in the -plugin-dir flag to tell terraform to use your own custom terraform-provider-aws.

Finally, this code by @joshuaspence may prove helpful to get you started. It's testing a similar thing in that it's a data source that provides a list of ids: https://github.com/terraform-providers/terraform-provider-aws/blob/b8d4e1570fc43a2acee6b6e47f63c9db6b067fa2/aws/data_source_aws_ami_ids_test.go

If it helps, here's the commit where data_source_aws_ami_ids were introduced: https://github.com/terraform-providers/terraform-provider-aws/commit/1bd7dd12e1a04550102e1e7468951a9abd5cca70

[bflad]

A new aws_route_tables data source has been released in version 1.25.0 of the AWS provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading.

[hashibot[bot]]

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 feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thanks!