Skip to content

Rebuild the cluster from files

Install once in the console or the TUI, keep the files, and rebuild unattended later. A rebuild gives a new cluster: a new cluster id, new secrets and new node ids (a first node keeps its id if you pin it, below). It restores the cluster’s shape, not its data: no instances, volumes, images, users or keys come back. Decide that before you wipe anything.

Do this once per node, after the install works. Keep the files off the cluster they describe: they hold secrets, so treat them like passwords.

File What it is How to keep it
install.yaml Stage 1: disks, NIC, host name, root, kind stratum-installer stage1 export on the node
node.yaml (first node) Stage 2: networks, service addresses, region, admin, storage stratum-installer config get --yaml, or stratumctl admin nodes config
Assignment (each joiner) The role, rack, links and disks the first node gave it stratumctl admin nodes joins export

A joiner’s node.yaml is built from its assignment at approval: there is nothing else to keep for it.

Each node keeps a record of its install at /etc/stratum/installer/install.yaml. It has the root password hash and the join code replaced by <redacted>. The export turns it back into a file the installer loads:

Terminal window
# on the node
stratum-installer stage1 export --out install.yaml
stratum-installer stage1 export --root-hash-file root.hash --out install.yaml
  • Root. --root-hash-file names a file holding the crypt hash (for example from mkpasswd -m yescrypt). Without it the hash is left out and root signs in with the SSH keys the record keeps. The export fails if the record keeps none.
  • Wipe. The file has wipe_other_disks: true and wipe_confirm for the OS disks, which hold the previous install and would otherwise be refused as “holds data”. Running it erases those disks. The record’s own wipe_extra and wipe_confirm are replaced by this.
  • Resolved values. Disks are the literal /dev/disk/by-id paths. A host-name template, nic.match and disk_select appear as the install resolved them, so the file names this machine, not a fleet.
  • A joiner needs --join-endpoint and --join-code. The stored code is redacted, and a code needs a live cluster, so a code cannot be kept in a file. Export with any well-formed code (XXXX-XXXX-XXX) and put the new cluster’s in at rebuild time.
  • For a node whose release has no stage1 export, copy its record off and run the export anywhere with --from-record.
  • The output is checked by the validation the installer runs at boot. --out writes the file readable by its owner only.
  • During the install, or within 5 minutes after it, on the node: stratum-installer config get --yaml prints the exact node.yaml the install wrote, secrets included. It needs the install code and the installer’s address, like every stratum-installer command (Stage 2). After those 5 minutes the install service stops.
  • Any time later: stratumctl admin nodes config <node-id> --out node.yaml. Every secret in it reads <redacted>: the admin password, registry pull credentials, the operator webhook, the release-mirror token, a join token. The loader refuses a secret that still reads <redacted> and names the key, so an unfilled file is never applied by accident. Replace each with a real value, or delete the key. The download carries the node’s identity.node_id.
Terminal window
stratumctl admin nodes joins list # the join id of each node
stratumctl admin nodes joins export nj-8w2k4m1p > node-2.yaml

It prints the assignment as YAML (--output json for JSON), without the keys the cluster adds to the record, so joins approve -f node-2.yaml loads it. A join that has no assignment yet (pending or rejected) has nothing to export. Links keep their addresses, which must be free in the new cluster’s networks. They are the same networks if the first node’s node.yaml is. See joins export.

  • The first node’s install.yaml (kind: new-cluster) and its node.yaml (mode ha-init) with the secrets filled in, placed for the unattended install. The node.yaml mode must match the install.yaml kind.
  • Every joiner’s install.yaml and exported assignment.
  • The ISO of the release you rebuild on, and the same hardware: disk ids and NIC names are literal.
  • A written decision on the data: it is gone.
  1. Wipe all nodes by installing each from its install.yaml: the OS disks and every other disk that holds data are erased. Do the first node first, with its node.yaml beside the file; its stage 2 runs by itself.

  2. Wait for the first node to be READY (stratumctl admin readiness), then create a join code:

    Terminal window
    stratumctl admin nodes join-code create --ttl 24h

    A code is reusable until it expires, up to 7 days, so one serves every joiner.

  3. Install each joiner. In its install.yaml, set join.code (and join.endpoint if the API address changed) to the new values, then install.

  4. Approve each joiner with its own assignment, by the serial it registered with:

    Terminal window
    stratumctl admin nodes joins approve --serial SN0002 -f node-2.yaml

    Joins run one at a time, while the cluster is green (approve).

  5. Revoke the code (stratumctl admin nodes join-code revoke <id>) and run the verify checklist. Then set up Ceph again and restore data on the new cluster.

What differs from the old cluster: the cluster id, every secret (OpenBao, Postgres, the admin password if you did not set it), certificates, and each joiner’s node id. A first node whose identity.node_id is kept in node.yaml keeps its id; an id is n- followed by 8 lowercase letters or digits. Anything that pinned the old cluster id or a node id (a Terraform state, saved API tokens, stratumctl profiles) needs updating.