57 lines
3.4 KiB
Markdown
57 lines
3.4 KiB
Markdown
# ADR-020: Define Rollback Eligibility and Retention
|
|
|
|
## Context
|
|
|
|
An A/B device retains A while trying B. Keeping A's bytes does not guarantee that A can still run: shared data, configuration, boot components, or security policy may have changed. Confirmation and later slot reuse also affect what the product can promise.
|
|
|
|
The reference design needs local recovery without downloading the old release. Boot control and Linux must understand the retained recovery state.
|
|
|
|
## Decision
|
|
|
|
Define an explicit rollback window and the conditions that make its target eligible. Retain the target release, matching boot artifacts, required dependencies, verification information, and a supported data path for that window. Record release identities and the window state outside replaceable software.
|
|
|
|
Admit a trial only when its permitted operations preserve the early-boot recovery path. The eligibility contract covers artifact validity, shared components, configuration, data, recovery-state formats, and the platform's security policy. Reassess these conditions before a supervisor initiates recovery where possible. Early boot recovery must rely on a contract established before trial, not on checks that require the failed Linux system.
|
|
|
|
Confirmation alone neither guarantees nor closes a post-confirmation rollback window. The product must state whether such a window exists. Save its closure before an incompatible change or slot reuse removes the promised recovery path. An interrupted closure may conservatively leave rollback unavailable; it must not leave a promise to use a removed target.
|
|
|
|
If eligibility cannot be established, stop ordinary rollback and use the separate recovery policy. Check essential functions after starting the retained release before reporting success.
|
|
|
|
## Alternatives Considered
|
|
|
|
### Treat Any Retained Slot as Recoverable
|
|
|
|
Simple, but ignores shared data and changes outside the slot. The slot may boot while the application remains unusable.
|
|
|
|
### Keep Every Previous Release Indefinitely
|
|
|
|
This needs more storage and still does not preserve compatibility or permission to run old software.
|
|
|
|
### Download Recovery Software When Needed
|
|
|
|
This can supplement local recovery, but cannot satisfy this design's offline requirement.
|
|
|
|
## Consequences
|
|
|
|
### Positive
|
|
|
|
- The recovery promise has an explicit lifetime and prerequisites.
|
|
- Cleanup and migrations cannot silently invalidate a retained target.
|
|
- Confirmation, data compatibility, and slot retention can be reviewed separately.
|
|
|
|
### Negative
|
|
|
|
- Retained artifacts and compatible data consume resources.
|
|
- Releases must maintain compatible recovery-state formats during the window.
|
|
- Closing the window may require an alternative recovery path.
|
|
|
|
## Applicability and Limits
|
|
|
|
Use when a product promises a return to retained software. This decision defines policy, not an artifact verifier or a durable journal implementation. Hardware failure and damaged shared boot components need separate recovery support. Security policy can prohibit an otherwise operational old release.
|
|
|
|
## Related Documents
|
|
|
|
- [Chapter 07: Rollback and Recovery](../docs/07-rollback-and-recovery.md)
|
|
- [ADR-014: Trial Boot and Confirmation](ADR-014-trial-boot-and-confirmation.md)
|
|
- [ADR-017: Keep Recovery State Outside Replaceable Software](ADR-017-keep-recovery-state-outside-replaceable-software.md)
|
|
- [ADR-021: Preserve Data Compatibility During Trial](ADR-021-preserve-data-compatibility-during-trial.md)
|