Terraform-provider-azurerm: Azure_virtual_machine: Missing `force_new` from `storage_os_disk.name`

[lawrencegripper]

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

Terraform (and AzureRM Provider) Version

13:27 $ tf -v
Terraform v0.11.8

• provider.azurerm v1.21.0
• provider.random v2.0.0
• provider.template v2.0.0

Affected Resource(s)

• azurerm_vritual_machine

Terraform Configuration Files

resource "azurerm_virtual_machine" "mongo" {
  count = "${var.cluster_size}"

  name                  = "mongo-vm-${count.index}"
  location              = "${azurerm_resource_group.opencga.location}"
  resource_group_name   = "${azurerm_resource_group.opencga.name}"
  network_interface_ids = ["${element(azurerm_network_interface.mongo.*.id, count.index)}"]
  vm_size               = "Standard_DS1_v2"

  storage_image_reference {
    publisher = "Canonical"
    offer     = "UbuntuServer"
    sku       = "16.04-LTS"
    version   = "latest"
  }

  storage_os_disk {
    name              = "mongo-disk-${count.index}"
    caching           = "ReadWrite"
    create_option     = "FromImage"
    managed_disk_type = "Standard_LRS"
  }

  os_profile {
    computer_name  = "mongovm${count.index}"
    admin_username = "${var.admin_username}"
    custom_data    = "${element(data.template_cloudinit_config.config.*.rendered, count.index)}"
  }

  os_profile_linux_config {
    disable_password_authentication = true

    ssh_keys {
      path     = "/home/${var.admin_username}/.ssh/authorized_keys"
      key_data = "${var.ssh_key_data}"
    }
  }
}

Debug Output

* module.mongo.azurerm_virtual_machine.mongo[1]: 1 error(s) occurred:

* azurerm_virtual_machine.mongo.1: compute.VirtualMachinesClient#CreateOrUpdate: Failure sending request: StatusCode=0 -- Original Error: autorest/azure: Service returned an error. Status=<nil> Code="PropertyChangeNotAllowed" Message="Changing property 'osDisk.name' is not allowed." Target="osDisk.name"

Expected Behavior

As the API doesn't allow for changes to the storage_os_disk.name field I would expect the plan to recreate the resource via a force_new annotation on the field.

Actual Behavior

Apply fails with API error.

Steps to Reproduce

1. terraform apply
2. Update the name field under storage_disk_os
3. terraform apply

References

Current field definition is here.

Would this be better handled as part of #2807?

[katbyte]

@lawrencegripper, yes, this will hopefully be solved as part of v2.0 when the split described in #2807 happens.

[lawrencegripper]

On a semi-related note I've observed that the current resource, when created as above, creates a managed disk which isn't destroyed when the resource is destroyed by TF. This means a tf taint operation fails as the VM is removed but the disk remains. When TF attempts to recreate the resource it fails with Disk name already exists.

I'll try and do a better repro today and put in a separate issue if that would be useful.

[tombuildsstuff]

@lawrencegripper thanks for reporting this

On a semi-related note I've observed that the current resource, when created as above, creates a managed disk which isn't destroyed when the resource is destroyed by TF. This means a tf taint operation fails as the VM is removed but the disk remains. When TF attempts to recreate the resource it fails with Disk name already exists.

indeed, that's unfortunately intended behaviour at this time (since Terraform doesn't create the disk) - there is an optional delete_os_disk_on_termination field which, if set can delete the OS Disk - however this won't work in cases where the Terraform Configuration has been removed (rather than tainting) since we look this up in the config.

Since #956 is tracking the same thing, I'm going to close this issue in favour of #956 - would you mind subscribing to that issue for updates?

[hashibot[bot]]

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 feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 [email protected]. Thanks!

[hashibot[bot]]

This has been released in version 2.0.0 of the provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading. As an example:

provider "azurerm" {
    version = "~> 2.0.0"
}
# ... other configuration ...