terraform-provider-azurerm: Unable to destroy VM protected items
Community Note
- Please vote on this issue by adding a đ reaction to the original issue to help the community and maintainers prioritize this request
- Please do not leave â+1â or âme tooâ comments, they generate extra noise for issue followers and do not help prioritize the request
- If you are interested in working on this issue or have submitted a pull request, please leave a comment
Hi,
recently I am unable to delete VM protected items. I suspect this could be due to Azure backend change.
from Azure portal it mentioned VM is deleted in deferred delete but Terraform expect Not Found
Terraform (and AzureRM Provider) Version
Terraform v0.11.11 AzureRm 1.33.1
Affected Resource(s)
azurerm_recovery_services_protected_vm
Terraform Configuration Files
resource "azurerm_recovery_services_protected_vm" "vm1" {
resource_group_name = "${azurerm_resource_group.example.name}"
recovery_vault_name = "${azurerm_recovery_services_vault.example.name}"
source_vm_id = "${azurerm_virtual_machine.example.id}"
backup_policy_id = "${azurerm_recovery_services_protection_policy_vm.example.id}"
}
Expected Behavior
azurerm_recovery_services_protected_vm.vm1: destroy completed.
Actual Behavior
azurerm_recovery_services_protected_vm.vm1: Still destroying... (ID: <vm_resource_id>, 30m0s elapsed)
Error: Error applying plan:
1 error(s) occurred:
* azurerm_recovery_services_protected_vm.vm1 (destroy): 1 error(s) occurred:
* azurerm_recovery_services_protected_vm.vm1: Error waiting for the Recovery Service Protected VM "VM;iaasvmcontainerv2;vm_resource_group;test_vm1" to be false (Resource Group "recovery_vault_resource_group") to provision: timeout while waiting for state to become 'NotFound' (last state: 'Found', timeout: 30m0s)
Steps to Reproduce
terraform applyterraform destroy
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Reactions: 87
- Comments: 24 (4 by maintainers)
@jcanongfi Yes itâs still there. Destroying a
azurerm_backup_protected_vmresource with soft delete enabled results in endless loop (I guess for 14 days). What would be ideal is ifazurerm_backup_protected_vmdestroy could consider soft delete as âdestroyedâ. I have no problems with soft delete existing but would prefer to avoid direct state manipulation to work around it hanging on destroy (even after manual deletion).Have we started looking into this yet? Currently removing state manually works but I donât think that should be the case as it hinders automation.
@Dev-Mivl , workaround is to manually remove Terraform State related with
azurerm_protected_itemresource address. AzureRm provider may need to change the return code for this resource.in my case, i will run
terraform state rm <resource_address>you can refer resource addressing for more info, or runterraform state listIt would be nice to have an option on the âazurerm_backup_protected_vmâ when it is added to say: ignore_soft_delete true/false So when a VM deployment is destroyed it just stops the backup and sets it to delete (with soft delete on) and continue the removal of the VM.
Or even having an option that says: in_state true/false That would give the option to deploy the resource but not add it to the state in the first place. So when the resource is removed it just removes the VM. I know this option would not stop the VM backup or delete it so the backup would fail. But at least that can be manually stopped and removed if an alert is triggered about failed backup. Difficult situation. Because that is essentially the same outcome by removing the resource from the state manually. It doesnât actually stop a VM backup.
Something like âignore_soft_delete true/falseâ would be ideal as it would be nice to when destroying a deployment that option allow the backup to be stopped and marked for deletion if âsoft deleteâ was enabled on the RSV and allow a resource to be destroyed unhindered.
<rant>At a minimum, I think items like this with a long history of issues should be flagged in the documentation. I was just testing some terraform to add the backup protected vm item and discovered the issue. There arenât any notes in the documentation and I had to come hunting in the issues section of the github page. This is completely backwards from a customer service perspective. If there are known issues, they should really be reflected in the docs so there is at least an opportunity to make a decision on using terraform to manage an item or not BEFORE I spin something up that I now have to perform state surgery on. This is extremely frustrating; especially in the current cybersecurity environment where we are all running around making sure our backups are managed better, are immutable, are tested, and we have full control on recovery. PLEASE do a better job on this in future.</rant>
It feels like here where we set up the target state and expect âNotFoundâ we should be able to pass multiple states in and allow for âNotFoundâ or âSoftDeletedâ or whatever status theyâre returning. In my mind, if I tell terraform to destroy an item but it sits in soft-deleted state for 14 days, itâs as good as gone (no expense, can be recreated).
It might require an overload of the state.WaitForState() method to allow multiple states to be terminal states, but it feels like a good extension since weâre likely to encounter this kind of thing on a variety of resources. Iâm no go expert but I could give it a try if the idea is suitable to others.
Is it possible to add an option to retain backup data on destroy of the
azurerm_recovery_services_protected_vmresource? (This would be in the scenario where soft-delete has been disabled in the vault⌠Via the Portal, when you select Stop Backup you get the option to delete or retain backup data)Does someone knows a workaround ? Right now, I guess we have to:
Does not seems clean at all, even impossible in CI environments.