v0.8.2 (Windows x64 -x86)
I have not tested this with other resource types
I have included the relevant portion. My full configuration file only contains a single resource group, the network interface for the VM in question, and pub IP for said interface.
resource "azurerm_virtual_machine" "default" {
name = "${var.sys_name}-Vm"
location = "${var.location}"
resource_group_name = "${azurerm_resource_group.default.name}"
network_interface_ids = ["${azurerm_network_interface.default.id}"]
vm_size = "${var.vm_size_map["prod.webrtc"]}"
#VIP as it removes orphaned VHDs
delete_os_disk_on_termination = true
lifecycle {
ignore_changes = [ "storage_os_disk.vhd_uri" ]
}
storage_os_disk {
name = "osdisk"
os_type = "linux"
image_uri = "${var.image_uri}"
vhd_uri = "https://${var.vhd_storage_account}.blob.core.windows.net/${lower(var.tag_role)}-${lower(var.tag_env)}/${var.tag_role}-osdisk.${uuid()}.vhd"
caching = "None"
create_option = "FromImage"
}
os_profile {
#All computernames are lowercase
computer_name = "${lower(var.sys_name)}"
admin_username = "ubuntu"
#Required but should be ignored since we use SSH keys
admin_password = "Password1234!"
}
os_profile_linux_config {
#All computernames are lowercase
disable_password_authentication = true
#ssh_keys
ssh_keys {
path = "/home/ubuntu/.ssh/authorized_keys"
key_data = "${var.ssh_cert}"
}
}
tags {
Creator = "${var.tag_creator}"
Environment = "${var.tag_env}"
Role = "${var.tag_role}"
OSType = "Linux"
SourceVhd = "${var.image_uri}"
}
}
https://gist.github.com/samirageb/b861ff4f07dab020d79d7dffc460c087
Resource should have been created
No resource created, with this message: * azurerm_virtual_machine.default: diffs didn't match during apply. This is a bug with Terraform and should be reported as a GitHub Issue. Mismatch reason: attribute mismatch: storage_os_disk.3006723302.caching
As best as I can tell, a TF file virtual machine with a name using UUID() in the storage_os_disk.vhd_uri property, with terraform apply, will create this issue. Lifecycle -> ignore_changes doesn't seem to work.
terraform applyChanging the caching value doesn't seem to affect anything, since the numerical IDs aren't coinciding between the 'plan' and 'apply' runs. I have had this problem in older editions of Terraform, but hoped .8 might fix it. I am using remote state with Azure as the backend, no modules are being used. On failure, the virtual_machine is removed from the .tfstate file.
No other references applicable.
Same problem with GCE provider, resource "google_compute_instance" but probably it is resource independent, it occurs from 0.8-rc1 to 0.8.2
Ignore changes don't work with nested attributes unless you give it the exact index. In the future we'd like to support this but that'll require better typing in the state so we can know that foo.bar references a list of bar.
@mitchellh Would the proper syntax be this then?
lifecycle {
ignore_changes = [ "storage_os_disk[4]" ]
}
Bump, can anyone quickly answer the previous question?
@mitchellh Why closing? Is there a workaround? Even if it can't be supported, isn't it a valid use case? In fact it's a big issue for anything 'dynamic' running on azure, like k8s.
@mitchellh Why closing? Is there a workaround? Even if it can't be supported, isn't it a valid use case? In fact it's a big issue for anything 'dynamic' running on azure, like k8s.
+1
Ignore changes don't work with nested attributes unless you give it the exact index. In the future we'd like to support this but that'll require better typing in the state so we can know that foo.bar references a list of bar.
This doesn't look like a solution.
I never really followed up on how to get the UUID working properly. My current workaround is this:
1.) Create a new resource
resource "random_id" "azure_vhd" {
count = "${var.count_vm}"
byte_length = 8
}
2.) Reference this in the line:
vhd_uri = https://${var.vhd_storage_account}.blob.core.windows.net/${lower(var.tag_role)}-${lower(var.tag_env)}/${var.sys_name_label}-osdisk.${element(random_id.azure_vhd.*.b64, count.index)}.vhd
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 have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.
Most helpful comment
Bump, can anyone quickly answer the previous question?