Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

terraform_data ignoring local-exec destroy provisioner #34711

Closed
leuthelt opened this issue Feb 21, 2024 · 5 comments · Fixed by #35230
Closed

terraform_data ignoring local-exec destroy provisioner #34711

leuthelt opened this issue Feb 21, 2024 · 5 comments · Fixed by #35230

Comments

@leuthelt
Copy link

leuthelt commented Feb 21, 2024

Terraform Version

Terraform v1.7.3
on windows_amd64

Terraform Configuration Files

resource "terraform_data" "destroy_action" {
provisioner "local-exec" {
when = destroy
command = "echo 'Destroy-time provisioner'"
}
}

Debug Output

https://gist.github.com/leuthelt/aa9760f8ec5d4279261aa0e9857be418

Expected Behavior

Terraform should run the defined local-exec command during destroy.

Actual Behavior

Terraform is removing terraform_data resource from state without executing local-exec command.

Steps to Reproduce

  1. terraform init
  2. terraform apply
  3. comment out whole resource "terraform_data"
  4. terraform apply

Additional Context

No response

References

No response

@leuthelt leuthelt added bug new new issue not yet triaged labels Feb 21, 2024
@leuthelt
Copy link
Author

Current workaround is to use count with terraform_data like it's documented in https://developer.hashicorp.com/terraform/language/resources/provisioners/syntax#destroy-time-provisioners, but that isn't my understanding of a destroy trigger.

@apparentlymart
Copy link
Contributor

Hi @leuthelt,

In your reproduction steps you mentioned commenting out the entire resource block. That means that you removed the provisioner from the configuration, and so Terraform didn't execute it.

Therefore Terraform seems to have worked as designed here. If you want the provisioner to run then you must keep it in the configuration.

I think therefore that this issue is a feature request for a way to keep the destroy provisioner in the configuration even though the containing resource block has been removed, so that the instructions about what to do when destroying the object can outlive the declaration of the object. Would you agree?

@leuthelt
Copy link
Author

Hi @apparentlymart, I would agree to your comment.

@apparentlymart
Copy link
Contributor

apparentlymart commented Feb 22, 2024

Thank you for confirming.

This situation is one of the future improvements we considered when recently introducing the removed block type as a way to give Terraform hints and instructions for how to destroy something that isn't in the configuration anymore.

If we did that then instead of removing the block entirely you would replace it with a removed block like this:

# NOTE: not a working example yet;
# hypothetical future language feature
removed {
  from = terraform_data.destroy_action

  provisioner "local-exec" {
    when    = destroy
    command = "echo 'Destroy-time provisioner'"
  }
}

The idea here then is that removed blocks would support any number of provisioner blocks as long as they all specify when = destroy, and then Terraform would use them during the apply phase when destroying this object.

We have also considered a helper command like terraform rm terraform_data.destroy_action that would automatically replace the resource block with a removed block and copy over just the parts of the resource configuration that are relevant when destroying, to minimize the chance of human error when making changes like this.

Copy link

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.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jun 23, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants