HCCP-138 breaking changes for Peering and TGW attachment

[smaant]

🛠️ Description

This PR introduces a few breaking changes:

• hcp_aws_network_peering resource now requires peering_id to be specified and doesn't accept peer_vpc_cidr_block
• hcp_aws_network_peering datasource no longer returns peer_vpc_cidr_block
• hcp_aws_transit_gateway_attachment resource doesn't accept destination_cidrs anymore
• hcp_aws_transit_gateway_attachment datasource no longer returns destination_cidrs

In order to associate CIDRs with Peerings and TGW attachments one would have to use hcp_hvn_route resource, example:

resource "hcp_hvn_route" "hvn-to-peering" {
  hvn_link = hcp_hvn.hvn.self_link
  hvn_route_id = "hvn-to-peering"
  destination_cidr = "10.1.0.0/24"
  target_link = hcp_aws_network_peering.prod.self_link
}

Migrating existing Terraform managed Peerings and TGW attachments

There are two ways to migrate existing Peerings and TGW attachments managed by Terraform:

1. Recreate Resources with Updated Schema

   • This option is quicker but will result in downtime and possible data loss. Best for test environments. Will allow you to specify human-readable ids for the resources.
   • Comment out all hcp_aws_network_peering and hcp_aws_transit_gateway_attachment resources.
   • Run terraform apply to destroy currently existing connections.
   • Uncomment and update all hcp_aws_network_peering and hcp_aws_transit_gateway_attachment resource definitions to match the new schema.
   • Add corresponding hcp_hvn_route resources for each CIDR targeting corresponding peering connections or transit gateway attachment.
   • Run terraform apply to recreate connections.

2. Re-Import with Updated Syntax:

   • This option allows you to avoid downtime or data loss.
   • Update any hcp_aws_network_peering and hcp_aws_transit_gateway_attachment resource definitions to match the new schema. All values needed can be found on the details pages of Peerings and TGW attachment in the HCP UI.
   • Add corresponding hcp_hvn_route resources for each CIDR targeting corresponding peering connections or transit gateway attachments.
   • Run terraform import hcp_hvn_route.<route-name> <hvn-id>:<hvn-route-id> for each hcp_hvn_route. <hvn-route-id> can be found on the details pages of the corresponding HVN connection in the HCP UI.
   • Run terraform plan and make sure that there are no changes detected by the Terraform.

Example of Re-Importing Peering:
Given:

resource "hcp_hvn" "hvn" {
  hvn_id = "prod-hvn"
  region = "us-west-2"
  cloud_provider = "aws"
}

resource "hcp_aws_network_peering" "peering" {
  hvn_id = hcp_hvn.hvn.hvn_id
  peer_vpc_id = "vpc-845f29fc"
  peer_account_id = "572816266891"
  peer_vpc_region = "us-west-2"
  peer_vpc_cidr_block = "172.31.0.0/16"
}

Rewrite it to the new schema and add corresponding HVN route:

resource "hcp_hvn" "hvn" {
  hvn_id = "prod-hvn"
  region = "us-west-2"
  cloud_provider = "aws"
}

resource "hcp_aws_network_peering" "peering" {
  hvn_id = hcp_hvn.hvn.hvn_id
  // add `peering_id` that you can find in the HCP UI
  peering_id = "f03324a9-4377-4a54-9c15-958fd07ad77b"
  peer_vpc_id = "vpc-845f29fc"
  peer_account_id = "572816266891"
  peer_vpc_region = "us-west-2"
  // remove `peer_vpc_cidr_block`
  // peer_vpc_cidr_block = "172.31.0.0/16"
}

// Add a `hcp_hvn_route` resource for the peering's cidr
resource "hcp_hvn_route" "peering-route" {
  hvn_link = hcp_hvn.hvn.self_link
  // you can find this id in the HCP UI in the peering details page in the list of Routes
  hvn_route_id = "a8dda9a8-0f69-4fa0-b38c-55be302fdddb"
  destination_cidr = "172.31.0.0/16"
  target_link = hcp_aws_network_peering.peering.self_link
}

Run import for the hcp_hvn_route:

$ terraform import hcp_hvn_route.peering-route prod-hvn:a8dda9a8-0f69-4fa0-b38c-55be302fdddb

Run terraform plan to make sure there are no changes detected by the Terraform:

$ terraform plan
No changes. Infrastructure is up-to-date.

Example of Re-Importing TGW Attachment:
Given:

resource "hcp_hvn" "hvn" {
  hvn_id = "prod-hvn"
  region = "us-west-2"
  cloud_provider = "aws"
}

resource "hcp_aws_transit_gateway_attachment" "prod" {
  hvn_id                        = hcp_hvn.hvn.hvn_id
  transit_gateway_attachment_id = "prod-tgw-attachment"
  transit_gateway_id            = "tgw-0ee94b1a1167cf89d"
  resource_share_arn            = "arn:aws:ram:us-west-2:..."
  destination_cidrs             = ["10.1.0.0/24", "10.2.0.0/24"]
}

Rewrite it to the new schema and add corresponding HVN route:

resource "hcp_hvn" "hvn" {
  hvn_id = "prod-hvn"
  region = "us-west-2"
  cloud_provider = "aws"
}

resource "hcp_aws_transit_gateway_attachment" "prod" {
  hvn_id                        = hcp_hvn.hvn.hvn_id
  transit_gateway_attachment_id = "prod-tgw-attachment"
  transit_gateway_id            = "tgw-0ee94b1a1167cf89d"
  resource_share_arn            = "arn:aws:ram:us-west-2:..."
  // remove `destination_cidrs`
  // destination_cidrs             = ["10.1.0.0/24", "10.2.0.0/24"]
}

// add `hcp_hvn_route` for each cidr associated with the TGW attachment
resource "hcp_hvn_route" "tgw-route-1" {
  hvn_link = hcp_hvn.hvn.self_link
  // you can find this id in the HCP UI in the TGW attachment details page in the list of Routes
  hvn_route_id = "35392425-215a-44ec-bbd0-051bb777ce5f"
  destination_cidr = "10.1.0.0/24"
  target_link = hcp_aws_transit_gateway_attachment.prod.self_link
}

resource "hcp_hvn_route" "tgw-route-2" {
  hvn_link = hcp_hvn.hvn.self_link
  // you can find this id in the HCP UI in the TGW attachment details page in the list of Routes
  hvn_route_id = "9867959a-d81b-4e52-ae8e-ca56f9dd06fc"
  destination_cidr = "10.2.0.0/24"
  target_link = hcp_aws_transit_gateway_attachment.prod.self_link
}

Run import for each hcp_hvn_route you've added:

$ terraform import hcp_hvn_route.tgw-route-1 prod-hvn:35392425-215a-44ec-bbd0-051bb777ce5f
...

$ terraform import hcp_hvn_route.tgw-route-2 prod-hvn:9867959a-d81b-4e52-ae8e-ca56f9dd06fc
...

Run terraform plan to make sure there are no changes detected by the Terraform:

$ terraform plan
No changes. Infrastructure is up-to-date.

[xargs-P]

Well written @smaant 💪 ,as hvn_routes are a new concept to users. In your description can you refer/link to the docs for that?
Come to think of it 🤔 is hvn routes commited yet?

Either way, I am thinking...

1. It would be good to have your description point to that hvn route documentation so the change log will have good pointers .
2. The README.md example updated to reflect the new changes.
3. Create an update or migration guide doc, containing the details of your PR description . This will help with users who may not visit the github changelog page. CC @bcmdarroch from the conversation on the other doc. You may be doing this in another PR.

[bcmdarroch]

Excellent work! 👍 We paired on testing all the migration steps and they worked as expected. ✅

[smaant]

@xargs-P I've updated description to include a link to the hcp_hvn_route doc, which is still only on this feature branch but it should be enough for now. I think Brenna took care of the rest of your suggestions. Gonna merge this into the feature-hvn-routes branch where we collect all hvn-routes related changes. This PR will be closed but still available via the link.