Draft ISSUE-WP-0007 — move issue-core off CoulombCore via rapp-issue-core
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 <noreply@anthropic.com>
This commit is contained in:
parent
a2aa49470a
commit
e2e4ef2172
1 changed files with 210 additions and 0 deletions
210
workplans/ISSUE-WP-0007-rapp-issue-core-railiance01-migration.md
Normal file
210
workplans/ISSUE-WP-0007-rapp-issue-core-railiance01-migration.md
Normal file
|
|
@ -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-<app>` 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.
|
||||||
Loading…
Add table
Add a link
Reference in a new issue