coulomb/reuse-surface
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Record production deploy of main-b035664 (REUSE-WP-0020-T05 done)
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
Details
CI Smoke / container-smoke (push) Successful in 2s
Details
ci / validate-registry (push) Successful in 3m10s
Details

Browse source 
Helm revision 7 on Railiance01. Production now runs a Forgejo image; the Gitea
dependency is gone from both the federation sources and the image reference.
/v1/reuse-events returns 200 for the first time, so REUSE-WP-0019 T04/T05 are
finally live. PVC and all 61 registrations survived.

Also diagnose T06: /health is served correctly by the app (200 in-cluster) but
Traefik routes it to the landing nginx, because router priority is derived from
rule-string length and Path(/health) ties with PathPrefix(/). Raise T06 to
medium — make reuse-smoke is the documented deploy check and it false-negatives.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
tegwick 2026-08-21 00:47:26 +02:00
parent 3b46fd747f
commit 2a3fc70172
2 changed files with 65 additions and 17 deletions
Download patch file Download diff file Expand all files Collapse all files

4
WORK-RECORDS.md
View file

@ -72,9 +72,9 @@
| task | REUSE-WP-0016-T09 | done | — | workplans/REUSE-WP-0016-interactive-registry-maintain.md |
| task | REUSE-WP-0020-T01 | done | — | workplans/REUSE-WP-0020-coulombcore-retirement-cutover.md |
| task | REUSE-WP-0020-T02 | done | — | workplans/REUSE-WP-0020-coulombcore-retirement-cutover.md |
| task | REUSE-WP-0020-T03 | todo | — | workplans/REUSE-WP-0020-coulombcore-retirement-cutover.md |
| task | REUSE-WP-0020-T03 | wait | — | workplans/REUSE-WP-0020-coulombcore-retirement-cutover.md |
| task | REUSE-WP-0020-T04 | wait | — | workplans/REUSE-WP-0020-coulombcore-retirement-cutover.md |
| task | REUSE-WP-0020-T05 | todo | — | workplans/REUSE-WP-0020-coulombcore-retirement-cutover.md |
| task | REUSE-WP-0020-T05 | progress | — | workplans/REUSE-WP-0020-coulombcore-retirement-cutover.md |
| task | REUSE-WP-0020-T06 | todo | — | workplans/REUSE-WP-0020-coulombcore-retirement-cutover.md |
| task | REUSE-WP-0020-T07 | todo | — | workplans/REUSE-WP-0020-coulombcore-retirement-cutover.md |
| task | REUSE-WP-0020-T08 | done | — | workplans/REUSE-WP-0020-coulombcore-retirement-cutover.md |

78
workplans/REUSE-WP-0020-coulombcore-retirement-cutover.md
View file

@ -161,7 +161,7 @@ hardened, re-enable and confirm `/v1/federated` returns 61 sources.
```task
id: REUSE-WP-0020-T05
status: progress
status: done
priority: high
```
@ -193,8 +193,45 @@ Deadline-bound: must land before **2026-08-31**.
controller, so a commit there deploys nothing — `make reuse-deploy` is a
manual `helm upgrade` requiring `REUSE_KUBECONFIG` for Railiance01.
3. ~~Correct `docs/deploy/reuse-kubernetes.md`.~~ **Done 2026-08-20** (`b035664`).
4. **Remaining.** Apply from a host with cluster access — the workstation
kubeconfig points at `127.0.0.1:16443` and needs an ops-bridge tunnel:
4. **Applied 2026-08-21 00:44 CEST — Helm revision 7, `Upgrade complete`.**
Access note worth keeping: `RAILIANCE01_KUBECONFIG` defaults to
`~/.kube/config-hosteurope` (`127.0.0.1:16443`), which has **no tunnel**.
The working path is `~/.kube/config-railiance01` (`127.0.0.1:16444`), served
by the `k3s-api-railiance01` ops-bridge tunnel. Deploy with
`RAILIANCE01_KUBECONFIG=$HOME/.kube/config-railiance01 make reuse-deploy`
until the Makefile default is corrected.
Pre-flight checks that mattered:
- The live Deployment really was on `gitea.coulomb.social/coulomb/reuse-surface:e3ae22e`
with `pullPolicy: IfNotPresent` — it had survived 18 restarts only because
the image was cached on the node. One eviction or image GC would have
ended it, retirement date or not.
- **No `imagePullSecrets` anywhere** in the chart or the namespace, and the
Forgejo `/v2/` endpoint answers `401` anonymously — which looked fatal.
It is not: that `401` is Forgejo's token handshake, and peers like
`audit-core` pull from the same registry with no secret. Verified properly
via the anonymous token flow (`/v2/token?scope=repository:coulomb/reuse-surface:pull`)
→ manifest `200`. No pull secret needed.
Post-deploy verification:
| Check | Result |
|---|---|
| Pod | `reuse-surface-7f79d88c-fz7fd`, 0 restarts, ready |
| Image | `forgejo.coulomb.social/coulomb/reuse-surface:main-b035664` |
| PVC | `reuse-surface-data` bound to the same `pvc-98165f95…` — data kept |
| Registrations | all 61 survived |
| `/v1/repos`, `/v1/federated` | 200; 60 sources, all Forgejo, 62 capabilities |
| `/v1/reuse-events` | **200** (was 404) — REUSE-WP-0019 T04/T05 finally live |
| TLS certificate | `condition met` |
Rollback if ever needed: `helm rollback reuse 6 -n reuse` — but note revision 6
pins the Gitea image, which only pulls while the node cache holds it and not
at all after 2026-08-31. Rolling forward is the safer direction.
Superseded steps, kept for context:
```bash
make reuse-dry-run # helm template, no apply
@ -207,9 +244,9 @@ Deadline-bound: must land before **2026-08-31**.
Confirm the PVC at `/data` survived, since `reuse.db` and the remote index
cache live there.
**`make reuse-smoke` will fail** — it runs `curl -fsS $(REUSE_URL)/health`,
and `/health` returns nginx `404` through the ingress (see T06). Fix that
first or expect a false negative on an otherwise good deploy.
**`make reuse-smoke` still fails** — it runs `curl -fsS $(REUSE_URL)/health`,
and `/health` returns nginx `404` through the ingress (T06). Everything else
in that target passes; the failure is a false negative.
Ships REUSE-WP-0019 **T04/T05/T06** as a side effect — telemetry store,
R-axis aggregation, and hub freshness monitoring were closed as finished but
@ -223,20 +260,31 @@ Review the six weeks of change between `e3ae22e` and HEAD before applying.
```task
id: REUSE-WP-0020-T06
status: todo
priority: low
priority: medium
```
Two smaller production inconsistencies found while verifying T01:
- `GET /health` returns nginx `404` through the ingress, though
`docs/deploy/reuse-kubernetes.md` documents it as the liveness path and the
landing page links it. Only `/v1/*` routes. Pod probes hit the container
directly so the service is unaffected, but the documented URL is wrong —
fix the ingress route or the docs, whichever matches intent.
- `GET /health` returns nginx `404` through the ingress. **Diagnosed
2026-08-21, not yet fixed.** The application is fine: in-cluster
`http://reuse-surface:8000/health` returns `200`. The ingress rule is also
correct on paper — `/health` `Exact` → `reuse-surface:8000`, ahead of `/`
`Prefix` → `reuse-surface-landing:8080`. The problem is Traefik: it derives
router priority from the length of the generated rule string, and
``Path(`/health`)`` and ``PathPrefix(`/`)`` are the *same length*, so the
tiebreak is arbitrary and the landing route wins. Confirmed by the response
carrying `server: nginx/1.27.5` (the landing container) rather than
`uvicorn`.
Fix by setting an explicit
`traefik.ingress.kubernetes.io/router.priority` annotation so the API routes
outrank the landing catch-all, in `railiance-apps/charts/reuse-surface`.
This is not cosmetic: `make reuse-smoke` is the documented deploy
verification and it fails on an otherwise healthy release.
- `composed_at` stayed at `2026-08-20T20:44:12` with `stale: false` across a
recompose that demonstrably changed output (61 → 62 capabilities). The
freshness timestamp is not tracking recomposes. Re-check after T05, since
REUSE-WP-0019-T06 touches exactly this and is not deployed.
recompose that demonstrably changed output (61 → 62 capabilities). Now that
T05 has shipped REUSE-WP-0019-T06, re-observe before treating this as a bug —
the deployed build at the time predated the freshness work.
## Refresh SCOPE.md Standard Sections