Software Updates
Updates are applied from System → Updates. The page lists available versions, marks the installed one with a current chip, and shows release notes for the selected version.
Only the super_admin role can start an update or upload an update bundle. The update controls
are hidden for every other role, and direct attempts are rejected.
Check for Updates
Click Check for Updates. The page shows when it last checked. Versions that are incomplete or not installable are not listed.
For an appliance with no route to the update registry, upload an offline update bundle instead — the available versions then come from the bundle's manifest.
Review the Impact, Then Update
There is no update-method choice. A single Update button opens a fact-based summary of what this update will actually do to your cluster:
| Row | Possible values |
|---|---|
| Storage access | Uninterrupted — nodes update one at a time while the others keep serving, or the storage engine is unchanged so it is never restarted; Brief pause — the storage engine restarts in place; Unavailable — the update requires a complete cluster stop |
| Management console | Brief reconnect — the dashboard and API reconnect for a moment while the manager restarts. Storage access is unaffected. |
| Rollback | Reversible, or Not reversible — recovery would require restoring from backup |
Confirmation is requested only when it is genuinely needed. Depending on the impact you may have to acknowledge that storage access will be briefly unavailable, that data protection measures are in place, and/or that the update cannot be rolled back once it completes.
An update that advances the on-disk volume group format is a hard rollback boundary. It is held until you explicitly acknowledge that an in-place rollback will no longer be possible, and rollbacks are blocked once the boundary is crossed.
Since 0.0.14.3 the storage engine is upgraded along with everything else. When a release does not change the engine, the engine is left running untouched and only the changed components are replaced.
Capacity and Interruption-Free Updates
An interruption-free (node-by-node) update needs enough free capacity to relocate data while one node is down. The page shows a Storage capacity gauge and a utilization trend so you can add drives or nodes before you cross that ceiling. If capacity is short, the impact summary says so and names what to free up.
Watch Progress
An Upgrade in progress banner shows the node-by-node progress with a View Status link. Updates pace themselves: each node's storage fully rejoins the cluster before the next node is restarted.
Routine alert noise is suppressed while a planned update is in progress.
If an Update Is Blocked
A blocked update is shown as Blocked — not Aborted — and keeps the progress card visible so the recovery action is discoverable.
| Control | When to use |
|---|---|
| Retry | Recovers handshake-driven blocks (drain, reintegrate, volume group upgrade). If Retry is unavailable it is shown disabled with a tooltip and an inline hint. |
| Abort | Use when Retry is unavailable. Storage I/O resumes after the abort; restart the update once the cluster is healthy. |
Control-plane phases that make no progress time out and flip to Blocked with a reason rather than retrying forever.
Operations that cannot run during an active update are shown disabled with an explanatory tooltip.
Downgrades
Installing an older version is still possible but is flagged before the action: a "Downgrade is not supported" alert, an amber install button, and an extra confirmation dialog. Data formats only migrate forward, so a downgrade can leave the cluster inconsistent.
Hardware-Specific Images
On hardware that requires a specific image variant (for example nodes with Broadcom Thor2 network cards), the update dialog states which image is in use and asks you to confirm it. The variant is detected and remembered, so it is carried across updates without any extra flag.