Plans should generate an error when they show deletion of a resource that has deletion protection enabled

[joe-a-t]

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.
• If an issue is assigned to a user, that user is claiming responsibility for the issue.
• Customers working with a Google Technical Account Manager or Customer Engineer can ask them to reach out internally to expedite investigation and resolution of this issue.

Description

There are a ton of resources with some kind of deletion protection arguments. Right now, no error is raised when making a plan to delete a resource with deletion protection enabled. Deletion protection only raises an error during the apply.

This creates a poor user experience where:

1. Someone opens a PR, the plan passes and makes it look like the resource will be successfully deleted
2. They merge the PR and kick off the apply
3. The apply fails because of deletion protection
4. They have to open a second PR reverting the change that caused the resource destruction to be triggered and disabling the deletion protection and get that merged and applied
5. They have to open a third PR redoing the change they attempted in the first PR and get that merged/applied.

A marginal improvement to this flow based on current behavior would be

1. Someone opens a PR, the plan fails because it is trying to delete a resource that is protected by a deletion protection argument
2. They have to open a second PR that just disables the deletion protection and merge/apply that prior to continuing with the first PR
3. They rebase the first PR and it plans, merges and applies successfully

A much better user experience would be:

1. Someone opens a PR, the plan fails because it is trying to delete a resource that is protected by a deletion protection argument
2. They update the existing PR to disable the deletion protection, at which point it plans, merges, and applies successfully

Based on the conversation in hashicorp/terraform#36229 (comment), it appears that the provider should be able to implement these improved workflows.

While I think that this behavior should change globally, if there are objections to plans failing because of deletion protection it could potentially be governed by a setting on the provider itself. But in my opinion, that complexity doesn't make a lot of sense because I don't know why someone would want to deliberately have failed applies.

New or Affected Resource(s)

• google_bigquery_table
• google_bigtable_instance
• google_bigtable_table
• google_container_cluster
• google_looker_instance
• google_project
• google_redis_cluster
• google_spanner_database
• google_sql_database
• google_sql_database_instance
• google_storage_bucket

Potential Terraform Configuration

N/A, no configuration changes required

References

• Allow precondition checks to access the plan's action for that resource terraform#36229
• Standardize documentation around deletion_protection, deletion_policy, force_deletion, etc #20308