From 2a3fc70172d88f8af7f3da3c0d29558e1b5081d0 Mon Sep 17 00:00:00 2001 From: tegwick Date: Fri, 21 Aug 2026 00:47:26 +0200 Subject: [PATCH] Record production deploy of main-b035664 (REUSE-WP-0020-T05 done) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 --- WORK-RECORDS.md | 4 +- ...-WP-0020-coulombcore-retirement-cutover.md | 78 +++++++++++++++---- 2 files changed, 65 insertions(+), 17 deletions(-) diff --git a/WORK-RECORDS.md b/WORK-RECORDS.md index 124eae1..58ba7aa 100644 --- a/WORK-RECORDS.md +++ b/WORK-RECORDS.md @@ -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 | diff --git a/workplans/REUSE-WP-0020-coulombcore-retirement-cutover.md b/workplans/REUSE-WP-0020-coulombcore-retirement-cutover.md index c5d7e8d..0d7298b 100644 --- a/workplans/REUSE-WP-0020-coulombcore-retirement-cutover.md +++ b/workplans/REUSE-WP-0020-coulombcore-retirement-cutover.md @@ -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