Skip to content

Instantly share code, notes, and snippets.

Last active January 20, 2018 20:04
Show Gist options
  • Save krisnova/c03e9ef8d20e0a50b4b8cc17520b6fbd to your computer and use it in GitHub Desktop.
Save krisnova/c03e9ef8d20e0a50b4b8cc17520b6fbd to your computer and use it in GitHub Desktop.
Destroy Provisioners in Terraform

Destroy Provisioners in Terraform

Feature Spec - Issue #386

Terraform users would like to see Terraform support destroy provisioners that would run before a destroy action. There are many use cases documented in the terraform github issue #386 on how this would be helpful to users.

It seems the Terraform community has a shared consesus that custom destroy steps should be handled somehow with a terraform provisioner. This feature spec is an attempt to propose a solution to the following question.

What would be the best way to implement custom destroy action with provisioners?

Using the three rules orignally proposed by @pmoust :

  • provisioners' actions must be idempotent
  • if a provisioner fails, destroy of resource is aborted.
  • a force option should taint/destroy the resource even if the on_destroy provisioner fails.

I have come up with a feature spec proposal that I think meets these 3 concerns with an elegant solution.

A new global provsioner argument "on_destroy".

Implement a new optional argument across all provisioners. This will give the user the ability to take advantage of all Terraform provisioners and allow them to be ran before a destroy action, and never during an apply. This also gives the user the ability to define the necessity of each destroy provisioner.

Durring an Apply() on a node while running a destroy operation Terraform will run configured provisioners. Based on their output and configured type, Terraform will either abort the Apply() or not.

Although this is backwards compatible in terms of a user not defining the new argument. This will break if a user attempts to define the argument while using an older version of Terraform.

The new on_destroy argument would support the following values :

  • "attempt"
  • "require"

Where "attempt" will define a destroy provisioner that will allow the destroy action to run on provsioner failure.

And "require" will define a destroy provisioner that will cause the destroy action to abort on provisioner failure.

All destory provisioners will be ignored by apply operations.

The presence of the on_destroy argument would serve as a flag that apply operations should respect in order to safely ignore destroy provisioners.

Example syntax :
resource "aws_instance" "web" {

    # This MIGHT succeed..
    # as a script might already exist on the server.
    provisioner "file" {
    	on_destroy = "attempt" 
        source = ""
        destination = "/tmp/"

    # This MUST succeed.. 
    # before the resource can be safely destroyed.
    provisioner "remote-exec" {
    	on_destroy = "require"
        inline = [
          "chmod +x /tmp/",
          "/tmp/ args"

The Story

As a Terraform user I can impliment any provisioner during a destroy operation. The provisioner will run before the destroy action takes place, and never during an apply operation. The execution of the destroy action will hinge on the success of the destroy provisioner and it's configured type.

As a Terraform user I can define the importance of my destroy provisioner(s). I will be able to abort a destroy action on a failed provisioner in some cases, and not in others.

As a Terraform user I can trust that provisioners will behave the same in both apply and destroy operations.

Success Criteria

  • Code with working examples to support story
  • Acceptance tests for both sad/happy paths for destroy provisioners
  • Documentation updates
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment