Appearance
Modern agent lifecycle #
Choose who owns the agent version before you ship the image. Mixing package self-updates with image-owned binaries creates a fleet where the running version depends on which rootfs slot happened to boot.
Two supported ownership models #
| Product model | Agent ownership |
|---|---|
| Conventional Linux host | Upgrade the modern agent through the qualified package/install path |
| Signed A/B image | Bake the complete Dataplicity runtime into every tested rootfs slot; the image release owns the version |
On RAUC-managed products, package installation is a bootstrap or recovery tool - not the normal steady-state upgrade path.
Dataplicity OS follows the signed A/B model. Its current images pin modern agent 0.1.60 as an on-image wheelhouse with rescue and supervisor in each root filesystem slot. Upgrade that runtime by releasing the next tested OS slot, not by replacing it independently on one booted slot.
Before an upgrade #
Record the current rescue and supervisor versions, OS image, architecture, install mode and agent ownership model. Test on the exact production image and prove:
- identity is preserved;
- the rescue path reconnects;
- the supervisor and broker recover;
- desired settings and Class Software remain correct;
- cache and logs remain bounded;
- rollback returns the whole tested runtime to a coherent version.
Roll out in a canary cohort before expanding.
The current Dataplicity OS RAUC bundle updates rootfs only. It does not update the boot, kernel, or firmware partitions. A product that needs those updates must define and qualify an expanded bundle and rollback design.
Recovery #
Separate credential recovery from service recovery. A restart cannot repair invalid credentials. Re-provisioning can create a fresh identity and leave the old device record orphaned, so use the release-specific recovery procedure.
If rescue is healthy but the supervisor is not, preserve the rescue path while investigating the optional plane. If the product is RAUC-managed, verify which slot is booted before installing packages by hand.
Removal and decommissioning #
Before removal:
- preserve any audit or support evidence your policy requires;
- ensure another local management path exists if the product must remain serviceable;
- stop fleet automation that assumes the device is online;
- use the removal procedure for the installed release and mode;
- erase device credentials and persistent state according to your decommissioning policy;
- verify Dataplicity no longer presents the unit as available.
Do not blindly remove the third-party Supervisor package or its configuration on a classic host; it may manage unrelated customer processes. Do not blindly delete /var/lib/dataplicity on an A/B image before confirming what product state shares that mount.
When the installed generation or ownership model is uncertain, identify it first using Choose the right agent path.