latitudesh/terraform-provider-latitudesh v4.0.0

on GitHub

Upgrading to v4.0.0

Three attributes became required. Terraform now rejects the configuration at plan time instead of letting the API fill them in:

Error: Missing required argument

  The argument "hostname" is required, but no definition was found.

If your configuration already sets them, there is nothing to do — upgrade and carry on.

If it does not (most likely on servers you imported and let the platform name), add them using the value the server currently has, which you can read from state without touching the API:

terraform state show latitudesh_server.web | grep -E '^\s+(hostname|id)'

Nothing else in this release requires a configuration change, and the provider still supports Terraform 1.6+. Only the new action needs a newer CLI.

Highlights

Reinstall a server without changing your configuration

New latitudesh_server_reinstall action (requires Terraform 1.14+). Until now a reinstall only happened as a side effect of changing a reinstall-only attribute with allow_reinstall = true — so reinstalling a healthy server, or recovering one stuck in failed_deployment, meant fabricating drift and reverting it afterwards.

server_id is the only required argument. Everything you leave out stays out of the request, so a bare config rebuilds the machine with the operating system, hostname, keys and disk layout it already runs:

action "latitudesh_server_reinstall" "rebuild" {
  config {
    server_id = latitudesh_server.web.id
  }
}

terraform apply -invoke=action.latitudesh_server_reinstall.rebuild

It waits for the server to come back on by default, reporting status changes as progress, and works per-instance with for_each when you want to rebuild part of a fleet. Note that an action does not write Terraform state: overriding operating_system (or any other attribute) here leaves the resource drifted, so keep the two in agreement. See the action docs.

Plan hardware is now readable

latitudesh_plan exposes drives — a list of { count, size, type }, one entry per disk group. count is a number so it lines up with latitudesh_server.disk_layout.count, and the list is always present (empty, never null), so summing it is safe:

data "latitudesh_plan" "plan" { slug = "c2-small-x86" }

locals {
  total_disks = sum([for d in data.latitudesh_plan.plan.drives : d.count])
}

This is what you need to derive disk_layout from a plan's real hardware instead of hardcoding slug-to-disk maps.

latitudesh_project also gained created_at and updated_at.

Fixes

• has_gpu was true for every plan. The API returns "gpu": {} for non-GPU plans, and the old check only tested for the key's presence. Anyone branching on has_gpu was getting the wrong answer for every plan.
• Server operations could report success without checking anything. When the readiness wait ran with little time left on its context, it returned as if the operation had finished — so Terraform could call a create or reinstall successful while the server was still deploying, or had already failed. It now polls, or surfaces the cancellation.
• Read paths no longer null out required values, which would fail apply on a required attribute.

Under the hood

• latitudesh-go-sdk v1.19.3, and the Terraform plugin stack moved to framework 1.19 / plugin-go 0.31 / plugin-sdk v2 2.40.1 / tfplugindocs 0.25 — the floor for serving actions.
• go generate reproduces the documentation instead of destroying it, and CI fails when docs/ drifts from the templates or the schema. Regenerating also corrected docs that described attributes the schema does not have.
• A coverage gate reconciles what the SDK exposes against what the provider ships, so a gap is a CI signal rather than something someone happens to notice.
• The acceptance suite creates and tears down its own project, leaving nothing behind, and runs every TestAcc* by prefix.