Define installation, upgrade, and removal behavior #9

New Issue

2026-08-31T08:03:03Z

xavierk commented

2026-08-31 08:03:03 +00:00

Parent map: Chart Fenris’s persistent TUI monitoring redesign

Question

What installation, upgrade, and removal journey should make the chosen TUI runtime, collector service, configuration, and observation database reliable when the source checkout moves or disappears? Decide installed locations, dependency packaging, service-unit installation, startup opt-in, privilege prompts, upgrade compatibility, data preservation, rollback expectations, and complete versus data-preserving removal.

Parent map: [Chart Fenris’s persistent TUI monitoring redesign](https://git.bongbetic.com/xavierk/Fenris/issues/1) ## Question What installation, upgrade, and removal journey should make the chosen TUI runtime, collector service, configuration, and observation database reliable when the source checkout moves or disappears? Decide installed locations, dependency packaging, service-unit installation, startup opt-in, privilege prompts, upgrade compatibility, data preservation, rollback expectations, and complete versus data-preserving removal.

xavierk added this to the Wayfinder: Fenris persistent TUI monitoring redesign milestone 2026-08-31 08:03:03 +00:00

xavierk added the wayfinder:grilling label 2026-08-31 08:03:04 +00:00

xavierk added a new dependency 2026-08-31 08:03:19 +00:00

#8 Define the collector, service, and CLI lifecycle

xavierk added a new dependency 2026-08-31 08:03:19 +00:00

#6 Evaluate Python TUI frameworks for Fenris

xavierk added a new dependency 2026-08-31 11:45:44 +00:00

#13 Define cross-cutting acceptance criteria

xavierk self-assigned this 2026-08-31 12:25:11 +00:00

xavierk commented

2026-08-31 13:28:36 +00:00

Resolution

Decided across two grilling rounds (Q1–Q12, all recommendations accepted) and recorded in ADR 0004 (commit ffa6f22).

Delivery & layout: make install builds the wheel and installs it with pinned deps into a dedicated venv at /opt/fenris; /usr/local/bin/fenris wrapper on PATH; units in /etc/systemd/system, helpers in /usr/libexec/fenris, polkit policy in the standard actions dir; the installer records an explicit file manifest that drives upgrade and uninstall. Checkout is build-time input only.
Privilege: one-shot root installer; runtime elevation exclusively polkit (auth_admin, fenris-monitor only); the installer never enables or starts units.
Dormant install: units present but disabled, nothing running, no monitoring period; the sole opt-in is the sanctioned toggle (fenris monitor resume [--now] or first-run TUI prompt), which enables the timer and opens the first period in one step.
Legacy import: installer detects ./data/history.jsonl (or takes an explicit path) and runs ADR 0001's idempotent single-transaction import, reporting counts; fenris import <path> retained.
Upgrade: same venv, unit/polkit sync against the manifest + daemon-reload (restart timer only if contents changed and it is active), timer state untouched, never kills an in-flight collection run; forward-only schema_version migrations after; /var/lib/fenris never rebuilt.
Rollback: best-effort, one generation — observations.db.bak snapshot before migrations; rollback = reinstall previous version + restore; automatic downgrade unsupported.
Removal: make uninstall performs the sanctioned disable first (open period closes user_disabled; only the sanctioned path records intent), then removes venv/helpers/units/policy/wrapper while keeping config and observation store; make purge adds config and store.
Dependencies: exact pins in a committed lockfile consumed by install and upgrade; make update-deps is the only refresh path.
Scaffolding & floor: installer creates /var/lib/fenris with ADR 0001 permissions and gates on python3 ≥ 3.9; the database file is created lazily by the first write so "no observations yet" stays a real state.

Newly surfaced tickets: none. No fog graduation: specification assembly stays in Not yet specified until the remaining decisions close. No existing ticket invalidated.

## Resolution Decided across two grilling rounds (Q1–Q12, all recommendations accepted) and recorded in [ADR 0004](https://git.bongbetic.com/xavierk/Fenris/src/branch/main/docs/adr/0004-install-upgrade-removal-lifecycle.md) (commit `ffa6f22`). - **Delivery & layout**: `make install` builds the wheel and installs it with pinned deps into a dedicated venv at `/opt/fenris`; `/usr/local/bin/fenris` wrapper on PATH; units in `/etc/systemd/system`, helpers in `/usr/libexec/fenris`, polkit policy in the standard actions dir; the installer records an explicit file manifest that drives upgrade and uninstall. Checkout is build-time input only. - **Privilege**: one-shot root installer; runtime elevation exclusively polkit (`auth_admin`, `fenris-monitor` only); the installer never enables or starts units. - **Dormant install**: units present but disabled, nothing running, no monitoring period; the sole opt-in is the sanctioned toggle (`fenris monitor resume [--now]` or first-run TUI prompt), which enables the timer and opens the first period in one step. - **Legacy import**: installer detects `./data/history.jsonl` (or takes an explicit path) and runs ADR 0001's idempotent single-transaction import, reporting counts; `fenris import <path>` retained. - **Upgrade**: same venv, unit/polkit sync against the manifest + `daemon-reload` (restart timer only if contents changed and it is active), timer state untouched, never kills an in-flight collection run; forward-only `schema_version` migrations after; `/var/lib/fenris` never rebuilt. - **Rollback**: best-effort, one generation — `observations.db.bak` snapshot before migrations; rollback = reinstall previous version + restore; automatic downgrade unsupported. - **Removal**: `make uninstall` performs the sanctioned disable first (open period closes `user_disabled`; only the sanctioned path records intent), then removes venv/helpers/units/policy/wrapper while keeping config and observation store; `make purge` adds config and store. - **Dependencies**: exact pins in a committed lockfile consumed by install and upgrade; `make update-deps` is the only refresh path. - **Scaffolding & floor**: installer creates `/var/lib/fenris` with ADR 0001 permissions and gates on `python3 ≥ 3.9`; the database file is created lazily by the first write so "no observations yet" stays a real state. Newly surfaced tickets: none. No fog graduation: specification assembly stays in Not yet specified until the remaining decisions close. No existing ticket invalidated.

xavierk closed this issue

2026-08-31 13:28:36 +00:00

~~xavierk referenced this issue 2026-08-31 13:28:38 +00:00~~

Chart Fenris’s persistent TUI monitoring redesign #1

xavierk referenced this issue

2026-08-31 14:46:58 +00:00

Chart Fenris’s persistent TUI monitoring redesign #1

Sign in to join this conversation.