Open AndiB42 opened 4 years ago
was any resolution found to this?
I face the same issue wherein i create disks from snapshots and then attach the disks, but the snapshots are irrelevant beyond the disk creation so i want to forget them ignore they are required as a data source.
resource "azurerm_managed_disk" "os_disk" { count = var.migration ? 1 : 0
name = lower("${local.virtual_machine_name}_OSDisk")
create_option = "Copy"
public_network_access_enabled = false
zone = local.primary_zone
resource_group_name = data.azurerm_resource_group.virtualmachine.name
location = data.azurerm_resource_group.virtualmachine.location
storage_account_type = var.vm_storage_account_type
source_resource_id = data.azurerm_snapshot.os_disk_snapshot[0].id
disk_size_gb = data.azurerm_snapshot.os_disk_snapshot[0].disk_size_gb
hyper_v_generation = var.hyper_v_generation
}
Community Note
Terraform (and AzureRM Provider) Version
Terraform v0.12.6
+ provider.azurerm v1.42.0
+ provider.local v2.0.0
+ provider.null v3.0.0
+ provider.random v3.0.0
+ provider.tls v3.0.0
Affected Resource(s)
azurerm_managed_disk
Terraform Configuration Files
Expected Behavior
We want to update our tags for existing Disks in the resource-group. The Terraform-Plan shows us the following:
Actual Behavior
Terraform shows us this error:
Important Factoids
To understand the backgrounds of the issue, i have to explain the "history" of this disk. We've created this disk months ago in a subscription (here called: OLD-SUBSCRIPTION). Previously, it was created manually (not via Terraform) and it was a copy of a specific snapshot.
Then we've created two new cluster-setups in the so called NEW-SUBSCRIPTION, and this disk should be attached to one of the clusters. Because this Disk contains very important live-data for us, we've just moved the disk, from the old subscription to the new one. The other cluster should get a new Disk, so we've configured the create_option = "Empty". And we wanted to add the old disk in a Terraform-Managed manner. So we've added the ignore_changes part for create_option and source_resource_id and imported the existing disk with a Terraform import command to our Terraform-State. In short: Both disks are in basically the same setup in two cluster-setups. Both should be managed in Terraform and the create-option should be ignored by Terraform. In fact, the Plan looks as expected, but in the execution, the source_resource_id seems to be parsed... This can fail of course, because the Service_principal has no permission for this Subscription AND the searched Resource-Group does not exist anymore.
If we remove the ignore_changes part for create-option and source_resource_id, Terraform wants to recreate this "old" disk, what we want to avoid.
Steps to Reproduce
(I can only assume these steps to reproduce)