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.
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.
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.
resource "aws_instance" "web" {
...
# This MIGHT succeed..
# as a script might already exist on the server.
provisioner "file" {
on_destroy = "attempt"
source = "script.sh"
destination = "/tmp/script.sh"
}
# This MUST succeed..
# before the resource can be safely destroyed.
provisioner "remote-exec" {
on_destroy = "require"
inline = [
"chmod +x /tmp/script.sh",
"/tmp/script.sh args"
]
}
}
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.
- Code with working examples to support story
- Acceptance tests for both sad/happy paths for destroy provisioners
- Documentation updates