--- id: ISSUE-WP-0003 type: workplan title: "Deploy issue-core as a service on railiance01 (ArgoCD GitOps pilot)" domain: custodian repo: issue-core status: active owner: claude topic_slug: custodian created: "2026-06-19" updated: "2026-06-19" state_hub_workstream_id: "" --- # Deploy issue-core as a service on railiance01 (ArgoCD GitOps pilot) `issue-core` is the authoritative task-lifecycle manager and the REST ingestion target for activity-core's `IssueSink`. Deployment artifacts (`Dockerfile`, `docker-entrypoint.sh`, `k8s/railiance/`) are now in-repo; the image builds locally and `/healthz` returns 200. The railiance01 cluster still has no `issue-core` namespace or workload — nothing is deployed until T01 push and T02 ArgoCD bootstrap complete. This workplan stands up `issue-core` as a first-class in-cluster service on railiance01 **via ArgoCD GitOps** — making issue-core the cluster's first declarative Application and turning on the idle GitOps capability. ## Current state (verified 2026-06-19) - **Deployment artifacts in-repo:** `Dockerfile`, `docker-entrypoint.sh`, and `k8s/railiance/` (Kustomize: ExternalSecret, ConfigMap, Deployment, Service). Image builds locally; `docker run` + `GET /healthz` returns 200. Image **not yet pushed** to `gitea.coulomb.social/coulomb/issue-core:0.2.0`. - **Dockerfile fix (2026-06-19):** build arg renamed `GITEA_PYPI_INDEX_URL` — `ARG PIP_INDEX_URL` leaked into the build env and pip used Gitea as the sole index, so dependencies like `click` were not found. - **railiance01 cluster:** no `issue-core` namespace; no issue-core Deployment/Service/Pod in any namespace. - **Dangling reference:** `activity-core/k8s/railiance/20-runtime.yaml` sets `ISSUE_CORE_URL: http://issue-core.issue-core.svc.cluster.local:8010` — a service that does not exist, on the **wrong port** (issue-core serves 8765) — with `ISSUE_SINK_TYPE: "null"` so emission is disabled. It is a placeholder. - **Packaging precursor is done:** `ISSUE-WP-0002` published `issue-core==0.2.0` to the Coulomb Gitea PyPI index. - **ArgoCD is installed but unused:** all 7 components healthy (~290d), but **0 Applications, 0 ApplicationSets, 0 registered git repos**, only the stock `default` AppProject. No `kind: Application` manifests exist in any infra repo. - **Existing deploy pattern is imperative** (the path we are *replacing* for this service): local `docker build` → `k3s ctr images import` (side-load, no registry) → `rsync` manifests → `kubectl apply` (see `activity-core/k8s/railiance/README.md`). ## Decisions - **Deployment method = ArgoCD GitOps** (operator decision 2026-06-19). issue-core is the pilot Application; the imperative side-load pattern is not used for this service. - **ArgoCD bootstrap owned by `railiance-platform`** (operator decision 2026-06-19). Platform owns repo registration, AppProject/app-of-apps conventions, and the External-Secrets/OpenBao plumbing. issue-core only **contributes** its `Application` manifest + workload manifests into the agreed GitOps source. T02 is therefore a cross-repo dependency, not issue-core work — see handoff to railiance-platform. - **Backend = cluster Gitea (markitect)** (operator decision 2026-06-19). Ingested tasks route to the existing Gitea backend; no new Postgres/PVC. - **Secret management = OpenBao.** `ISSUE_CORE_API_KEY` is a shared ingestion key injected from OpenBao on both issue-core and the activity-core worker. ops-warden does **not** vend it (see `~/ops-warden/wiki/playbooks/activity-core-issue-sink.md`). Coordinate the canonical path with `railiance-platform` (`issue-core-ingestion-api-key`). - **Image delivery = container registry, not side-load.** GitOps requires a pullable image tag in a registry the cluster can reach (the Coulomb Gitea container registry); side-loading defeats declarative reproducibility. ## Open questions - **GitOps source repo.** Resolved by `railiance-platform` as part of the bootstrap (T02 dependency): where issue-core's `Application` + manifests are expected to live (its own `issue-core/k8s/` vs. a platform GitOps repo) and the AppProject/app-of-apps convention to follow. - **Registry path & pull secret.** Confirm the Coulomb Gitea container registry path and the cluster pull-secret posture (tracked in `railiance-forge` container-registry docs and `railiance-apps-WP-0004` I03). --- ## Container image published to a pullable registry ```task id: ISSUE-WP-0003-T01 status: in_progress priority: high ``` **Goal.** A reproducible, registry-hosted image ArgoCD-managed pods can pull. - [x] Add `Dockerfile` installing `issue-core[api]>=0.2,<0.3` from the Gitea PyPI index (with explicit PyPI primary index). Entrypoint renders `backends.json` then `issue serve --host 0.0.0.0 --port 8765`. - [x] Local build succeeds; `docker run` + `GET /healthz` returns 200. - [ ] Build and **push to the Coulomb Gitea container registry** (confirm path per Open questions); tag `0.2.0`. - [ ] Configure the cluster pull secret so `issue-core` namespace pods can pull. - [ ] Verify: `POST /issues/` smoke; pushed tag pullable from the cluster. ## ArgoCD bootstrap (railiance-platform dependency) + issue-core Application ```task id: ISSUE-WP-0003-T02 status: wait priority: high ``` **Owner split.** ArgoCD bootstrap is **railiance-platform's** (operator decision 2026-06-19): repo registration in ArgoCD, AppProject/app-of-apps convention, and the agreed GitOps source layout. This task is `wait` on that handoff. issue-core's part is to **contribute** the `Application` manifest + workload manifests into the layout platform defines. - **(railiance-platform)** Register the GitOps source repo (repository Secret + creds); define AppProject for cluster services; publish the source-repo/path convention and sync policy. - **(issue-core)** Once the convention is known: author the `issue-core` ArgoCD `Application` manifest (source repo/path/revision → destination `issue-core` namespace) per the platform layout. - Verify: `kubectl get applications -n argocd` shows `issue-core` Synced/Healthy; ArgoCD reconciles a trivial manifest change. ## Kubernetes manifests (namespace, Deployment, Service) in GitOps source ```task id: ISSUE-WP-0003-T03 status: in_progress priority: high ``` **Goal.** Declarative manifests in the GitOps source repo, synced by T02. - [x] `k8s/railiance/` Kustomize bundle (namespace via ArgoCD `CreateNamespace=true`). - [x] Deployment: registry image tag `0.2.0`; port 8765; `/healthz` probes; resource requests/limits; env from ExternalSecret (T04) and ConfigMap (T05). - [x] Service: ClusterIP on **8765** as `issue-core.issue-core.svc.cluster.local`. - [ ] Verify: ArgoCD syncs the manifests; Pod Ready; `/healthz` 200 from a debug pod (blocked on T01 push + T02 bootstrap + T04 secrets). ## OpenBao secret: ISSUE_CORE_API_KEY ```task id: ISSUE-WP-0003-T04 status: todo priority: high ``` **Goal.** The shared ingestion key delivered to both sides from OpenBao. - Provision `ISSUE_CORE_API_KEY` in OpenBao at the canonical path (coordinate with `railiance-platform`; catalog id `issue-core-ingestion-api-key`). - Deliver into the issue-core Deployment (T03) and the activity-core worker (T06) with the **same** value (External Secrets / Bao injector — match the cluster's established mechanism). - Never write the value to Git, manifests, State Hub, or logs. - Verify: both pods resolve a non-empty key; auth round-trip (401 without, 201 with). ## In-cluster backend config (cluster Gitea / markitect) ```task id: ISSUE-WP-0003-T05 status: in_progress priority: medium ``` **Goal.** issue-core's `backends.json` inside the cluster points `default` at the cluster Gitea (markitect) backend. - [x] ConfigMap `issue-core-backends` with in-cluster Gitea URL (`gitea-http.default.svc.cluster.local:3000`); token sentinel `__FROM_ENV__`. - [x] `docker-entrypoint.sh` renders `~/.config/issue-tracker/backends.json` from `BACKENDS_TEMPLATE` + `GITEA_BACKEND_TOKEN` at startup. - [ ] Verify: a `POST /issues/` creates a real Gitea issue and returns `issue_url` (blocked on T04 secrets + in-cluster deployment). ## Wire activity-core to the live service ```task id: ISSUE-WP-0003-T06 status: todo priority: high ``` **Goal.** activity-core emits to the live issue-core Service. - Fix `activity-core/k8s/railiance/20-runtime.yaml`: `ISSUE_CORE_URL` port `8010 -> 8765`; flip `ISSUE_SINK_TYPE` `null -> rest` once issue-core is Ready. - Inject `ISSUE_CORE_API_KEY` into the activity-core worker from the same OpenBao secret (T04). - **Contract gap:** issue-core requires `triggering_event_id` as a UUID; activity-core cron paths may send non-UUID keys (e.g. `"scheduled"`). Event-driven emission with real event UUIDs works (the `str()` guard in `issue_sink.py`, commit f05c56e, handles UUID objects). Align schemas before enabling `rest` for cron-triggered rules. - Verify: an activity-core run emits a task that lands in cluster Gitea via issue-core. ## End-to-end verification + GitOps runbook ```task id: ISSUE-WP-0003-T07 status: todo priority: medium ``` **Goal.** Confirm the deployed service is healthy and document the new path. - ArgoCD Application Synced/Healthy; issue-core Pod Ready; Service reachable cluster-internal. - activity-core → issue-core emission returns 201 and creates a Gitea issue. - Document the GitOps runbook (image build/push, ArgoCD sync, secret rotation, rollback) in `docs/`. - Emit an `add_progress_event` milestone to the hub on completion. --- ## See also - `ISSUE-WP-0002` — Gitea PyPI publication (packaging precursor, finished). - `railiance-apps-WP-0004` I03 — issue-core packaging/image enablement notes. - `railiance-forge` — Gitea container registry docs. - `activity-core/docs/issue-core-emission-boundary.md` — emission contract. - `activity-core/k8s/railiance/README.md` — the imperative pattern being superseded for this service. - `~/ops-warden/wiki/playbooks/activity-core-issue-sink.md` — key routing.