Lifecycle option to keep/retain/detach resources on destroy

WilliamABradley commented 3 years ago

Current Terraform Version

Terraform v0.13.3

Use-cases

This feature would cover multiple use cases.

If you are destroying an environment, and you would like to keep a resource, then this would allow you to always unlink the resource from the Terraform state, without having to perform the terraform state rm command prior.
If this is a resource that will be destroyed anyway by a parent resource, a CDN Config resource, it will be destroyed regardless when you destroy the CDN, Kubernetes resources, etc, so destroying it beforehand is just wasting time.
If there is a resource that is failing to destroy due to some external dependency, that makes it impossible to destroy, e.g. an AWS Edge Lambda, Postgres Role attached to a database, etc. Perhaps it will be destroyed due to a parent resource, so it would be nice to have the option.

This also matches Cloudformation's Deletion Policy option which allows you to do this.

Attempted Solutions

terraform state rm achieves this, but it is inconvenient as you have to perform those commands each time, and add scripting.

Proposal

Style 1: Combine with prevent_destroy

resource "provider_resource" "resource" {
  lifecycle {
    on_destroy = "delete" | "retain" | "prevent/fail"
  }
}

Style 2: Retain prevent_destroy, but have more than one destroy property

resource "provider_resource" "resource" {
  lifecycle {
    detach_on_destroy = true
    # Could have both at the same time? prevent_destroy = true
  }
}

References

innovate-invent commented 3 years ago

I would like to see something along the lines of destroyed_with = <parent resource reference> that marks the resource as destroyed if the referred resource is destroyed

apparentlymart commented 3 years ago

@innovate-invent let's keep this issue focused on only the use-cases it already covers, because three disjoint use-cases in one feature request is already a lot to unpack without throwing in a fourth one! Feel free to open a new feature request issue to discuss what underlying problem would potentially be solved by that destroyed_with suggestion.

innovate-invent commented 3 years ago

my suggestion specifically relates to the second use case

daraul commented 3 years ago

I like the on_destroy = "retain" option.

It gets me around a problem I have where I found myself destroying my gandi_livedns_domain resource while testing. When I attempt to apply I get an error stating that the domain already exists; terraform doesn't know about it, so it attempts to create one.

I am not sure if this would be considered a bug in the provider, but being able to tell terraform "don't destroy this resource even if I tell you to destroy everything" sounds reasonable in cases like this.

innovate-invent commented 3 years ago

@daraul that is certainly a bug in the provider. If the provider reports that it has destroyed gandi_livedns_domain, yet the object remains, then that is a failure of the provider.

Michael-McClelland commented 2 years ago

This would be extremely helpful for resource teardown in situations where certain resources cannot be deleted due to security constrains. Many development paradigms at large organizations constrain deletion of certain resources entirely and also restrict directly running commands to alter state. This feature would significantly reduce friction in those situations.

dotdc commented 2 years ago

+1 for on_destroy = "retain"

fatbasstard commented 1 year ago

+1 from me!

I'm looking for a way to "abandon" a resources in 30+ workspaces (same codebase). It's a github repository that's now "archived" and I want to get it out my Terraform configuration with leaving the archived repositories out in the wild...

Cloudformation indeed has the "retain" option (https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-attribute-deletionpolicy.html).

I want this for Terraform. Now I have to go through 30 remote states to do an terraform rm while simultaniously removing the resource from code. While making sure nobody else starts a TF run....

andresvia commented 1 year ago

+1 for this feature, it will make the argument skip_destroy in ECS Task Definitions obsolete.

edit: an argument with the same name also exists for lambda functions.

iancward commented 3 months ago

It looks like there is a removed block, but it seems buried in the documentation and my initial searches didn't find it.

crw commented 2 months ago

Thanks, indeed removed block should cover this use case. If anyone has related or more nuanced issues surrounding this issue, please open a new ticket. Thanks very much!

autarchprinceps commented 1 month ago

removed block isn't really helpful, as it needs to be specified after the fact individually and e.g. outside modules, more like an import, whereas deletion policy in cloudformation or its equivalent suggested here would be specifying on the resource that it should preserved, even when you delete entire modules or the like, whereas prevent_destroy lifecycle errors in your apply instead of only removing the state without touching the real infrastructure.

github-actions[bot] commented 3 weeks ago

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.

hashicorp / terraform