Feature proposal: Allow providers to review planned resource deletion

[gdavison]

Use-cases

Terraform currently does not involve providers during the plan when deleting a resource. In most cases, this is a reasonable approach. However, there are some resources where deletion can have severe consequences, and it would be useful for the provider to warn the practitioner.

For example, a recent Slack outage was caused in part by the deletion of a resource related to DNSSEC in AWS's Route 53 DNS service. AWS documentation warns that there are several steps to follow, including waiting for DNS records with a typical TTL of 48 hours to propagate. The AWS console also includes this warning. The AWS provider, however, will happily delete the resource.

If Terraform were to call the provider when planning the deletion of a resource, the AWS provider would be able to present a warning to the practitioner.

Attempted Solutions

We will be updating the AWS provider documentation, though this may not be consulted at plan or apply time.

Proposal

Allow a resource to add a deletion plan hook where a warning or error can be returned.

[bflad]

Another potentially interesting use case in this area is that some APIs provide deletion/termination protection for resources. Theoretically resources could check that API to ensure a deletion could successfully occur, at least according to that particular value, otherwise returning an upfront error or warning (in the case the provider opts to forcibly delete the resource during destroy operations, sometimes based on a virtual "force destroy" attribute) during planning.

Any enhancements here will likely need to be applied to both protocol 5 and 6 so it can be beneficial to the whole provider ecosystem.

It might be interesting to decide whether it is more or less ideal to introduce a new RPC, e.g. PlanResourceDestroy, or reuse PlanResourceChange. There's some safety by creating a new RPC, which would need to be newly and separately handled. It can also better include the semantics of the situation, passing available data like configuration and state, but omitting fields like proposed new state which always will be empty.

For additional context, terraform-plugin-sdk/v2 currently short circuits PlanResourceChange RPC logic when the proposed new state is null, so there would need to be code changes to retrofit any destroy plan calls to that RPC. terraform-plugin-framework skips over some automatic logic when the plan is null, but unsure if there would need to be additional changes to support this functionality if it was overloaded on the existing RPC.

[bflad]

Sorry for the immediate followup comment, but this also reminded me of another potential use case. Some deletion APIs support the creation of a final data snapshot, which can be a little awkward to work with in Terraform due to destroy being completely reliant on state, not configuration. Having a destroy plan RPC might provide some additional error detection capabilities in these situations.

References:

• Terraform ignores skip_final_snapshot so it's impossible to delete rds db instance terraform-provider-aws#92
• Require final_snapshot_identifier when skip_final_snapshot = false. terraform-provider-aws#769
• Terraform seems to ignore "skip_final_snapshot" for rds cluster terraform-provider-aws#2588
• InvalidParameterCombination: FinalDBSnapshotIdentifier can not be specified when deleting a replica instance terraform-provider-aws#4276
• FinalSnapshotIdentifier is required when a final snapshot is required terraform-provider-aws#4910
• Cannot destroy an Aurora RDS cluster when it was built with a replication_source_identifier value terraform-provider-aws#6749

[github-actions]

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 have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.