Terraform: Feature suggestion - Destroy Provisioner (local or remote exec)

[davehodgson]

Hi guys,

I've been working on a project on Azure and run into a couple of challenges because I want to create a VPN gateway and upload a cert as a part of the terraform script (https://github.com/hashicorp/terraform/issues/4116) I've come up with a workaround using the provisioner to call local-exec to a powershell command and from there written scripts to handle the work.

Unfortunately when I got to destroy the infrastructure the virtual network can't be destroyed because it need to have the certs and gateway deleted before it can be deleted.

This made me thing - it would be very useful to have a "reverse" provisioner or one that could be flagged as to be used for create/update/destroy, that way I could write the reverse script to tear down any infra I have built in this way or effectively run a reverse bootstrap operation to clean up anything that exists outside the terraform covered resources.

Just a thought.

[mtougeron]

This would also be useful to us so we could automatically remove the node & client from Chef server when the instance is destroyed by Terraform.

[gileshinchcliff]

+1
We're using Terraform to provision Kubernetes in AWS and we can't destroy completely because some resources are created by K8s which Terraform doesn't know about, ie loadbalancer, security groups.
Being able to bootstrap the command kubectl delete namespace to terraform destroy, would make things a lot simpler.

[gordonIanJ]

+1
It would be excellent to be able to exec upon destroy, in order to e.g. remove a key from a SaltStack master a la https://github.com/saltstack-formulas/ec2-autoscale-reactor

[karcaw]

+1 Would be really nice to have this!

[pll]

+1 - I need to drop users & tables from an RDS db upon destroy. I create the user and table space at spin-up, but short of (once again) writing a wrapper to run terraform, I have no way to reverse actions run at incarnation time.

[grayaii]

I would love to have to this too. As a workaround, we have a wrapper script that calls terraform, and upon "destroy", the wrapper script can then local-exec anything we want. It' not ideal, but gets the job done.

[gordonIanJ]

I think handling post-destroy in a wrapper is a good design decision. -1
for the feature.

On Friday, March 11, 2016, grayaii [email protected] wrote:

I would love to have to this too. As a workaround, we have a wrapper
script that calls terraform, and upon "destroy", the wrapper script can
then local-exec anything we want. It' not ideal, but gets the job done.

—
Reply to this email directly or view it on GitHub
https://github.com/hashicorp/terraform/issues/4121#issuecomment-195566464
.

[pll]

@gordonIanJ - Why? Do also object to remote execution of provisioners? Seems like this would be nothing more than enabling the reverse of that.

[billf]

destroy is sometimes explicit (terraform destroy ..) and sometimes implicit (-/+ due to re-creation). it would be nice to be able to trigger the same provisioner if either happens.

[DevBOFH]

+1

[mluedke]

+1. In addition to local/remote provisioner commands that need to be un-done during destroy, we have the same use case as @gileshinchcliff with Kubernetes creation of resources outside of Terraform.

[gposton]

+1, we are using terraform to create a vpc and a lambda function inside that VPC. Under the covers Lambda creates ENIs that terraform doesn't know about and those ENIs botch our destroy. A 'exec' on destroy would allow us to clean up those ENIs before terraform attempts to destroy the VPC.

[Alars-ALIT]

+1

[chrisevett]

+1

[rendicott]

+1

[bigdaddyvol]

+1

[saurabh-hirani]

+1

[mitchellh]

Dup of #386. Its coming!

[jsilberm]

+1

[iradaik]

+1

[hashibot[bot]]

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.