ansible-collections / azure

Development area for Azure Collections
https://galaxy.ansible.com/azure/azcollection
GNU General Public License v3.0
246 stars 327 forks source link

azure_rm_virtualmachine option for auto delete all resources connected to created VM #1208

Open toutas opened 1 year ago

toutas commented 1 year ago

I could not find a similar issue for azure_rm_virtualmachine

SUMMARY

creating a virtual machine using azure_rm_virtualmachine does not allow you to set flags on associated resources (like data/os disks, nics) that tell those resources to be deleted when the virtual machine itself is deleted. I would like functionality for this, similar to what has been added to.

ISSUE TYPE
COMPONENT NAME

azure_rm_virtualmachine

ADDITIONAL INFORMATION

Cleaning up resources from deleted virtual machines, especially spot machines, is somewhat of a pain in the ass if the associated virtual machine has been created using azure_rm_virtualmachine (and thus without auto delete). At worst it is required to go through the azure portal to check which resources associated with the deleted VM were not removed alongside it. Adding this functionality will lower the amount of labor required to delete resources that should have the same lifetime as the VM, and will make it a lot more manageable for spot eviction handling

- name: Create a VM with OS and multiple data managed disks -- autodelete
  azure_rm_virtualmachine:
    resource_group: myResourceGroup
    name: testvm001
    vm_size: Standard_D4
    managed_disk_type: Standard_LRS
    admin_username: "{{ username }}"
    ssh_public_keys:
      - path: /home/adminUser/.ssh/authorized_keys
        key_data: < insert your ssh public key here... >
    image:
      offer: 0001-com-ubuntu-server-focal
      publisher: canonical
      sku: 20_04-lts-gen2
      version: latest
    data_disks:
      - lun: 0
        managed_disk_id: "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxxxxx/resourceGroups/myResourceGroup/providers/Microsoft.Compute/disks/myDisk"
      - lun: 1
        disk_size_gb: 128
        managed_disk_type: Premium_LRS
        deleteOption: Delete <------- suggested addition

https://learn.microsoft.com/en-us/azure/virtual-machines/delete?tabs=rest2%2Ccli3%2Cportal4%2Cportal5

I am unfamiliar with the API used, but the link above shows the functionality as part of the REST API/CLI/etc

Fred-sun commented 1 year ago

@toutas We can manage which resources to remove with the 'remove_on_absent' parameter. Did you encounter any problems when deleting? Thank you!

toutas commented 1 year ago

@Fred-sun the use-case is explicitly auto-deletion of resources when the VM is deleted, even when not using azure_rm_virtualmachine to delete VM.

My understanding of 'remove_on_absent' is that it is only relevant if azure_rm_virtualmachine is used to delete the VM, but that is not the case for Spot evictions.

I have tested it, with 'remove_on_absent' set to 'all', which fails to clear up Spot VM associated resources even after it is evicted and deleted.

Fred-sun commented 1 year ago

@toutas You create a virtual machine, to add a 'deleteopition' flag to one of the data disks, the purpose is to delete later? right?

toutas commented 1 year ago

@Fred-sun that is correct, the deleteoption flag on the data disks, os disk, and other relevant resources are for the purpose of telling azure that it should delete these resources if their associated VM is deleted somehow.

The key takeaway is that no further action is required for deletion besides setting the deleteOption flag during provisioning/creation with azure_rm_virtualmachine. Afterwards azure will automatically delete the resources associated with the VM if the VM is deleted in one way or another (e.g. if a Spot VM is evicted and deleted, which is an action that happens automatically without user input)

Fred-sun commented 1 year ago

@toutas That sounds great, and this flag we want to keep has to go with the resource we created. However, the python SDK does not support this flag, so it is not possible to do it for the time being. Thank you!