resource/aws_route53_zone_association: Support resource import and recreate resource on all updates

[bflad]

Community Note

• Please vote on this pull request by adding a 👍 reaction to the original pull request comment to help the community and maintainers prioritize this request
• Please do not leave "+1" comments, they generate extra noise for pull request followers and do not help prioritize the request

Closes #7964
Closes #2832

Changes proposed in this pull request:

• tests/resource/aws_vpc: Add acceptance testing to verify Terraform resource recreation after external deletion
• tests/resource/aws_route53_zone: Add acceptance testing to verify Terraform resource recreation after external deletion
• resource/aws_route53_zone_association: Support resource import and recreate resource on all updates

Previously the resource implemented an Update function that did not perform any updates. All attributes were switched to ForceNew: true and the Update function removed.

The new TestAccAWSRoute53ZoneAssociation_disappears_VPC acceptance test explicitly verified #2832 by showing DESTROY/CREATE on the resource for properly referenced VPC that was externally deleted from Terraform.

DESTROY/CREATE: aws_route53_zone_association.foobar
  vpc_id:     "vpc-0760bf69d6ba598c6" => "<computed>" (forces new resource)
  vpc_region: "us-west-2" => "<computed>"
  zone_id:    "Z3FP49IAL6M01X" => "Z3FP49IAL6M01X"
CREATE: aws_vpc.bar
  arn:                              "" => "<computed>"
  assign_generated_ipv6_cidr_block: "" => "false"
  cidr_block:                       "" => "10.7.0.0/16" (forces new resource)
  default_network_acl_id:           "" => "<computed>"
  default_route_table_id:           "" => "<computed>"
  default_security_group_id:        "" => "<computed>"
  dhcp_options_id:                  "" => "<computed>"
  enable_classiclink:               "" => "<computed>"
  enable_classiclink_dns_support:   "" => "<computed>"
  enable_dns_hostnames:             "" => "true"
  enable_dns_support:               "" => "true"
  instance_tenancy:                 "" => "default" (forces new resource)
  ipv6_association_id:              "" => "<computed>"
  ipv6_cidr_block:                  "" => "<computed>"
  main_route_table_id:              "" => "<computed>"
  owner_id:                         "" => "<computed>"
  tags.%:                           "" => "1"
  tags.Name:                        "" => "terraform-testacc-route53-zone-association-bar"

Output from acceptance testing:

--- PASS: TestAccAWSVpc_disappears (13.48s)

--- PASS: TestAccAWSRoute53Zone_disappears (40.98s)

--- PASS: TestAccAWSRoute53ZoneAssociation_basic (114.23s)
--- PASS: TestAccAWSRoute53ZoneAssociation_disappears (131.71s)
--- PASS: TestAccAWSRoute53ZoneAssociation_disappears_VPC (115.04s)
--- PASS: TestAccAWSRoute53ZoneAssociation_disappears_Zone (123.63s)
--- PASS: TestAccAWSRoute53ZoneAssociation_region (115.49s)

[nywilken]

LGTM 🚀

[bflad]

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

[borgstrom]

@bflad This caused breaking changes for anyone working around missing cross-account route53 association while waiting on #2005

If you have done authorization and association across account out-of-band (i.e. using the AWS CLI) this change causes those associations to now want to be removed when you pick up the new version of the provider.

For now we're going to ensure we don't pick up the 2.3.0 version of the provider, but I'm curious your thoughts on how we can move forward? Can we get a solution to #2005, or some how change this resource to NOT remove existing associations added out of band like before?

[bflad]

Hi @borgstrom 👋 Thanks for the report and sorry for any trouble. Can you please file a new top level GitHub issue following the bug report template so we have all the details to appropriately triage? Thanks.

It will be helpful to get the relevant configuration and plan output to see what can be done or if any immediate workarounds can be provided. Since cross-account authorizations are not explicitly supported by the Terraform AWS Provider currently, there is no acceptance testing for this scenario. Given the additional information, we may be able to write up new testing covering this scenario to prevent what sounds like a legitimate issue in the future, even without native Terraform support for cross-account authorizations.

[borgstrom]

Hi @bflad 👋

This actually turned out to be an internal change that was overlooked, and I was too quick to jump the gun and point fingers at your change.

Many apologies! 🙇

We're back in a good state.

Thanks for all the work on this project!

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