From 23631f023902cca20a0800a1711068fa16915733 Mon Sep 17 00:00:00 2001 From: tegwick Date: Thu, 20 Aug 2026 08:54:21 +0200 Subject: [PATCH] Correct T07: reuse-surface is live and stale; state-hub was mostly a false alarm MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Checking each image reference's liveness separated the two cases the first pass treated alike. reuse-surface is a live Deployment on gitea, pinned to a 2026-07-07 commit and 22 commits behind main. Its CI moved to forgejo at 21:25 that same day, three hours after the pinned commit, and has published :latest and :main- there ever since. Producer migrated, consumer did not. state-hub's Deployment is already on forgejo with the current tag scheme. Its only gitea reference is a completed one-shot alembic-init Job that does not re-run on its own, so "unable to run its schema migration" was wrong. Residual risk is a chart template recreating it. No repository rename occurred — this is a registry migration in which one consumer was left behind. An image reference is not a dependency until something can act on it. Co-Authored-By: Claude Opus 5 --- DECISIONS.md | 27 ++++++++++++++++--- WORK-RECORDS.md | 1 + ...0002-predecessor-and-deployment-reality.md | 20 ++++++++++++-- 3 files changed, 43 insertions(+), 5 deletions(-) diff --git a/DECISIONS.md b/DECISIONS.md index 44cdf03..5151b3b 100644 --- a/DECISIONS.md +++ b/DECISIONS.md @@ -90,9 +90,30 @@ This fails in the most inconvenient way available. Running pods survive decommission because their images are already pulled locally — **so nothing breaks on the day**. The failure arrives at the next restart, reschedule, node reboot or scale-up, as `ImagePullBackOff`, at a moment chosen by circumstance -rather than by us. And one of the two is **State Hub's own migration job** — the -service this entire project exists to retire in an orderly way, unable to run its -schema migration. +rather than by us. + +**Corrected 2026-08-20, same day.** The first version of this entry treated both +references as equally live and said State Hub would be "unable to run its schema +migration". That overstated it, and the two cases are not alike: + +- **`reuse-surface` is the real one.** A *live Deployment* pulling + `gitea.coulomb.social/coulomb/reuse-surface:e3ae22e` — a commit from + **2026-07-07 18:25**, now **22 commits** behind main (2026-07-30). Its CI + moved to `REGISTRY: forgejo.coulomb.social` at **21:25 the same day**, three + hours later, and has been publishing `:latest` and `:main-` there ever + since. The producer migrated; the consumer never did. +- **`state-hub` is largely a false alarm.** Its *Deployment* already runs + `forgejo.coulomb.social/coulomb/state-hub:main-d8808bf` — correctly migrated, + current tag scheme. The only gitea reference is a **completed one-shot Job** + (`state-hub-alembic-init`, 1 succeeded, completions 1, created 2026-07-06) + that does not re-run on its own. It matters only if something recreates it + from a chart template still carrying the old image, which is worth fixing but + is not an outage waiting to happen. + +The correction is recorded rather than edited away because the *method* produced +it: enumerating workload image references found both, and only checking each +one's liveness separated a live staleness from a historical artifact. **An image +reference is not a dependency until something can act on it.** `forgejo.coulomb.social` already runs on railiance01, so the destination exists and the work is retag, push, update manifest. Routed to `railiance-platform`. diff --git a/WORK-RECORDS.md b/WORK-RECORDS.md index b5e60ce..169089f 100644 --- a/WORK-RECORDS.md +++ b/WORK-RECORDS.md @@ -22,3 +22,4 @@ | task | SHR-WP-0002-T04 | todo | — | workplans/SHR-WP-0002-predecessor-and-deployment-reality.md | | task | SHR-WP-0002-T05 | todo | — | workplans/SHR-WP-0002-predecessor-and-deployment-reality.md | | task | SHR-WP-0002-T06 | todo | — | workplans/SHR-WP-0002-predecessor-and-deployment-reality.md | +| task | SHR-WP-0002-T07 | todo | — | workplans/SHR-WP-0002-predecessor-and-deployment-reality.md | diff --git a/workplans/SHR-WP-0002-predecessor-and-deployment-reality.md b/workplans/SHR-WP-0002-predecessor-and-deployment-reality.md index df8125d..86bf176 100644 --- a/workplans/SHR-WP-0002-predecessor-and-deployment-reality.md +++ b/workplans/SHR-WP-0002-predecessor-and-deployment-reality.md @@ -238,6 +238,7 @@ decision route rather than adding it unilaterally. id: SHR-WP-0002-T07 status: todo priority: high +state_hub_task_id: "07636ddf-a26b-4760-8353-2532af9fd938" ``` **The registry dependency, found 2026-08-20 and not previously tracked.** @@ -249,8 +250,23 @@ is the complete set). Nothing breaks on decommission day, because running pods already hold their images. It breaks at the next restart, reschedule or scale-up, as -`ImagePullBackOff`. One of the two is **State Hub's own migration job** — this -project's subject, unable to run its schema migration. +`ImagePullBackOff`. + +**The two are not equally urgent** (corrected 2026-08-20 after checking each +reference's liveness): + +- **`reuse-surface` — live and stale.** A running Deployment on the old + registry, pinned to a 2026-07-07 commit and **22 commits behind** main. Its CI + switched to forgejo three hours after that commit and has published there ever + since; the deployment was never repointed. **This is the one that must move + before 2026-08-31.** +- **`state-hub` — mostly a false alarm.** The Deployment is already on + `forgejo.coulomb.social/coulomb/state-hub:main-d8808bf`. The gitea reference is + a *completed* one-shot Job that will not re-run by itself; the residual risk is + a chart template recreating it. Worth cleaning, not urgent. + +There was **no repository rename**. This is a registry migration (gitea → +forgejo, early July) in which producers moved and one consumer did not. `forgejo.coulomb.social` is already on railiance01, so the work is retag, push, update manifest. Routed to `railiance-platform`; ownership of the `reuse-surface`