terraform-provider-aws: EC2 Transit Gateway VPC Attachment "Transit gateway route table was deleted or no longer exists" when attaching to Shared Transit Gateway from another AWS Account
Community Note
- Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
- Please do not leave “+1” or “me too” comments, they generate extra noise for issue followers and do not help prioritize the request
- If you are interested in working on this issue or have submitted a pull request, please leave a comment
Terraform Version
Terraform: 0.11.10 AWS Provider: 1.50.0
Affected Resource(s)
- aws_ec2_transit_gateway_vpc_attachment
Terraform Configuration Files
resource "aws_ec2_transit_gateway_vpc_attachment" "VPC-Attachment" {
vpc_id = "${var.vpc_id}"
##value from shared transit gateway in another AWS account.
transit_gateway_id = "${var.transit_gw_id}"
subnet_ids = ["${var.subnet_ids}"]
transit_gateway_default_route_table_association = false
transit_gateway_default_route_table_propagation = false
}
Debug Output
https://gist.github.com/amall015/01e86a35645824f9fd6e035fc05c0483
Panic Output
N/A
Expected Behavior
Transit gateway VPC attachment should be created using shared Transit gateway from another account without describing the default route table, since the rtb information is not retrievable in the context of the shared account.
Actual Behavior
Error is produced stating:
error determining EC2 Transit Gateway Attachment (tgw-attach-#######) association to Route Table (tgw-rtb-#######): InvalidRouteTableID.NotFound: Transit Gateway Route Table tgw-rtb-####### was deleted or does not exist.
status code: 400, request id: 69239b45-69b2-475e-ae74-3e3c72baad0f
Steps to Reproduce
terraform apply- All subsequent terraform plans
Important Factoids
The VPC attachment resource IS created successfully. However the error always appears when trying to refresh the information about the resource. So the first plan works, the apply creates the resource and then fails, and then all plans after fail.
References
Spawned from comment in: EC2 Transit Gateway attachment associations cannot be non-default #6664 https://github.com/terraform-providers/terraform-provider-aws/issues/6664#issuecomment-443349234
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Reactions: 76
- Comments: 19 (4 by maintainers)
Hi Folks 👋 (and thanks to @andrewsuperbrilliant for an initial fix implementation 🥇), sorry for the hassle and delays here! When the EC2 Transit Gateway resources were initially under development prior to its general availability release around AWS re:Invent last year, the Resource Access Manager (RAM) service was announced around the same time, so its functionality and interaction with Transit Gateways was unknown at the time. 😅
Generally in Terraform, we do not have Terraform resources for ensuring infrastructure removal beyond cases unless we are completely managing the whole configuration for a piece of infrastructure. Managing the full EC2 Transit Gateway Default Route Table seemed problematic given how Routes are inserted automatically in many scenarios. As a compromise, the intention of the
transit_gateway_default_route_table_associationandtransit_gateway_default_route_table_propagationarguments on theaws_ec2_transit_gateway_vpc_attachmentresource was to help operators target removing EC2 Transit Gateway Default Route Table Routes for the specific VPC attachment, which works great if you have access to the Default Route Table.As outlined in this issue, trying to read and manage the EC2 Transit Gateway Default Route Table configuration for a RAM shared EC2 Transit Gateway is not possible. The fix as started by #7513 is on the correct path, but is missing covering acceptance testing to ensure this functionality works with Terraform resource import and prevent regressions. Historically we have not setup the Terraform AWS Provider acceptance testing with multiple AWS accounts, so we have spent some time getting an implementation of that going that is easy to implement across potentially hundreds of acceptance tests.
The good news here is that #7513 will get some review items today just for the resource changes and adding some additional documentation. After those are addressed, we will merge in the fixes for this issue. After a certain degree of testing complexity, especially for new acceptance testing concepts that may need additional vetting, we do not fully expect every contributor to be able to implement the testing to the maintainer’s desires so we will accept the contribution after manually verifying it one last time using placeholder testing with our new setup (to be merged in separately after the fact).
We should be able to get the fixes released either middle of this upcoming week or the next. The timing and release numbers are a little indeterminate at the moment as we are looking to merge in Terraform 0.12 provider support, which is still being finalized, so apologies for being more vague than usual on the timing and version.
Same issue as everyone else above even with:
Any updates on a fix?
Experiencing the same issue with Terraform v0.11.11 and provider.aws v1.55.0.
Any update?
This has been released in version 2.2.0 of the Terraform AWS provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading.
Removing those two arguments did resolve my issue. Should be error message be updated to reflect that they are not valid in this case instead of “route table does not exist”?
Thank you for your help.