docs: update issue-core deployment closeout

This commit is contained in:
2026-07-01 20:04:37 +02:00
parent e5172611ec
commit 8d34c6d468
2 changed files with 41 additions and 19 deletions

View File

@@ -7,7 +7,7 @@ railiance-platform.
## Source layout ## Source layout
- Workload bundle: `issue-core/k8s/railiance/` - Workload bundle: `issue-core/k8s/railiance/`
- Image: `gitea.coulomb.social/coulomb/issue-core:0.2.0` - Image: `gitea.coulomb.social/coulomb/issue-core:0.2.1`
- Container port and Service port: `8765` - Container port and Service port: `8765`
- Cluster Service URL: `http://issue-core.issue-core.svc.cluster.local:8765` - Cluster Service URL: `http://issue-core.issue-core.svc.cluster.local:8765`
- Tenant Application: `railiance-platform/argocd/applications/issue-core.application.yaml` - Tenant Application: `railiance-platform/argocd/applications/issue-core.application.yaml`
@@ -18,31 +18,31 @@ therefore intentionally not duplicated in this bundle.
## Platform gates ## Platform gates
The following pieces are owned by railiance-platform before the workload can The following pieces are owned by railiance-platform for the live pilot and for
be fully reconciled: any future cluster replay:
- ArgoCD repository credentials and the project/app-of-apps convention. - ArgoCD repository credentials and the project/app-of-apps convention.
- The `issue-core` ArgoCD `Application`. - The `issue-core` ArgoCD `Application`.
- External Secrets Operator and a `ClusterSecretStore` named `openbao`. - External Secrets Operator and a `ClusterSecretStore` named `openbao`.
- OpenBao entries for the issue-core runtime Secret. - OpenBao entries for the issue-core runtime Secret.
Until those gates exist, `kubectl kustomize k8s/railiance` can render locally, For the 2026-06-25 live deployment, these gates were satisfied and the
but the live `ExternalSecret` and `Deployment` are expected to wait. `issue-core` Application reached Synced/Healthy with image `0.2.1`.
## Secret contract ## Secret contract
Kubernetes Secret name: `issue-core-runtime` Kubernetes Secret name: `issue-core-runtime`
Current issue-core manifest path, pending railiance-platform confirmation: Current issue-core manifest path:
```text ```text
platform/workloads/issue-core/issue-core/issue-core-runtime platform/workloads/issue-core/issue-core/issue-core-runtime
``` ```
Credential route catalog id `issue-core-ingestion-api-key` is owned by Credential custody is owned by railiance-platform/OpenBao. For agents, first
railiance-platform/OpenBao and is still marked draft/path TBD in the local use the non-secret route catalog entry `activity-core-issue-sink` to confirm
ops-warden catalog reviewed 2026-06-18. Confirm the canonical path before the activity-core + issue-core pairing, and never request the value from
provisioning the live Secret. ops-warden.
Required properties: Required properties:
@@ -56,12 +56,12 @@ HTTP status codes, and created issue URLs.
## Build and publish ## Build and publish
Use the published package as the image input. For a reproducible release image, Build the checked-out source tree and publish a registry tag that ArgoCD can
pin the package version to the image tag: pull:
```bash ```bash
docker build --build-arg ISSUE_CORE_VERSION="==0.2.0" -t gitea.coulomb.social/coulomb/issue-core:0.2.0 . docker build -t gitea.coulomb.social/coulomb/issue-core:0.2.1 .
docker push gitea.coulomb.social/coulomb/issue-core:0.2.0 docker push gitea.coulomb.social/coulomb/issue-core:0.2.1
``` ```
The Coulomb Gitea package is public-pullable for this image, so the workload The Coulomb Gitea package is public-pullable for this image, so the workload

View File

@@ -4,11 +4,11 @@ type: workplan
title: "Deploy issue-core as a service on railiance01 (ArgoCD GitOps pilot)" title: "Deploy issue-core as a service on railiance01 (ArgoCD GitOps pilot)"
domain: infotech domain: infotech
repo: issue-core repo: issue-core
status: active status: blocked
owner: claude owner: claude
topic_slug: custodian topic_slug: custodian
created: "2026-06-19" created: "2026-06-19"
updated: "2026-06-25" updated: "2026-06-30"
state_hub_workstream_id: "896ace77-21b3-450b-8fb7-254aefc8c570" state_hub_workstream_id: "896ace77-21b3-450b-8fb7-254aefc8c570"
--- ---
@@ -73,6 +73,23 @@ declarative Application and turning on the idle GitOps capability.
`/healthz` returns 200; authenticated `POST /issues/` returned 201 and Gitea `/healthz` returns 200; authenticated `POST /issues/` returned 201 and Gitea
issue id `175`. issue id `175`.
## Closeout recheck (2026-06-30)
- issue-core-owned deployment work remains complete: manifests, runtime secret
contract, backend config, runbook, and direct authenticated ingestion smoke are
done for image `0.2.1`.
- The remaining completion gate is the activity-core producer handoff. A
non-secret source recheck of `/home/worsch/activity-core/k8s/railiance/20-runtime.yaml`
still shows `ISSUE_CORE_URL` on port `8010` and `ISSUE_SINK_TYPE: "null"`.
- `ops-warden` routing catalog entry `activity-core-issue-sink` confirms the
lane is owned by activity-core + issue-core and that ops-warden does not vend
`ISSUE_CORE_API_KEY`.
- This WSL session does not have `kubectl` on PATH, so live ArgoCD/Kubernetes
state could not be re-polled from the workstation. Keep T06/T07 at `wait`
until the activity-core runtime is switched to the service on port `8765`,
receives the shared key through OpenBao, and an activity-core emission returns
issue-core HTTP 201 with a created Gitea issue.
## Decisions ## Decisions
- **Deployment method = ArgoCD GitOps** (operator decision 2026-06-19). - **Deployment method = ArgoCD GitOps** (operator decision 2026-06-19).
@@ -218,7 +235,7 @@ the cluster Gitea (markitect) backend.
```task ```task
id: ISSUE-WP-0003-T06 id: ISSUE-WP-0003-T06
status: progress status: wait
priority: high priority: high
state_hub_task_id: "96b14cdb-364f-4eab-a80e-dd8b3859c694" state_hub_task_id: "96b14cdb-364f-4eab-a80e-dd8b3859c694"
``` ```
@@ -234,6 +251,10 @@ state_hub_task_id: "96b14cdb-364f-4eab-a80e-dd8b3859c694"
accepts `triggering_event_id` as a non-empty traceability string, so accepts `triggering_event_id` as a non-empty traceability string, so
event-driven paths can send UUIDs and cron paths can send stable keys such as event-driven paths can send UUIDs and cron paths can send stable keys such as
`"scheduled"`. `"scheduled"`.
- [ ] activity-core runtime source still needs the live flip:
`ISSUE_CORE_URL` `8010 -> 8765` and `ISSUE_SINK_TYPE` `"null" -> "rest"`.
- [ ] activity-core worker still needs the shared `ISSUE_CORE_API_KEY` from the
approved OpenBao lane; never write the value to Git, State Hub, logs, or chat.
- Verify: an activity-core run emits a task that lands in cluster Gitea via - Verify: an activity-core run emits a task that lands in cluster Gitea via
issue-core. issue-core.
@@ -241,7 +262,7 @@ state_hub_task_id: "96b14cdb-364f-4eab-a80e-dd8b3859c694"
```task ```task
id: ISSUE-WP-0003-T07 id: ISSUE-WP-0003-T07
status: progress status: wait
priority: medium priority: medium
state_hub_task_id: "8d853b8e-cfca-441d-b817-0a29e37bd66e" state_hub_task_id: "8d853b8e-cfca-441d-b817-0a29e37bd66e"
``` ```
@@ -254,7 +275,8 @@ state_hub_task_id: "8d853b8e-cfca-441d-b817-0a29e37bd66e"
(remaining T06 handoff). (remaining T06 handoff).
- [x] Document the GitOps runbook (image build/push, ArgoCD sync, secret - [x] Document the GitOps runbook (image build/push, ArgoCD sync, secret
contract, smoke, activity-core handoff) in `docs/argocd-gitops.md`. contract, smoke, activity-core handoff) in `docs/argocd-gitops.md`.
- Emit an `add_progress_event` milestone to the hub on completion. - Emit an `add_progress_event` milestone to the hub when the activity-core
emission proof exists and this workplan can move from `blocked` to `finished`.
--- ---