coulomb/prj-state-hub-retirement
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Pin the CoulombCore decommission at 2026-08-31; find the registry dependency

Browse source 
Operator set the date: CoulombCore retires by end of August. Eleven days, which
decides T03 — absorbing Core Hub directly into hub-core depends on HUB-WP-0004,
which still has not decided whether hub-core becomes a runtime at all. The
project recommends the interim move (the pattern issue-core used a week ago);
the choice stays core-hub's.

Resolving the public service names against the two hosts surfaced something no
plan contained: gitea.coulomb.social is a live container registry on CoulombCore,
and two railiance01 workloads pull images from it — reuse-surface, and State
Hub's own alembic-init migration job. Nothing breaks on the day, because running
pods already hold their images; it breaks at the next restart or reschedule as
ImagePullBackOff, at a time chosen by circumstance.

Added as T07 and routed to railiance-platform. forgejo.coulomb.social already
runs on railiance01, so the work is retag, push, update manifest.

The generalisation goes into T06's proposed G-GEN gate: the inventory was built
from tunnels and workplans and both missed this. A host is not free of dependents
because nothing tunnels to it — it is free when nothing pulls, resolves or
authenticates against it either.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
tegwick 2026-08-20 08:47:23 +02:00
parent 4e0f10fe96
commit d9867bd783
2 changed files with 88 additions and 2 deletions
Download patch file Download diff file Expand all files Collapse all files

55
DECISIONS.md
View file

@ -46,3 +46,58 @@ retirement this project is planning.
The real finding survived the correction and sharpened: **the gen-3 runtime
serves from the host being decommissioned.**
## CoulombCore decommission date: end of August 2026
**2026-08-20, operator.** CoulombCore is to be retired **by 2026-08-31**. This
project treats that as a hard external constraint, not a target.
Eleven days. That materially decides `SHR-WP-0002-T03`: absorbing Core Hub
directly into `hub-core` depends on `CORE-WP-0010` → `HUB-WP-0004`, the latter
still holding an open decision on whether hub-core becomes a runtime at all.
Finishing an architecture decision *and* a production migration inside eleven
days is not a plan, it is a hope. **The project's recommendation to core-hub is
therefore the interim move** (`rmgr rapp wrap` onto railiance01, absorb into
hub-core afterwards on a calm schedule) — the pattern `issue-core` used one week
earlier. The choice remains core-hub's; the reasoning is recorded either way.
### What is actually still on CoulombCore
Established by resolving the public service names and inspecting railiance01,
2026-08-20:
| Service | Status | Consequence of shutdown |
| --- | --- | --- |
| `hub.coulomb.social` → Core Hub | Production since 2026-07-03 | Loss of the gen-3 interaction framework. Tracked, `SHR-WP-0002-T03` |
| `gitea.coulomb.social` → container registry | Live (200) | **Not tracked anywhere before today.** See below |
`bao`, `forgejo`, `policy`, `risk` and `reuse` all resolve to railiance01
already.
### The registry dependency nobody had written down
`gitea.coulomb.social` is a container registry on CoulombCore, and **two
workloads running on railiance01 pull their images from it**:
- `reuse/Deployment/reuse-surface` → `gitea.coulomb.social/coulomb/reuse-surface:e3ae22e`
- `state-hub/Job/state-hub-alembic-init` → `gitea.coulomb.social/coulomb/state-hub:f2e042a`
Checked across Deployments, StatefulSets, DaemonSets, Jobs and CronJobs; those
two are the whole set.
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.
`forgejo.coulomb.social` already runs on railiance01, so the destination exists
and the work is retag, push, update manifest. Routed to `railiance-platform`.
**Generalisation worth keeping:** the decommission inventory was built from
tunnels and workplans, and both missed this. A host is not free of dependents
because nothing *tunnels* to it — it is free when nothing *pulls, resolves or
authenticates* against it either.