Docs and implementation differ w.r.t. operating_system reinstall behaviour

[kierdavis]

Terraform Version

Terraform v1.1.7
on linux_amd64
+ provider registry.terraform.io/cloudflare/cloudflare v3.13.0
+ provider registry.terraform.io/equinix/metal v3.2.2
+ provider registry.terraform.io/hashicorp/aws v4.8.0
+ provider registry.terraform.io/hashicorp/google v4.18.0
+ provider registry.terraform.io/hashicorp/local v2.2.2

Affected Resource(s)

• metal_device

Terraform Configuration Files

Relevant snippet. I can put together a minimal reproducer if required.

resource "metal_device" "host" {
  count = var.equinix_host_count

  hostname                = var.equinix_host_count == 1 ? var.equinix_hostname : format("%s%d", var.equinix_hostname, count.index)
  plan                    = var.equinix_plan
  metro                   = var.equinix_region
  operating_system        = var.equinix_os
  billing_cycle           = "hourly"
  project_id              = var.equinix_project
  hardware_reservation_id = var.equinix_reservation
  ipxe_script_url         = var.equinix_ipxe_script_url

  ip_address {
    type            = "public_ipv4"
    cidr            = 31
    reservation_ids = [metal_reserved_ip_block.ip_reservation.id]
  }

  ip_address {
    type = "private_ipv4"
    cidr = 31
  }

  # Whether the device should be reinstalled instead of destroyed when modifying user_data, custom_data, or operating system.
  reinstall {
    enabled = true
  }
}

Debug Output

Very long (our config manages ~600 resources) and it would be a pain to vet this log for any stray secrets / api keys. As mentioned above, I can put together a minimal reproducer if required.

Expected Behavior

The documentation says

reinstall - (Optional) Whether the device should be reinstalled instead of destroyed when modifying user_data, custom_data, or operating system.

So I would expect that if there's a diff on the operating_system field, then the resource should be reinstalled rather than being destroyed/created.

Actual Behavior

Terraform still wants to destroy/create the resource. See the diff reported in Terraform's output. Note that the only attribute marked "forces replacement" is operating_system, and that the metal_device's id is changing to a "known after apply" value.

References

• equinix/terraform-provider-metal#152 introduced the reinstall option. As far as I can tell, the implementation hasn't significantly changed since then.
  • I noticed that this PR changed ForceNew to false for both user_data and custom_data, but not for operating_system. Was there a reason to omit operating_system or was this simply a mistake?

[kierdavis]

Also, if changing operating_system triggers a reinstall, surely changing ipxe_script_url should as well?

[displague]

ipxe_script_url is trickier because you can change the ipxe_script_url field for post-provision reasons. https://github.com/equinix/terraform-provider-equinix/issues/159 is relevant.

The CustomizeDiff field should be in control of the operating_system ForceNew value, but it appears that the default of true is taking priority (unlike in the other fields where a default of false is given).

https://github.com/equinix/terraform-provider-equinix/blob/master/equinix/resource_metal_device.go#L72