Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

vsphere_virtual_machine forces new on existing resource for computed value when adding resources #646

Closed
simonbirtles opened this issue Oct 29, 2018 · 1 comment

Comments

@simonbirtles
Copy link

simonbirtles commented Oct 29, 2018

I have written a custom provider to obtain new IPv4 host addresses from Infoblox, this provider is validated in working correctly. I have the issue with the vsphere_virtual_machine resource after having run terraform apply to create the initial resources. When the host count is updated say from 3 to 4, so to add another virtual machine, all VM resources created in the HCL below are maked for deletion and create as the clone ipv4_address is marked as;

clone.0.customize.0.network_interface.0.ipv4_address: "10.10.1.1" => (forces new resource)

The first apply created and assigned the IP address successfully but when increasing the count variable all resources must be recreated. When decreasing the count variable this situation does not occur and only the last resources created are deleted as expected and others (within the new count numbers) are left as is.

I understand that computed variables must be known when the plan is run but the situation is different between adding additional resources and removing some resources.

Terraform Version

Terraform v0.11.8

vSphere Provider Version

terraform-provider-vsphere_v1.8.1_x4

Affected Resource(s)

  • vsphere_virtual_machine
    clone/customize/network_interface/ipv4_address

Terraform Configuration Files

resource "infoblox_host_address" "host_address_idx" {
count = "${var.idx_host_count}"
ipv4_network = "${cidrhost(var.idx_ipv4_network, 0)}/${element(split("/", var.idx_ipv4_network),1)}"
dns_domain = "${var.dns_domain_name}"
hostname = "${format("%sidx-%02d", var.hostname_prefix, count.index + 1)}"
}

resource "vsphere_virtual_machine" "project_idx" {
count = "${var.idx_host_count}"
name = "${element(infoblox_host_address.host_address_idx.*.hostname,count.index)}"
num_cpus = "${var.idx_cpu_count}"
memory = "${var.idx_memory_mb}"
resource_pool_id = "${data.vsphere_compute_cluster.compute_cluster_project.resource_pool_id}"
datastore_cluster_id = "${data.vsphere_datastore_cluster.datastore_cluster_project.id}"
folder = "${vsphere_folder.folder_project_idx.path}"
guest_id = "${data.vsphere_virtual_machine.template_image_project_idx.guest_id}"
scsi_type = "${data.vsphere_virtual_machine.template_image_project_idx.scsi_type}"
tags = [
"${data.vsphere_tag.idx_tag.id}",
"${var.vsphere_project_tag}"
]

network_interface {
network_id = "${data.vsphere_network.network_project_idx.id}"
adapter_type = "${data.vsphere_virtual_machine.template_image_project_idx.network_interface_types[0]}"
}
disk {
unit_number = 0
label = "disk0"
size = "${ max( data.vsphere_virtual_machine.template_image_project_idx.disks.0.size , var.idx_disk_gb ) }"
eagerly_scrub = "${data.vsphere_virtual_machine.template_image_project_idx.disks.0.eagerly_scrub}"
thin_provisioned = "${data.vsphere_virtual_machine.template_image_project_idx.disks.0.thin_provisioned}"
}

clone {

template_uuid           = "${data.vsphere_virtual_machine.template_image_project_idx.id}"
customize {

  linux_options {
    host_name           = "${element(infoblox_host_address.host_address_idx.*.hostname,count.index)}"
    domain              = "${var.dns_domain_name}"
  }
  network_interface {                            
    ipv4_address        = "${element(infoblox_host_address.host_address_idx.*.ipv4_host_address,count.index)}"
    ipv4_netmask        = "${element(split("/", var.idx_ipv4_network),1)}"
  }
  ipv4_gateway          = "${data.infoblox_network_gateway.gateway.ipv4_gateway}"
  dns_server_list       = "${var.dns_server_list}"

}

}
}

Expected Behavior

Expected would be that the addition of resources would not effect the existing resources is the same way that removing some resources does not.
The plan runs a refresh prior to the plan being created which includes checking existing resources linked to other resources.

Actual Behavior

In this case, the vsphere_virtual_machine ipv4_address reference to the infoblox resource. The infoblox refresh returns the existing assigned IP address so why
does the vsphere_virtual_machine resource have to forcenew on this computed value when increasing the resource count.

Snip of plan output

-/+ module.project.vsphere_virtual_machine.project_idx[0] (new resource required)
id: "423bb623-8433-c003-3d65-943e3f02232" => (forces new resource)
boot_retry_delay: "10000" => "10000"
change_version: "2018-10-29T19:04:18.139628Z" =>
clone.#: "1" => "1"
clone.0.customize.#: "1" => "1"
clone.0.customize.0.dns_server_list.#: "1" => "1"
clone.0.customize.0.dns_server_list.0: "10.10.1.49" => "10.10.1.49"
clone.0.customize.0.ipv4_gateway: "10.10.1.5" => "10.10.1.5"
clone.0.customize.0.linux_options.#: "1" => "1"
clone.0.customize.0.linux_options.0.domain: "domain.corp" => "domain.corp"
clone.0.customize.0.linux_options.0.host_name: "yyy-xxx-idx-01" => "yyy-xxx-idx-01"
clone.0.customize.0.linux_options.0.hw_clock_utc: "true" => "true"
clone.0.customize.0.network_interface.#: "1" => "1"
clone.0.customize.0.network_interface.0.ipv4_address: "10.10.1.1" => (forces new resource)
clone.0.customize.0.network_interface.0.ipv4_netmask: "27" => "27"
clone.0.customize.0.timeout: "10" => "10"

@simonbirtles
Copy link
Author

correctly using: [] without element as per issue: #hashicorp/terraform#3449
ipv4_address = "${infoblox_host_address.host_address_idx.*.ipv4_host_address[count.index]}"

@ghost ghost locked and limited conversation to collaborators Apr 18, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant