Provide more context to terraform providers to avoid accidental resource deletions

[at-goog]

Use-cases

Many resources in GCP are stateful and accidentally deleting them is catastrophic. Due to lack of execution context, a terraform provider may drop and recreate a resource during an update. If providers have more information on which operation was triggered (apply vs destroy), they can choose to never drop certain kinds of stateful resources on apply (e.g. databases, Kubernetes clusters, etc.).

Attempted Solutions

Users can mark their resources with prevent_destroy = true. However, this has 2 issues -

1. Users must update their template (with prevent_destroy = false) for destroy to go through since lifecycle blocks don't support interpolation.
2. It requires explicit action from users and they need to be more vigilant about protecting their resources. Providers can do this automatically for them.

Proposal

While delegating work to a terraform provider, if more operational context can be provided (i.e. type of operation = apply vs. destroy, etc.), then provider can take the right action based on the type of resource and the user intent.

References

• Cannot use interpolations in lifecycle attributes terraform#3116

[paultyng]

I'm going to move this to the SDK, I believe the context is available on the wire, its just not bubbled up from the current SDK to the resource implementations.

[paddycarver]

I'm going to actually disagree with you there, @paultyng. Whether terraform apply or terraform destroy is called, I believe we only get an ApplyResourceChange RPC over the wire. I don't think we get to know whether it was from an apply or a destroy subcommand.

[adejoux]

Hello,

+1. Very interested by this feature or something equivalent to avoid accidental delete.

Regards,

Alain