Appearance
Software delivery #
A Build can contain application containers and an optional managed OS image, but the two parts move differently:
- container versions begin reconciling when the Build becomes effective for a device
- the OS image remains held until an operator starts its staged rollout under Engineering > Software > Delivery
This boundary prevents a Build assignment from immediately rebooting every matching device.
Verify container delivery #
The agent resolves the device's effective Build, downloads each required OCI artefact, verifies it, imports it into the host container runtime, and reconciles the application. Review per-device deployment results and verify application health, stream publication, restart behaviour, and offline recovery before expanding a cohort.
Dataplicity prepares container archives for casync delivery. A capable device can reuse chunks from previous releases and local seeds. If casync is absent, fails, produces an ineffective reconstruction, or does not verify, the device downloads the full artefact. Delta delivery is an optimisation; the final archive identity and checksum remain authoritative.
Start a managed OS rollout #
The Delivery section applies to the OS-image part of a Build. Before starting:
- qualify the Device Class for managed RAUC updates
- confirm the selected Build and target tags
- review eligible, blocked, stale, and non-reporting devices
- choose bounded concurrency and stagger
- confirm the automatic-pause threshold
The rollout snapshots its target devices and creates durable per-device attempts. Pending devices remain held until released by the schedule and concurrency controls. Pause stops new releases. Resume continues them. Cancel stops pending work while allowing a device already installing to reach a safe mark-good or rollback outcome.
Read delivery results #
Use the rollout and device results rather than treating assignment as success. Results cover queued, download, install, reboot, validation, marked-good, rollback, failure, offline, and cancellation states.
An OS device can be blocked because its inventory is absent or stale, its RAUC compatible identity differs, its persistent data mount is unsuitable, or its failed-boot rollback evidence is incomplete. Managed delivery fails closed for that device; other eligible devices can continue within the rollout policy.
The agent attempts casync reconstruction first where available, using cached bundles and readable RAUC slots as seeds. Any missing binary, transfer problem, ineffective delta, size mismatch, or digest mismatch falls back to the complete signed .raucb. The complete bundle must still pass catalogue checksum, RAUC signature, compatible identity, and version checks before installation.
Understand the rollback boundary #
RAUC installs to the inactive slot. The device bootloader must enforce a finite boot-attempt counter and automatically return to the previous good slot after a failed boot. The agent marks the new slot good only after the device returns to cloud reachability and validation succeeds.
Dataplicity can observe a rollback and report it in the rollout result. It cannot replace the board-specific bootloader fallback mechanism. Repeat the physical failed-boot test for every board, bootloader, and image-layout revision.
OS and container recovery remain independent:
- automatic OS rollback does not change the effective Software Build
- selecting a previous container composition does not switch RAUC slots
- neither operation reverses incompatible application data or irreversible hardware changes
Follow RAUC image OTA requirements for the complete image and lab qualification contract.