--- 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.