Migrating from the Packet Provider

[displague]

Continued from packethost/terraform-provider-packet#288

Users coming from the Packet provider can convert their existing configurations to work with this provider.
This Equinix Metal provider is derived from v3.2.0 of the Packet provider.

The packet_ resources have all been renamed to metal_. Instructions to adapt existing projects to this provider should be included in the README.md.

Here are some initial thoughts on what this content should include.

---

When converting a project from Packet to Equinix Metal:

• Update to terraform-provider-packet v3.2.0 (Perhaps v3.2.1 to avoid the hardware_reservation_id problem)
• terraform plan, resolve any diffs before proceeding
• backup the existing configuration directory and state
• rename the packet_ references in the config and modules to metal_
• rename any packethost/packet references in the module to equinix/equinix-metal
• rename packethost references in the module to equinix
• repeat these renames within the tfstate files
• terraform init --upgrade to fetch the equinix-metal provider
• terraform plan and look for no changes, if the plan is clean it should be safe to apply

It may also be advisable to update to the latest version of Terraform before making any of these changes. A proper versions.tf (the contents of that file, from terraform 0.12-upgrade, required in TF 0.13) and .terraform.lock.hcl file is needed in TF 0.12+ and TF 0.14+ respectively.

[t0mk]

hmm, it will be demanding to write a proper guide to migrate from packet to metal, even though it's just a name change. I wonder if it has been done before with some other provider, and I saw that you asked in Hashcorp Slack.

The steps that you've listed seem reasonable, but there's a lot of them. Maybe it would be worth to create a golang migrator tool, like https://github.com/hashicorp/tf-sdk-migrator

[displague]

I came across this the other day, I don't know how relevant it is to our needs since the resource names are also being renamed. https://www.terraform.io/docs/commands/state/replace-provider.html.

[displague]

We will also need to address how best to migrate hardware_reservation_id fields from a computed UUID state value to the desired state value next_available value (packethost/terraform-provider-packet#304).

[displague]

I'm curious if Packet provider users might be able to keep their existing configurations by modifying the required_providers block:

https://www.terraform.io/docs/configuration/provider-requirements.html#requiring-providers

terraform {
  required_providers {
    packet = {
      source  = "equinix/metal"
      version = "~> 1.0"
    }
  }
}

---

2020-12-16 update: This wouldn't work. The provider alias syntax does not allow the resource name to use the alias name. You can not alias equinix/metal as packet and continue to use the old Packet resource names. https://www.terraform.io/docs/configuration/providers.html#alias-multiple-provider-configurations
https://www.terraform.io/docs/configuration/provider-requirements.html#local-names

[displague]

Does terraform state replace-provider packethost/packet equinix/metal help in any way?

[displague]

https://registry.terraform.io/providers/hashicorp/google/latest/docs/guides/version_3_upgrade is a nice example of how we can close this issue. Once we have created a guide in the docs, on how to migrate between the two providers, we can close this issue and address new concerns as they come in.

[niels-s]

FYI. I took the following approach to migrate our to the new Equinix Provider

1. terraform state replace-provider packethost/packet equinix/metal
2. terraform state pull > backup.state
3. cp backup.state metal.state
4. Replace device_ with metal_ in metal.state file
5. terraform state push -force metal.state
6. terraform plan
7. Fix the hardware_reservation_id breaking changes. This involved removing the hardware_reservation_id in the metal.state file to prevent recreating all the devices.
8. terraform state push -force metal.state
9. terraform plan
10. No plan changes anymore 🎉