post_processing is a new and unsupported device provisioning states

During device provisioning, the API may return a state of post_provisioning.

This is only returned when deploying new, unreleased, images.

Upon encountering this new state, terraform will error with:

╷
│ Error: unexpected state 'post_provisioning', wanted target 'active, failed'. last error: %!s(<nil>)
│ 
│   with metal_device.vcf,
│   on main.tf line 8, in resource "metal_device" "vcf":
│    8: resource "metal_device" "vcf" {
│ 
╵

This state should be handled if encountered.

terraform-provider-metal/metal/resource_metal_device.go

Line 470 in ec6ec6f

    
           state, err := waitForDeviceAttribute(d, []string{"active", "failed"}, []string{"queued", "provisioning"}, "state", meta)

Example config:

provider "metal" {
 auth_token = var.token
}

variable "token" {}
variable "project_id" {}

resource "metal_device" "vcf" {
  hostname = "vcf-esx-01"
  hostname = "tf-test-vcf-marques"
  project_id = var.project_id
  facilities = ["ch3"]
  plan = "m3.large.x86"
  operating_system = "vmware_esxi_7_0_vcf"
  billing_cycle = "hourly"
}
terraform {
  required_providers {
    metal = {
      source = "equinix/metal"
    }
  }
  required_version = ">= 0.13"
}

The post_provisioning state will not be exposed in the API. We can ignore this.

Generally, we may want to take a posture of not assuming that Terraform will not know all possible states.

Either we error on unknown states, assuming we can know all the states, or we ignore states that are unknown to TF and only error on known bad states (and complete in known success states). It's a tricky problem.