Change in custom_data forces new VM resource

[andrey-dubnik]

Hi there,

I can see a bit of a problem with Azure TF behaviour as referencing custom_data to the data object computed attribute forces new VM by some reason.

Terraform Version

Terraform v0.11.4

• provider.azurerm v1.3.0
• provider.null v1.0.0
• provider.template v1.0.0

Affected Resource(s)

• azure_virtual_machine

Expected Behavior

Ignore custom_data on the second run

Actual Behavior

Machine gets recreated every time

Steps to Reproduce

Create data template resource

data "azurerm_storage_account" "jiira" {
  name                = "${azurerm_storage_account.jiira.name}"
  resource_group_name = "${azurerm_resource_group.hackrg.name}"
}

data "template_file" "cifsmount" {
  template = "${file("${path.module}/cloud-init.tpl.yaml")}"

  vars {
    jiira_sa_name      = "${var.jiira_sa_name}"
    jiira_sa_container = "${var.jiira_sa_container}"
    jiira_sa_key       = "${data.azurerm_storage_account.jiira.secondary_access_key}"
  }

  depends_on = ["data.azurerm_storage_account.jiira"]
}

Reference data template resource in the os_profile of the VM

  os_profile {
    computer_name  = "my-vm-${count.index}"
    admin_username = "bla"
    admin_password = "*****-vFt012"
    custom_data = "${data.template_file.cifsmount.rendered}"
  }

In the output there is a trigger to rebuild VM

      os_profile.2830592169.admin_password:                             "" => ""
      os_profile.2830592169.admin_username:                             "ops" => ""
      os_profile.2830592169.computer_name:                              "jiira-vm-0" => "" (forces new resource)
      os_profile.~2830592169.admin_password:                            <sensitive> => <sensitive> (attribute changed)
      os_profile.~2830592169.admin_username:                            "" => "ops"
      os_profile.~2830592169.computer_name:                             "" => "jiira-vm-0" (forces new resource)
      os_profile.~2830592169.custom_data:                               "" => "cfb348559dd4806545f****f24b15969d3f431ca35" (forces new resource)

If custom_data is commented then VM is not forced to re-create

References

[matt-FFFFFF]

I have a scenario that is related to this.

I have a local admin password stored in Azure Key Vault and I retrieve it like this. The null_resource dependency is a script that provisions the secret (if it doesn't exist) in Key Vault:

data "azurerm_key_vault_secret" "initial_local_admin_password" {
  name       = "${local.initial_local_admin_password_secret_name}"
  vault_uri  = "${azurerm_key_vault.kv.vault_uri}"
  depends_on = ["null_resource.provision_local_admin_password"]
}

Note: the secret state is intentionally not stored in Terraform

This secret value is passed into the azurerm_virtual_machine, using the admin_password parameter.

Because the state of the secret is not stored, it is seen as changed on every apply.

      os_profile.~3860824611.admin_password:                             <sensitive> => <sensitive> (attribute changed)
      os_profile.~3860824611.computer_name:                              "" => "wvd-dc-002" (forces new resource)
      os_profile.~3860824611.custom_data:                                "" => <computed> (forces new resource)

This forces a the resource to be created every time. Clearly not ideal.

Will provider v2.0 also address this issue? I do not really want to have to store the secret value in tfstate. It kind of defeats the point of using Key Vault.

[tombuildsstuff]

hi @adubnik @matt-FFFFFF

We're currently working on version 2.0 of the Azure Provider which we previously announced in #2807.

As a part of this we're introducing five new resources which will supersede the existing azurerm_virtual_machine and azurerm_virtual_machine_scale_set resources:

• azurerm_linux_virtual_machine
• azurerm_linux_virtual_machine_scale_set
• azurerm_virtual_machine_scale_set_extension
• azurerm_windows_virtual_machine
• azurerm_windows_virtual_machine_scale_set

We recently opened #5550 which adds support for the new Virtual Machine resources - and I'm able to confirm that this is fixed in the new Virtual Machine resource - however unfortunately we have no plans to backport this to the existing azurerm_virtual_machine resource.

In order to get feedback on these new resources we'll be launching support for these new resources as an opt-in Beta in an upcoming 1.x release of the Azure Provider and ultimately release these as "GA" in the upcoming 2.0 release. We'll post an update in #2807 when both the opt-in Beta (1.x) & GA (2.0) are available - as such I'd recommend subscribing to that issue for updates.

This issue's been assigned to the milestone "2.0" since this is where this will ship - however (due to the way that closing Github Issues from PR's works, to be able to track this back for future users) this issue will be closed once the first of the new resources have been merged.

Thanks!

[mamoit]

azurerm_linux_virtual_machine worked perfectly for me. This will reduce the amount of manual taints and the chance for error by a very large amount.

[ghost]

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 ...

[ghost]

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!