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.

35
workplans/SHR-WP-0002-predecessor-and-deployment-reality.md
View file

@ -172,8 +172,10 @@ decommission date is a real constraint currently represented in no plan —
including this project's own gate model, which `T06` addresses.
Also asked: whether the decommission date changes `HUB-WP-0004`'s open
library-vs-thin-host decision. **Open dependency for this project: the
CoulombCore decommission date is not pinned anywhere we can cite.**
library-vs-thin-host decision. **Pinned 2026-08-20 by the operator: CoulombCore retires by 2026-08-31.**
Eleven days. See `DECISIONS.md`. On that constraint the project recommends the
interim move — an architecture decision plus a production migration inside
eleven days is not a plan. The choice remains core-hub's.
```task
id: SHR-WP-0002-T04
@ -232,6 +234,35 @@ consumers are reconciled, its downstream lanes are swept, and its successor is
deployed somewhere that will still exist. Take it through the project's normal
decision route rather than adding it unilaterally.
```task
id: SHR-WP-0002-T07
status: todo
priority: high
```
**The registry dependency, found 2026-08-20 and not previously tracked.**
`gitea.coulomb.social` is a live container registry on CoulombCore, and two
railiance01 workloads pull images from it:
`reuse/Deployment/reuse-surface` and `state-hub/Job/state-hub-alembic-init`
(checked across Deployments, StatefulSets, DaemonSets, Jobs and CronJobs — that
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.
`forgejo.coulomb.social` is already on railiance01, so the work is retag, push,
update manifest. Routed to `railiance-platform`; ownership of the `reuse-surface`
manifest sits with that repo.
**Why this is a project task and not a platform ticket:** it was missed because
the decommission inventory was assembled from tunnels and workplans. A host is
not free of dependents because nothing tunnels to it. Feed that into `T06`'s
`G-GEN` gate — a generation or host transition must enumerate what *pulls,
resolves and authenticates* against the thing being switched off, not only what
connects to it.
## Related
- `SHR-WP-0001` — foundation and architecture baseline (finished)