pdurlej/platform

Fork 0

chore(uptime-kuma): prepare W8.2 low-risk app upgrade packet #506

New issue

Closed

opened 2026-05-26 17:54:22 +02:00 by codex · 0 comments

codex commented

2026-05-26 17:54:22 +02:00

Collaborator

Spec sources (whitelist)

state/cycle/W8-module-upgrade-prep.md §W8.2 low-risk apps / Required Evidence Per Upgrade PR / Stop Conditions
state/cycle/W8-readiness-2026-05-26.md §Candidate Classification
modules/uptime-kuma/module.yaml
modules/uptime-kuma/runbook.md

Extracted context

From state/cycle/W8-module-upgrade-prep.md:

W8.2 low-risk apps: Upgrade standard/maintenance user apps with local smokes.
Default candidates: `pogodowa-babcia`, `uptime-kuma`, other standard non-core modules once metadata exists.

From state/cycle/W8-readiness-2026-05-26.md:

`uptime-kuma` | `propose-pr` | stateful user-visible app | `louislam/uptime-kuma:2.1.3` |
Second candidate only after backup/rollback stance is explicit.

From modules/uptime-kuma/module.yaml:

update_policy.mode: propose-pr
artifact.image: louislam/uptime-kuma
artifact.tag: 2.1.3
statefulness: stateful
exposure: tailnet-only

From modules/uptime-kuma/runbook.md:

Stateful (private-pii). Local SQLite holds monitor configurations, heartbeat/uptime history, notification settings, and status page configurations.

Do NOT read (unless escape hatch fires)

compose/ — this PR should not change service wiring.
Live RS2000 paths — runtime smoke/apply is out of scope.
modules/forgejo/ and core services — Forgejo/core upgrades are separate W8.final work.

Allowed touched paths

state/cycle/W8-uptime-kuma-pilot.md (create)
modules/uptime-kuma/module.yaml (modify only if pinning a verified desired artifact digest or refreshing metadata)
Optional: state/cycle/W8-module-upgrade-prep.md (modify, short status note only)

Why this exists (product-first)

uptime-kuma is a better W8.2 rehearsal than Forgejo/core infrastructure, but it still has state. This issue should produce a clear packet: what tag/digest is current, whether a newer safe candidate exists, what backup/rollback evidence is required, and whether a later runtime approval is worth asking for.

Why this matters now

After minio-init, W8 needs one normal app-shaped candidate before touching stateful core services. uptime-kuma has metadata and tailnet-only exposure, but its SQLite state means the packet must be explicit before any upgrade PR.

What "done" looks like

A W8.2 uptime-kuma packet records current tag/digest and candidate tag/digest, or explicitly records that no upgrade candidate was selected.
Packet includes release-note/changelog pointer or says where none was found.
Packet includes backup-before requirement, rollback artifact, smoke command, expected result, and no-runtime-mutation statement.
If module.yaml changes, it changes only metadata/digest, not runtime wiring.
PYTHONPATH=control-plane python3 -m platformctl.cli validate all --json exits with zero failures.

Scope

In scope:

Repo-only packet for a future uptime-kuma W8.2 upgrade.
Optional desired digest metadata if verified.

Out of scope:

Running the upgrade.
Recreating/stopping/restarting uptime-kuma.
Changing Traefik exposure.
Public status page/product activation.

Suggested approach

Use registry metadata to compare current 2.1.3 with upstream stable tags.
If a candidate exists, record old/new digest and release-note evidence.
If no candidate exists or evidence is ambiguous, document that and stop at packet/no-op.
Keep all runtime action behind a later operator approval.

Escape hatch

If upstream versioning is ambiguous or release notes imply a breaking migration, stop and mark the packet manual, not ready-to-apply.

Unknowns / owner questions

None for the packet. Runtime execution is a later explicit owner gate.

Risk class

risk/runtime
risk/process
risk/exposure
risk/product

Class of service

class/security-sensitive

Trace

Original source: #389 W8 coordination lane after #501/#502
Migrated by: codex, 2026-05-26
Related issues / PRs: #389, #501, #502, #503, #504

## Spec sources (whitelist) - `state/cycle/W8-module-upgrade-prep.md` §W8.2 low-risk apps / Required Evidence Per Upgrade PR / Stop Conditions - `state/cycle/W8-readiness-2026-05-26.md` §Candidate Classification - `modules/uptime-kuma/module.yaml` - `modules/uptime-kuma/runbook.md` ## Extracted context > From `state/cycle/W8-module-upgrade-prep.md`: > ``` > W8.2 low-risk apps: Upgrade standard/maintenance user apps with local smokes. > Default candidates: `pogodowa-babcia`, `uptime-kuma`, other standard non-core modules once metadata exists. > ``` > > From `state/cycle/W8-readiness-2026-05-26.md`: > ``` > `uptime-kuma` | `propose-pr` | stateful user-visible app | `louislam/uptime-kuma:2.1.3` | > Second candidate only after backup/rollback stance is explicit. > ``` > > From `modules/uptime-kuma/module.yaml`: > ``` > update_policy.mode: propose-pr > artifact.image: louislam/uptime-kuma > artifact.tag: 2.1.3 > statefulness: stateful > exposure: tailnet-only > ``` > > From `modules/uptime-kuma/runbook.md`: > ``` > Stateful (private-pii). Local SQLite holds monitor configurations, heartbeat/uptime history, notification settings, and status page configurations. > ``` ## Do NOT read (unless escape hatch fires) - `compose/` — this PR should not change service wiring. - Live RS2000 paths — runtime smoke/apply is out of scope. - `modules/forgejo/` and core services — Forgejo/core upgrades are separate W8.final work. ## Allowed touched paths - `state/cycle/W8-uptime-kuma-pilot.md` (create) - `modules/uptime-kuma/module.yaml` (modify only if pinning a verified desired artifact digest or refreshing metadata) - Optional: `state/cycle/W8-module-upgrade-prep.md` (modify, short status note only) ## Why this exists (product-first) `uptime-kuma` is a better W8.2 rehearsal than Forgejo/core infrastructure, but it still has state. This issue should produce a clear packet: what tag/digest is current, whether a newer safe candidate exists, what backup/rollback evidence is required, and whether a later runtime approval is worth asking for. ## Why this matters now After `minio-init`, W8 needs one normal app-shaped candidate before touching stateful core services. `uptime-kuma` has metadata and tailnet-only exposure, but its SQLite state means the packet must be explicit before any upgrade PR. ## What "done" looks like - [ ] A W8.2 `uptime-kuma` packet records current tag/digest and candidate tag/digest, or explicitly records that no upgrade candidate was selected. - [ ] Packet includes release-note/changelog pointer or says where none was found. - [ ] Packet includes backup-before requirement, rollback artifact, smoke command, expected result, and no-runtime-mutation statement. - [ ] If `module.yaml` changes, it changes only metadata/digest, not runtime wiring. - [ ] `PYTHONPATH=control-plane python3 -m platformctl.cli validate all --json` exits with zero failures. ## Scope **In scope:** - Repo-only packet for a future `uptime-kuma` W8.2 upgrade. - Optional desired digest metadata if verified. **Out of scope:** - Running the upgrade. - Recreating/stopping/restarting `uptime-kuma`. - Changing Traefik exposure. - Public status page/product activation. ## Suggested approach 1. Use registry metadata to compare current `2.1.3` with upstream stable tags. 2. If a candidate exists, record old/new digest and release-note evidence. 3. If no candidate exists or evidence is ambiguous, document that and stop at packet/no-op. 4. Keep all runtime action behind a later operator approval. ## Escape hatch If upstream versioning is ambiguous or release notes imply a breaking migration, stop and mark the packet `manual`, not `ready-to-apply`. ## Unknowns / owner questions - None for the packet. Runtime execution is a later explicit owner gate. ## Risk class - [x] `risk/runtime` - [x] `risk/process` - [ ] `risk/exposure` - [ ] `risk/product` ## Class of service - [ ] `class/security-sensitive` ## Trace - Original source: #389 W8 coordination lane after #501/#502 - Migrated by: codex, 2026-05-26 - Related issues / PRs: #389, #501, #502, #503, #504

codex added this to the 09 - Module upgrade waves milestone

2026-05-26 17:54:22 +02:00

codex added the

labels

2026-05-26 17:54:22 +02:00

codex referenced this issue

2026-05-26 17:55:28 +02:00

meta(upgrades): plan staged module upgrade waves after metadata and DR #389