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

Option to skip destroying dependant resources #30299

Open
alexwilcox9 opened this issue Jan 5, 2022 · 1 comment
Open

Option to skip destroying dependant resources #30299

alexwilcox9 opened this issue Jan 5, 2022 · 1 comment

Comments

@alexwilcox9
Copy link

Current Terraform Version

Terraform v1.1.2
on linux_amd64

Use-cases

I'm trying to improve the performance of my pipelines and am looking for a way to skip destroying certain child resources when the parent resource is being destroyed
For example I create many virtual machines in Azure and then create extensions on top of them. Deleting the virtual machine always deletes the extension but of course terraform doesn't know this so it spends time removing the extensions first.

Attempted Solutions

One solution I have come across is removing various child resources from state before removing the parent however this doesn't scale particularly well

Proposal

Some additional functionality in the lifecycle block that tells terraform which resources will be destroyed by the destruction of other resources so that it will then skip over destroying these resources if the plan says that the parent resource is being destroyed

resource "azurerm_virtual_machine" "example" {
  name                  = "acctvm"
  location              = azurerm_resource_group.example.location
  resource_group_name   = azurerm_resource_group.example.name
  network_interface_ids = [azurerm_network_interface.example.id]
  vm_size               = "Standard_F2"

}

resource "azurerm_virtual_machine_extension" "example" {
  name                 = "hostname"
  virtual_machine_id   = azurerm_virtual_machine.example.id
  publisher            = "Microsoft.Azure.Extensions"
  type                 = "CustomScript"
  type_handler_version = "2.0"

  settings = <<SETTINGS
    {
        "commandToExecute": "hostname && uptime"
    }
SETTINGS

  lifecycle {
  destroyed_by = [azurerm_virtual_machine.example]
}
}

In the example above when running a destroy the plan would show both resources are going to be removed but when it actually runs terraform skips straight to the virtual machine and just removes the extension from state.

References

I did have a search through other issues and found similar requests for inverse targeting but they don't quite seem to be after the same thing
Thanks!

@alexwilcox9 alexwilcox9 added enhancement new new issue not yet triaged labels Jan 5, 2022
@apparentlymart
Copy link
Contributor

Thanks for sharing this use-case, @alexwilcox9!

Typically we prefer to have Terraform be able to figure these things out for itself (with the help of providers) rather than bog the language down with various flags and tweakables to coax the correct behavior, and with that in mind I think the use-case you are describing here is one of the ones I was discussing in a much earlier broad proposal in #22094.

Due to its age it doesn't really match how we typically structure enhancement requests these days (use-case oriented, rather than solution-oriented), but does at least serve to show one possible way Terraform and providers could together collaborate to get this better behavior automatically (what I called "Containment Relationship"), so that there wouldn't be a need for another fiddly lifecycle option that Terraform users would need to understand in order to read an existing configuration using it.

However, that's not to say that we couldn't add an manual opt-in for this, and even if we do decide to go with a more automatic solution this new issue better represents the single use-case than my older one does, so I think it'd be good to use this to represent the specific use-case of optimizing away deletions that can happen "for free", regardless of how exactly we might achieve that, with the proposal you made here and something like what I described in #22094 both being initial candidates to consider. (There are probably other possible approaches, too!)

Thanks again for sharing this!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants