[Feature Request] Add "deleted_by" meta-argument to resource lifecycle

[cybershoe]

Terraform Version

Terraform v1.6.6
on darwin_arm64

Use Cases

With some providers, deleting a resource also deletes subordinate objects associated with that resource (e.g: deleting a resource group deletes its contents, deleting an NGINXaaS for Azure deployment deletes its configurations and certificates, etc.). Where that behaviour is expected, a user should be able to specify in a resource's lifecycle block that deleting a related resource will also delete the subordinate resource; in that case terraform destroy should not explicitly delete the subordinate resource if it is already planning on deleting the parent resource.

There are two main benefits to this approach:

1. The destroy process is simplified. The resource provider presumably has a better understanding of the best order of operations to delete its subordinate resources. So long as the user is confident that the provider will properly perform the deletion, the implementation details should be left to the provider.

2. For providers with a less-than-perfect API success rate, this reduces the number of API calls, and therefore the chances of a failure preventing the destroy operation from succeeding.

Attempted Solutions

Currently, to prevent removal of a resource, I must delete it from the terraform state with terraform state rm. This works, but it is an extra imperative step that should be handled by terraform's order of operations planning.

Proposal

Add a "deleted_by" meta-parameter to the lifecycle block. The value of this parameter is another resource that, when deleted, will also destroy the resource in question. When terraform destroy is run, terraform will not explicitly destroy the subordinate resource if it is already planning to destroy the parent resource.

This should be an explicit meta-parameter. Terraform may not be able to know in all cases whether a subordinate resource is deleted by a particular parent resource, and in any event this behaviour may not even be desired, so it should be left to the discretion of the user.

References

Implements a use case from:

• feature request: inverse targeting / exclude #2253

Relates to:

• prevent_destroy should let you succeed #3874
• Exclude resources from the destroy process #23547

[crw]

Thanks for this feature request! If you are viewing this issue and would like to indicate your interest, please use the 👍 reaction on the issue description to upvote this issue. We also welcome additional use case descriptions. Thanks again!

[jbardin]

Hi @cybershoe,

This is more related to #22094 than the linked issues (and is in fact one of the use cases for that proposal). Adding the reference to the resource block alone doesn't really really help us here, because the resource configuration applies to one or more instances, and the reference can't describe the relationships between the individual instances.

More declarative configuration in this area is also being explored via the new removed block, but this particular type of relationship may not turn out to be handled due to not being able to clearly map out how the resource instances between resources are related.