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