From e2e4ef21720cc243d6cfb7afe5160f3a7f330ed3 Mon Sep 17 00:00:00 2001 From: tegwick Date: Wed, 19 Aug 2026 19:45:07 +0200 Subject: [PATCH] =?UTF-8?q?Draft=20ISSUE-WP-0007=20=E2=80=94=20move=20issu?= =?UTF-8?q?e-core=20off=20CoulombCore=20via=20rapp-issue-core?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit CoulombCore is being decommissioned and issue-core still runs there. The ops-bridge tunnel issue-core-railiance01 is a reverse forward re-exporting this workstation's 18765, so railiance01 currently reaches issue-core through a laptop forwarding to CoulombCore. Deleting the tunnel is not a migration. ISSUE-WP-0003 is marked finished and claims an ArgoCD-reconciled deployment on railiance01. Checked 2026-08-19: the issue-core namespace there is empty, the cluster has no ArgoCD at all, and /healthz answers from CoulombCore's cluster IP. T00 is to establish why before rebuilding, and to correct that record. Proposed, unassigned — drafted from ops-warden's CoulombCore sweep, so the packaging decisions are left to this repo rather than pre-made. Co-Authored-By: Claude Opus 5 --- ...7-rapp-issue-core-railiance01-migration.md | 210 ++++++++++++++++++ 1 file changed, 210 insertions(+) create mode 100644 workplans/ISSUE-WP-0007-rapp-issue-core-railiance01-migration.md diff --git a/workplans/ISSUE-WP-0007-rapp-issue-core-railiance01-migration.md b/workplans/ISSUE-WP-0007-rapp-issue-core-railiance01-migration.md new file mode 100644 index 0000000..15f36fe --- /dev/null +++ b/workplans/ISSUE-WP-0007-rapp-issue-core-railiance01-migration.md @@ -0,0 +1,210 @@ +--- +id: ISSUE-WP-0007 +type: workplan +title: "rapp-issue-core: move the runtime off CoulombCore onto railiance01" +domain: infotech +repo: issue-core +status: proposed +owner: unassigned +topic_slug: issue-core +priority: high +created: "2026-08-19" +updated: "2026-08-19" +depends_on: [] +related: + - ISSUE-WP-0003 + - RMGR-WP-0006 + - RMGR-WP-0007 +--- + +# ISSUE-WP-0007 — rapp-issue-core: move the runtime onto railiance01 + +CoulombCore is being decommissioned. `issue-core` is one of three services +still running there, and it is the load-bearing one: the ops-bridge tunnel +`issue-core-railiance01` is a **reverse** forward that re-exports this +workstation's `18765` to railiance01, so railiance01 reaches issue-core *through +a laptop* that is forwarding to CoulombCore. When CoulombCore goes, issue-core +goes with it, and deleting the tunnel is not a migration. + +## Start here: ISSUE-WP-0003 says this is already done. It is not. + +`ISSUE-WP-0003` is `status: finished` and states that "the railiance01 cluster +now reconciles `issue-core` through ArgoCD; External Secrets Operator reads the +OpenBao-backed runtime Secret and the Deployment is live on port 8765." + +Checked on 2026-08-19 against the railiance01 cluster +(`~/.kube/config-railiance01`, bridge tunnel `k3s-api-railiance01`, local +`16444`): + +| Claim | Observed | +| --- | --- | +| Deployment live in `issue-core` namespace | Namespace exists, **empty** — `No resources found` | +| Reconciled by ArgoCD | **No ArgoCD** — the cluster has no `applications` resource type | +| issue-core serving | Serving from **CoulombCore**: `-L 18765:10.43.103.154:8765`, `/healthz` → `{"status":"ok","version":"0.2.1"}` | + +Whatever was stood up under WP-0003 is gone — most plausibly the railiance01 +cluster was rebuilt without it, since ArgoCD itself is absent. **Task T00 is to +establish what actually happened before rebuilding**, because if the deployment +was lost silently once it will be lost silently again, and a GitOps controller +that no longer exists is a different starting point than one that drifted. + +Do not treat WP-0003 as prior art to resume. Treat it as a record that needs +correcting once this workplan establishes the truth. + +## Why a `rapp-` wrapper rather than `k8s/railiance/` in this repo + +`issue-core` currently carries its own `Dockerfile` and `k8s/railiance/` +Kustomize tree. The estate has since settled on a different split, visible in +`rapp-postgres`, `rapp-qonto`, `rapp-user-engine`, `rapp-tenant-engine`, +`rapp-openbao`, `rapp-secrets-engine`, `rapp-policy-nexus`: **domain logic stays +in the app repo; runtime packaging, bindings, secret references, network policy, +placement, and rollout evidence live in a `rapp-` repo.** + +`rapp-qonto/README.md` states the boundary plainly: "Domain logic and financial +policy stay in `qonto-assistant`. This repo owns runtime packaging, the Knative +binding, secret references, network policy, and workload-specific rollout +evidence." + +That split is also what makes the loss above visible next time: rollout evidence +is a deliverable of the wrapper, not a side effect of a cluster being up. + +`repo-manager` scaffolds these — do not hand-build one: + +```bash +rmgr rapp wrap --path ../rapp-issue-core --app issue-core \ + --ownership-repo issue-core --from-app ../issue-core \ + --rail rail-kubernetes \ + --package-type manifest-managed-platform-service +rmgr rapp validate --path ../rapp-issue-core --family-root .. +rmgr rapp place --path ../rapp-issue-core --reef reef-railiance +``` + +`--rail`, `--classification`, `--criticality`, and `--package-type` are +decisions, not defaults to accept blindly — settle them in T01. See +`repo-manager/docs/RailianceAppDeploymentGuide.md` (RMGR-WP-0006) and +`RMGR-WP-0007` (greenfield rapp wrap efficiency). + +## Consumers to carry across + +Migration is not done when a pod is Running. These reach issue-core today: + +- **activity-core** — `IssueSink` emission. ops-warden routes this need as + catalog id `activity-core-issue-sink`. +- **ops-bridge** — tunnels `issue-core-coulombcore` (`-L 18765` → + `10.43.103.154:8765`) and `issue-core-railiance01` (reverse re-export). Both + are retired by this work; the second one should not be recreated in any form. +- Anything reading `http://127.0.0.1:18765` on the workstation. + +## Tasks + +```task +id: ISSUE-WP-0007-T00 +status: todo +priority: high +``` + +**Establish what happened to the WP-0003 deployment.** Before rebuilding: +was ArgoCD removed deliberately, was the cluster rebuilt, or did the +Application drift and get pruned? Check railiance01 cluster history, the +`issue-core` namespace's remaining objects, and the OpenBao-backed +ExternalSecret referenced by WP-0003. Record the finding, and correct +`ISSUE-WP-0003` — a workplan asserting a production deployment that does not +exist will mislead the next reader exactly as it misled this one. + +Deliverable: a short `history/` note. If the cause turns out to be a +platform-side defect rather than an issue-core one, route it to `risk-nexus` +as a finding rather than absorbing it here. + +```task +id: ISSUE-WP-0007-T01 +status: todo +priority: high +``` + +**Settle the packaging decisions.** `--rail` (`rail-kubernetes` vs +`rail-knative`), `--package-type`, `--classification`, `--criticality`, and +whether issue-core needs `--dedicated-postgres` or consumes `rapp-postgres` as +a consumer (it has a database; check which pattern the other rapps that need +one actually use). Decide against the existing `k8s/railiance/` manifests so +the wrapper starts from something real. + +```task +id: ISSUE-WP-0007-T02 +status: todo +priority: high +``` + +**Scaffold `rapp-issue-core` via `rmgr rapp wrap`,** then +`rmgr rapp validate --family-root ..`. Do not hand-author the layout; the +validator encodes the family conventions and will reject a bespoke tree. +Register the new repo the normal way (write the files, commit, run the +consistency check) rather than by hand. + +```task +id: ISSUE-WP-0007-T03 +status: todo +priority: high +``` + +**Port the runtime.** Move `Dockerfile` / image build and the `k8s/railiance/` +tree into the wrapper's shape: manifests, secret references (OpenBao-backed +ExternalSecret — custody stays with the platform, never in this repo), +NetworkPolicy, Service. Image `0.2.1` is what is serving today; decide whether +to rebuild or promote the existing digest. + +`issue-core` keeps its domain code and loses its deployment artifacts. That +deletion is part of the task, not a follow-up — two sources of deployment truth +is the failure this split exists to prevent. + +```task +id: ISSUE-WP-0007-T04 +status: todo +priority: high +``` + +**Deploy to railiance01 and prove it.** `rmgr rapp place --reef reef-railiance`, +then live evidence in the wrapper: cold start, `/healthz` 200 from *inside* the +cluster (not through a laptop forward), dependency-failure behaviour, and +rollback. Follow `rapp-qonto/tools/verify_live.sh` as the shape — reversible, +secret-free. + +Evidence that the service answers only via an ops-bridge tunnel does not count. +That is the condition being retired. + +```task +id: ISSUE-WP-0007-T05 +status: todo +priority: high +``` + +**Cut consumers over, then retire the tunnels.** Point activity-core's +`IssueSink` at the in-cluster address; ask ops-warden to update catalog id +`activity-core-issue-sink` if the routing pointer changes. Only once consumers +are on the new address, ask ops-bridge to remove `issue-core-coulombcore` and +`issue-core-railiance01` from `~/.config/bridge/tunnels.yaml`. + +Order matters: removing the tunnels first takes issue-core down for everyone +still pointed at `127.0.0.1:18765`. + +```task +id: ISSUE-WP-0007-T06 +status: todo +priority: medium +``` + +**Close out.** Update `SCOPE.md` and `WORK-RECORDS.md`; correct `ISSUE-WP-0003` +per T00; tell ops-warden and ops-bridge that CoulombCore has one fewer +dependency. Remaining CoulombCore services after this: `core-hub-staging` and +`inter-hub`. + +## Notes for whoever picks this up + +- ops-bridge tunnel map header (`~/.config/bridge/tunnels.yaml`) lists what is + left on CoulombCore and why. +- railiance01 cluster access: `kubectl --kubeconfig ~/.kube/config-railiance01` + (tunnel `k3s-api-railiance01`, local `16444`). There is no CoulombCore + kubeconfig any more — its `k3s-api` tunnel was removed on 2026-08-19, so + inspecting the *current* deployment needs that tunnel restored first. +- This workplan was drafted from outside issue-core (during ops-warden's + CoulombCore retirement sweep). The tasks are stated as findings and decisions + rather than a fixed design, because the owning repo should make the calls.