Terraform-provider-aws: Allow import of aws_route_table_association

[hashibot]

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

---

Terraform Version

v0.8.7

Affected Resource(s)

• aws_route_table_association

Currently if you run terraform import on a aws_route_table_association you'll get an error:

* import module.X.aws_route_table_association.Y (id: rtbassoc-1234f171): resource aws_route_table_association doesn't support import

Allowing route table associations to be imported would be really useful. Right now, I can do it by manually editing the state file but it is an error prone process.

You can get the id of a route table association through

aws ec2 describe-route-tables --route-table-ids rtb-123436a4

They follow the format rtbassoc-XXXXX.

Thanks!

[ozbillwang]

In fact, when you import route table, it will import all route table associations together, but the name of aws_route_table_association resource has an issue:

aws_route_table_association.db
aws_route_table_association.db-1

It should be:

aws_route_table_association.db.0
aws_route_table_association.db.1

[ozbillwang]

@GuiSim

[apanagiotou]

Has anyone managed to bypass this even manually? I'm migrating CloudFormation to Terraform and I'm stuck at importing aws_route_table_association. Any guidance would be useful. Thanks

[pib]

@apanagiotou Yes, I have worked around it by using "terraform state mv".

For example, in the above post where it mentions that it automatically imports the wrong names, you can fix that by running:

$ terraform state mv aws_route_table_association.db aws_route_table_association.db.0
$ terraform state mv aws_route_table_association.db-1 aws_route_table_association.db.1

(or possibly [0] and [1], which is what I used)

[klloveall]

Just to clarify, the square brackets do work as mentioned at the end of @pib 's comment. Not sure if the dot notation he has works as well, but the following is (almost) exactly what I used:

terraform state mv [...].vpc.aws_route_table_association.external [...].vpc.aws_route_table_association.external[0]
terraform state mv [...].vpc.aws_route_table_association.external-1 [...].vpc.aws_route_table_association.external[1]
terraform state mv [...].vpc.aws_route_table_association.external-2 [...].vpc.aws_route_table_association.external[2]

[nunofernandes]

Also in need of this to migrate from cloudformation to terraform!

[pit]

This PRs probably will help solving this issue in a different way:
https://github.com/terraform-providers/terraform-provider-aws/pull/6999
https://github.com/terraform-providers/terraform-provider-aws/pull/5359
https://github.com/terraform-providers/terraform-provider-aws/pull/7282

[Indigenuity]

For route table associations that weren't automatically imported correctly or incorrectly, pull your state file for manual editing:

$ terraform state pull > mystate.tmp

Then edit mystate.tmp to include a resource like this:

"aws_route_table_association.private_app": {
    "type": "aws_route_table_association",
    "depends_on": [
        "aws_route_table.private_app",
        "aws_subnet.private_app"
    ],
    "primary": {
        "id": "rtbassoc-REDACTED",
        "attributes": {
            "id": "rtbassoc-REDACTED",
            "route_table_id": "rtb-REDACTED",
            "subnet_id": "subnet-REDACTED"
        },
        "meta": {},
        "tainted": false
    },
    "deposed": [],
    "provider": "provider.aws"
}

Make sure you've still got valid JSON with all the commas, then push the state file back:

$ terraform state push mystate.tmp
# Confirm the outputs of these all look right:
$ terraform state list
$ terraform apply
$ terraform state list

[dimisjim]

Best way is to define it in a resource block with the right arguments, plan it and then apply. If it already exists, you would basically only end up adding it to your state file. No reason to pull and edit the state file as @Indigenuity points to.

[Indigenuity]

@dimisjim Yes I think that's the intended behavior, but I ended up with a brief outage when I tried that approach, since it removed the association and then re-created it. User error perhaps, but that's the behavior I get with that approach.

[tmccombs]

If I attempt to apply my aws_route_table_association that I can't import, then I get the following error:

Error: Provider produced inconsistent final plan

When expanding the plan for
module.vpc.aws_route_table_association.public["dlb-c"] to include new values
learned so far during apply, provider "aws" produced an invalid new value for
.route_table_id: was known, but now unknown.

This is a bug in the provider, which should be reported in the provider's own
issue tracker.


Error: Provider produced inconsistent final plan

When expanding the plan for
module.vpc.aws_route_table_association.public["dlb-c"] to include new values
learned so far during apply, provider "aws" produced an invalid new value for
.subnet_id: was known, but now unknown.

This is a bug in the provider, which should be reported in the provider's own
issue tracker.

[bflad]

Support for importing aws_route_table_association resources has been merged and will release with version 2.22.0 of the Terraform AWS Provider, tomorrow. 👍 Thanks to @YakDriver for the implementation.

[hashibot[bot]]

This has been released in version 2.22.0 of the Terraform AWS provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading.

For further feature requests or bug reports with this functionality, please create a new GitHub issue following the template for triage. Thanks!

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