Roll out metald and WG Mesh
Use a Metald Update to install a new metald and Atlas WG Mesh build on the Metal Servers. The two binaries always roll out together. VMs, consoles, and mesh traffic keep running during the upgrade.
Before you start
- Deploy the Atlas release that contains the build. Atlas builds metald and Atlas WG Mesh during migration and shows their versions in Atlas Settings.
- Check that no other Metald Update is Running or Paused. Only one update can run at a time.
1. Create the update
Open Metal Server. Select the servers to upgrade (1), open Actions (2), and click Create Metald Update (3).
To upgrade every running server, create a Metald Update from its list instead and leave the server table empty.
2. Set the batches
The new update is a Draft. It pins the metald and WG Mesh versions from Atlas Settings, so a later build does not change it.
Set the rollout fields (1). Check the servers (2), then click Plan Rollout (3).
| Field | Use |
|---|---|
| Canary Size | Servers in the first batch. Keep it at 1 for a new build. |
| Batch Size | Servers in each later batch. |
| Wait Minutes | Time to watch a batch before Atlas checks it. Use 10 minutes or more in production. |
3. Review the plan
Atlas reads the versions that run on each server (1). A server that already runs the build becomes Skipped. A server that Atlas cannot read becomes Failed.
Click Start Rollout (2). To change the servers or the fields, click Edit Plan (3).
If all servers already run the build, the update becomes Completed without a rollout.
4. Watch the canary
The canary server gets batch 1 and the other servers get later batches (1). Atlas starts one upgrade SSH Task for each server and links it in the row (2). Pause Rollout and Cancel Rollout (3) stay available.
Open the SSH Task to follow the upgrade (1). A successful task (2) shows the new versions and the number of VMs that still run.
5. Let Atlas check each batch
After a batch upgrades, Atlas waits until Wait Until (1). The row stays Upgraded (2) during the wait. Use this time to watch the servers and their VMs.
After the wait, Atlas checks every upgraded server. A server must report the pinned versions and must have synchronized in the last 2 minutes. A server that passes becomes Verified (1) with its new versions (2), and the next batch starts.
6. Pause, resume, or cancel
Click Pause Rollout to stop new upgrades. The update becomes Paused (1). An SSH Task that already runs finishes.
Click Resume Rollout (2) to continue. Resume also retries the Failed servers. Click Cancel Rollout (3) to stop the rollout for good.
7. Finish
The update becomes Completed (1) when every batch is Verified (2).
When a server fails
A failed upgrade or check pauses the update, and the server row becomes Failed.
- Read the row's Status Reason. For a failed upgrade, read the end of its SSH Task output.
- Fix the cause, then click Resume Rollout, or click Cancel Rollout.
The upgrade script restores the previous binaries when the new build does not start, so a failed server keeps running its old build. A build with a new metald patch is an exception: the server keeps the new build, and you roll forward with a fixed build. A Metald Update pauses lists the host checks.
To go back to an earlier build, duplicate its Metald Update, then plan and start the duplicate. This does not work for a build with a new metald patch or WG Mesh map layout. Roll forward with a fixed build instead.