Motivation
After `rollback` completes, the user has restored the system to a previous snapshot but has limited visibility into what specifically reverted. Knowing which packages changed versions, which kernel was selected, and which config files differ from the pre-rollback state is essential for both operator confidence and post-incident documentation. Today the user has to derive this manually by inspecting the previous root subvolume that rollback preserves.
Scope
After a successful rollback, the tool prints a report summarizing what the rolled-back state contains compared to the state that was just replaced. Categories:
- Packages: RPM versions that differ between the previous root (preserved at the snapshot name) and the new root. Format similar to `dnf history` output. Likely the most actionable signal.
- Kernel: which kernel will boot after reboot vs which was running.
- Config files (best-effort): list of `/etc` files that differ. Diff content is too noisy for default output; just enumerate paths.
Properties
- Computed from comparing the two root subvolumes (the rolled-back-to one, now active, and the preserved old one)
- Read-only: report only, no further modification
- Reasonable failure mode: if comparison fails (e.g., RPM database unreadable), report what we could compute and note what we couldn't
- Output should be sufficient for an operator to log to a change ticket without further investigation
Open questions for design
- Where to source package data: `rpm --root` against the old subvolume's `/var/lib/rpm`? But `/var` is a separate subvolume not affected by rollback, so the RPM database actually reflects post-rollback state. Need to think about this carefully — the actual package state at rollback time vs the snapshot's view of packages is non-obvious because RPM data lives in `/var`.
- Should the report be inline with rollback output, or a separate command (`atomic-rollback report-rollback`) the user runs after?
Acceptance criteria
Milestone
0.5.0
Motivation
After `rollback` completes, the user has restored the system to a previous snapshot but has limited visibility into what specifically reverted. Knowing which packages changed versions, which kernel was selected, and which config files differ from the pre-rollback state is essential for both operator confidence and post-incident documentation. Today the user has to derive this manually by inspecting the previous root subvolume that rollback preserves.
Scope
After a successful rollback, the tool prints a report summarizing what the rolled-back state contains compared to the state that was just replaced. Categories:
Properties
Open questions for design
Acceptance criteria
Milestone
0.5.0