Update Artifact Retention: Do Not Delete the Only Recovery Image for an Active Cohort
Retire an update artifact only after a versioned dependency review shows that no supported device state, pending operation or recovery obligation still requires it. File age and low download counts are useful inventory signals, but neither proves that an offline cohort has another usable path.
This is a server-side retention planning procedure. It produces a retirement proposal and explicit blockers; it does not authorize deletion or provide storage-removal commands. RAUC 1.13 supplies two concrete dependency examples. The inventory and approval model below are original engineering recommendations, not a RAUC garbage-collection feature. No repository or device was changed.
1. Inventory consumers before listing old files
Start with supported deployed states: hardware class, active updater capability, accepted signing policy, relevant data compatibility and recovery route. Include service stock and devices that have been offline beyond the ordinary reporting interval. An absent report is an unknown state, not proof of retirement.
RFC 9019’s actor definitions distinguish status tracking from firmware delivery and consumption. Use that separation to assign ownership: fleet operations supplies the supported-state inventory, release engineering supplies artifact dependencies, and the recovery owner supplies service obligations.
Identify which evidence closes an obligation. Examples include authenticated confirmation that a unit reached a replacement capability, an approved decommission record, or a qualified alternate recovery route for the entire class. Do not infer any of these from a campaign being administratively closed.
2. Give artifacts identities and dependency edges
| Inventory field | Required meaning |
|---|---|
| Artifact identity | Exact approved bytes and digest, separate from mutable download location |
| Eligible starting states | States that can authenticate, parse and apply this artifact |
| Required dependencies | Manifests, payloads, chunks, bridge artifacts and approved retrieval services |
| Consumers | Active assignments, unresolved attempts, supported old states and recovery procedures |
| Availability evidence | Verified copy, access route and restoration evidence where archival storage is involved |
| Retirement owner | Who can resolve each dependency or approve a changed support obligation |
A filename reused for several releases is not a stable dependency key. Preserve distinct signed containers when signer or recipient variants matter. A matching payload alone does not establish that a particular deployed verifier can accept the stored package.
For shared stores, track dependencies below the bundle level. RAUC’s casync workflow uses indexes with payload data in a chunk store. Removing one old index does not prove its chunks are unused by every retained index. Conversely, retaining the index without its required chunks may preserve only the appearance of recoverability.
3. Mark everything reachable from a live obligation
Build a directed planning graph. Roots are supported device states, approved recovery obligations, pending assignments and unresolved installations. Follow each required edge to its artifacts and their transitive dependencies. Mark every reachable object as retained.
A bridge package can be a dependency even if it is rarely downloaded. RAUC 1.13 describes an intermediate update when an old updater cannot understand newer manifest options. If an offline supported class still needs that bridge, a newer final release does not make the bridge redundant.
Do not count an alternate path until its complete acceptance conditions are qualified. The replacement may require a signer the old device lacks, a data transition it cannot perform, or a service connection unavailable at that installation. Record missing evidence as a blocker rather than drawing an optimistic graph edge.
4. Review a removal set, not isolated files
Evaluate the proposed set together. Two artifacts might each appear removable because the other offers an alternate path; deleting both would remove every path. Compute retained reachability with the entire proposed set unavailable, then compare it with the obligations.
Shared chunks need references from every retained index, including recovery and service packages outside the main rollout catalog. If another team owns part of the store and cannot provide its references, classify the coverage as incomplete. A local reference count cannot establish global safety.
Keep storage savings separate from evidence quality. Report estimated reclaimable bytes only from the actual storage model, accounting for shared objects and replicas. This article provides no storage-saving benchmark.
5. Prevent the review from becoming stale
Bind the proposal to inventory, dependency and campaign revisions. Before any separately authorized retirement, require a consistent recheck or a controlled window that prevents new assignments from creating references to candidate objects.
Handle attempts already in progress explicitly. A short-lived download URL expiring does not establish that the device no longer needs a retry, and a server lease timing out does not prove installation stopped. Reconcile the operation or retain its dependencies under the documented uncertainty policy.
A proposal invalidates when a new supported starting state appears, a replacement fails qualification, or an unresolved device returns with an older capability. The default response is to reopen the affected dependency review, not silently preserve the earlier approval.
6. Distinguish archive retention from usable recovery
An offline archive can satisfy a particular obligation only if the allowed recovery delay, responsible people, access permissions and restore procedure are defined and exercised. A digest proves identity after retrieval; it does not prove that someone can retrieve the object during an incident.
Keep public certificates, signed manifests and required verification metadata with the approved artifact record. Private signing keys are not ordinary archive attachments. If a recovery path depends on future re-signing, treat that as an unqualified dependency until its authorization and operational feasibility are established.
Where policy permits, rehearse the proposed absence in an isolated catalog copy with synthetic consumers. Preserve the original store. Check old-device paths, alternate mirrors, shared chunks and service recovery without actually removing production artifacts.
Hypothetical forgotten service cohort
A retirement proposal removes bridge B and recovery image R because neither has recent downloads. Most connected controllers run release C. The inventory also contains twelve supported service units last confirmed on an older updater.
The dependency review finds that B is their only qualified route to C, while R belongs to the approved local recovery procedure. Both remain blocked. The owner can resolve the hold through verified migration, a qualified replacement path or an explicit support decision. A high fleet adoption percentage cannot substitute for that evidence.
Deliver the candidate removal set, retained dependency graph, unresolved-consumer list, alternate-path evidence and review revision. That package makes retirement reviewable without confusing storage housekeeping with proof that every supported device can still recover.
