Release 2.0.0 with Equinix Metal Metro support

[displague]

Release 2.0.0 introduces Metros https://feedback.equinixmetal.com/changelog/new-metros-feature-live.

The implementation status of various metro features is tracked in #28.

Ask questions about this release here! The moderators will bubble up Q&A into this discussion description and will link issues as needed. Any answer provided here should ultimately make it into the provider documentation. Let us know if we've missed something.

Keep in mind that answers for one resource type may not apply to another (metal_device resource behavior is not the same as metal_vlan or metal_reserved_ip_block behavior). If we are not being specific about which resource we are describing in a question or answer, or we omitted a resource, let us know.

State management is Terraform's purpose and this provider release, like all others, aims to fulfill that purpose. This can get tricky given all the possible ways facility and metro state can take form. While we covered the most common use-cases, some state change edge-cases may be blocked or destructive.

If you want to know more about Terraform state management and tainted resources, check out:

• https://www.terraform.io/docs/language/state/index.html
• https://www.terraform.io/docs/cli/state/taint.html

How do I use metros?

Devices

The facilities field is now optional. You can now specify a metro. The two fields can not be used together, and you can not change to the other field after deployment.

Wether you use the facilities or metro parameters, the deployed_facility and metro attributes will both reflect the location of the server.

resource "metal_device" "server" {
  ...
  metro = "SV"
}

Unlike facilities, you can not provide a list or use a special keyword like "any". Like facilities, you can not change the metro after deployment without the device being destroyed and recreated.

How do I continue to use facilities?

Do nothing different! Continue to set facilities to ["any"] or any set of facilities you prefer.
The behavior of changing this value has not changed, your device will be destroyed and recreated.

resource "metal_device" "server" {
  ...
  facilities = ["sjc1"]
}

How do I avoid tainting facility deployed devices once I update to a provider release with metro support?

It's best to not change the stated facilities or metro value once created. Take advantage of data sources or the deployed_facility and metro attributes.

How do I update my metal_device resources to specify a metro?

Removing the facilities field, and adding a metro field, even if the new value matches the attributes from state is not advised. Your device may be destroyed and recreated.

[displague]

We are aware of a bug affecting users with Metro bound VLANs using the metal_port_vlan_attachment resource: #69

This also affects users of the packet_port_vlan_attachment resource: packethost/terraform-provider-packet#307

If this bug is impacting you now, remove the metro bound resource (or use a different project for metro resources) until the fix has been released (subscribe to the issue for notification).

You will need the latest version of the Equinix Metal provider to take advantage of projects with metro bound VLANs.

The latest version of the Packet provider will be needed to avoid TF errors when using the packet_port_vlan_attachment resource in projects that contain metro scoped VLANs.

[displague]

This problem has been addressed in https://github.com/equinix/terraform-provider-metal/releases/tag/v2.0.1 of the Equinix Metal provider.

[displague]

The Packet provider was not affected by this bug as originally suspected. packethost/terraform-provider-packet#307 has been closed.