HiveCast Platform

Appearance

Rollback ​

Status: target state. No automated rollback exists. The present-state answer is "downgrade the wrapper version manually."

Today: manual downgrade ​

bash
hivecast stop
sudo apt install hivecast=0.1.24    # the prior version
hivecast start

Per Device. The operator must know which prior version is good. There is no "previous-revision" concept on the Host because there are no profile revisions today.

Target: revision-based rollback ​

A rollout (see Rollouts) operates on profile revisions. Rollback is "apply revision N-1." The orchestrator computes the diff and reverses the rollout. Devices that didn't get the new revision are no-ops.

Rollback should be fast — under a minute for a small fleet — because it must be safe to invoke under incident pressure.

Rollback inputs ​

A rollback decision needs:

  • Which revision was applied.
  • Which Devices got the new revision.
  • Which Devices had errors after the rollout.
  • The previous revision's profile content.

The first two are inputs to the orchestrator's audit log. The third comes from system.devices and runtime health probes. The fourth lives in the profile store.

None of those stores exist today.

Manual rollback procedure ​

Until automation exists, the operator's procedure under incident:

  1. Identify which Devices were upgraded. Today this is your inventory tool, not the platform.
  2. Identify the prior good wrapper version. From your release log.
  3. Downgrade each Device. apt install hivecast=<prev>; hivecast restart.
  4. Verify each Device returned to healthy. system.devices devices.list, host.control status, app cards on the dashboard.
  5. Audit-log the incident in your own ops channel. The platform will not record it.

For a small fleet under one operator, this works. For larger fleets it is slow and error-prone.

Data-only rollbacks ​

A subtler case: a rollout that did not change package versions but modified runtime configuration (a profile-only change). Rollback here does not need to revert binaries — only revert the runtime record edits.

Today this means hand-editing <host-home>/runtimes/*.json per Device. Target state is a profile revision rollback that touches only the changed records.

Rollback hazards ​

  • Newer-data, older-code. If the new version migrated a data store, rolling back the code with the migrated data may panic. The platform does not migrate data today (state files are append-only, schema-additive), so this is not an immediate hazard. As the system grows, schema migrations will need backward-compat planning.
  • Credential rotation interaction. If a rollout coincided with a credential refresh, rollback to a wrapper that doesn't recognize the new credential format is bad. Today the credential format is stable; future-proof by versioning credential payloads.
  • Half-rolled-out rollback. If only some Devices got the new version and some are still on the old, "rollback" is "leave the old ones alone, downgrade the new ones." The orchestrator must do this correctly per Device.

Loose ends ​

Rollback shares the workstream owner with rollout: WORKSTREAMS/docker-npm-parity/. No code today.

See also ​

Source: WORKSTREAMS/docker-npm-parity/. No code today.