Terraform-provider-local: Add ability to preserve local_file on destroy

Created on 5 Jan 2018 · 8Comments · Source: hashicorp/terraform-provider-local

_This issue was originally opened by @alanbchristie as hashicorp/terraform#17040. It was migrated here as a result of the provider split. The original body of the issue is below._

Would it be possible to add a do_not_destroy argument to the local_file configuration item so that when terraform destroy is executed the generated local file is left intact? The reason? I create dynamic content for a post-destroy Ansible script and it would be useful to keep the content of the locally-generated file for this playbook.

i.e. would it be acceptable to provide the ability to do this...

resource "local_file" "cleanup_vars" {
  content = "${data.template_file.cleanup_vars.rendered}"
  filename = "../../../ansible/aws-cleanup/vars.yml"
  do_not_destroy = true
}

With the above if terraform apply is re-excuted is is perfectly fine (and expected) to over-write any existing file.

Terraform Version

Terraform v0.11.1

Terraform Configuration Files

data "template_file" "cleanup_vars" {
  template = "${file("../../../ansible/aws-cleanup/vars.yml.tpl")}"

  vars {
    aws_region = "${var.aws_region}"
  }
}

resource "local_file" "cleanup_vars" {
  content = "${data.template_file.cleanup_vars.rendered}"
  filename = "../../../ansible/aws-cleanup/vars.yml"
}

Debug Output

n/a

Crash Output

n/a

Expected Behavior

n/a

Actual Behavior

n/a

Steps to Reproduce

n/a

Additional Context

n/a

References

n/a

enhancement

Source

hashibot

👍5

Most helpful comment

Hi @alanbchristie! Thanks for this feature request and sorry for the delay in responding to it.

The Terraform team at HashiCorp won't be able to work on this in the near future due to our focus being elsewhere, but we'd be happy to review a pull request if you or someone else has the time and motivation to implement it.

There is some precedent for options like this for resources where it's common to use Terraform to create them but to pass management onto some other system after a while. Usually these have names like verb_on_destroy, where "verb" is some suitable terminology for the resource in question. For this situation, I'd suggest naming the argument delete_on_destroy, having it default to true, and then having the explicit configuration be delete_on_destroy = false. This is consistent with other similar existing features like the nomad_job deregister_on_destroy argument.

(The reason for the *_on_destroy terminology here is that "destroy" in this context is Terraform's operation, which in turn causes other operations in the target system. Calling it do_not_destroy could be confusing since setting it won't actually prevent Terraform from destroying the resource instance itself. Instead, it adjusts the actions Terraform takes _when_ it destroys the resource instance.)

apparentlymart on 20 Feb 2018

👍3

All 8 comments

Hi @alanbchristie! Thanks for this feature request and sorry for the delay in responding to it.

apparentlymart on 20 Feb 2018

👍3

@apparentlymart I have attempted a resolution in #10, happy to take any feedback.

abn on 31 Mar 2018

Hello,
Same use case and same issue as @alanbchristie. any update regading this ticket ? Thanks in advance.

MOURIK on 9 Apr 2020

Thanks for your patience @abn while we improve our triage process for the HashiCorp providers. I'd like to understand more about your use case here: since you are calling terraform destroy but want to preserve this resource, it must be part of a larger config with additional kinds of resources that you do want to destroy. Could you outline the steps of this process and how the config is used?

kmoe on 7 Aug 2020

@kmoe To be honest, my memory of the original use case is a bit shoddy. But, as the description says, the particular case that lead to this was since we created a few resources on AWS that generated tokens and/or configurations that needed to be used to in order to clean up resources that were created post-apply outside of tf state, which needed to be cleaned up using an ansible playbook after destroy was called. The simple requirement is to be able to not delete a generated file; there are various other cases where this will come in handy in general.

abn on 7 Aug 2020

same here

HaveFun83 on 7 Jun 2021

still the same needed here

crazychatting on 26 Oct 2021

I'd love to say I'm still interested in this problem, but I'm not. Instead, as indicated at the start of the issue, I use Ansible as a controller so I just copy the file out of Terraform's way once the infrastructure's provisioned. Then, after I call destroy, when control switches back to my Ansible playbook, I have the file prior to its deletion and can do the required processing.

With regard to the earlier question in 2020 why anyone would want to keep such a file? Unlike other resources the fact it's a "local" resource should hint that it's typically does not play a crucial role within the infrastructure ... it's "local" after all (and would get re-written anyway when you run apply). And, maybe the fact that three others also think this is a good idea might also indicate that, maybe, it is?

Anyway - it's been more productive for me to code around the behaviour using an external tool.