docs(migration): record gitea runner bootstrap on sol

This commit is contained in:
mpabi
2026-04-12 16:48:35 +02:00
parent f2f97d1d5a
commit dc59423c75

View File

@@ -70,6 +70,8 @@ Date: `2026-04-12`
- `trade-docs` - `trade-docs`
- The current live component-to-repository boundary was documented in `trade-next/trade-docs/doc/k3s-component-repo-map.md`. - The current live component-to-repository boundary was documented in `trade-next/trade-docs/doc/k3s-component-repo-map.md`.
- We have not yet reconstructed the current live `trade-staging` manifests and host drift into `trade-gitops` and `trade-host-iac`. - We have not yet reconstructed the current live `trade-staging` manifests and host drift into `trade-gitops` and `trade-host-iac`.
- The first canonical bootstrap module now exists in `trade-next/trade-gitops`: `bootstrap/gitea-actions`.
- An organization-scoped Gitea Actions runner for `trade-next` is now online on `sol` and can reach the target `k3s` cluster using the `K3S_KUBECONFIG_B64` org secret.
## Migration Risks ## Migration Risks
@@ -196,6 +198,7 @@ Date: `2026-04-12`
- Record every current live drift before moving workloads. - Record every current live drift before moving workloads.
- Done on `2026-04-12`: `trade-next` was created and the target repositories now exist. - Done on `2026-04-12`: `trade-next` was created and the target repositories now exist.
- Done on `2026-04-12`: the live component boundary map was written to `trade-next/trade-docs/doc/k3s-component-repo-map.md`. - Done on `2026-04-12`: the live component boundary map was written to `trade-next/trade-docs/doc/k3s-component-repo-map.md`.
- Done on `2026-04-12`: bootstrapped `trade-next/trade-gitops` with the first runnable IaC module for `sol` under `bootstrap/gitea-actions`.
- Next for item `02`: reconstruct the live `trade-staging` objects, overlays, secrets wiring, and host-specific drift into `trade-gitops` and `trade-host-iac`. - Next for item `02`: reconstruct the live `trade-staging` objects, overlays, secrets wiring, and host-specific drift into `trade-gitops` and `trade-host-iac`.
### 03. Fix `dlob-publisher-hot` startup, readiness, and liveness ### 03. Fix `dlob-publisher-hot` startup, readiness, and liveness
@@ -291,25 +294,39 @@ Date: `2026-04-12`
- Done on `2026-04-12`: validated `Postgres` on `/srv/trade/postgres/16/main`, validated `Redis` on `/srv/trade/redis`, and confirmed `btrfs` quotas are active for both paths. - Done on `2026-04-12`: validated `Postgres` on `/srv/trade/postgres/16/main`, validated `Redis` on `/srv/trade/redis`, and confirmed `btrfs` quotas are active for both paths.
- Done on `2026-04-12`: `Postgres` listens with pod CIDR access in `pg_hba.conf`, and `Redis` announces `149.50.96.162` for cluster-aware clients inside `k3s`. - Done on `2026-04-12`: `Postgres` listens with pod CIDR access in `pg_hba.conf`, and `Redis` announces `149.50.96.162` for cluster-aware clients inside `k3s`.
### 19. Prepare a minimal canary namespace for trade on `mevnode` ### 19. Bootstrap an organization-scoped Gitea Actions runner on `mevnode`
- Done on `2026-04-12`.
- Use `trade-next/trade-gitops` as the canonical bootstrap source, not an ad-hoc shell history on the host.
- Scope the runner at the `trade-next` organization level so every migration repository can reuse the same execution plane.
- Keep the first bootstrap simple: one runner replica on `sol`, one deployer service account, and one org secret carrying a kubeconfig for cluster access.
- Keep the runner state persistent only where necessary; avoid long-lived Docker layer storage until image caching strategy is explicitly planned.
- Done on `2026-04-12`: created `trade-next/trade-gitops` initial `main` branch with `bootstrap/gitea-actions` manifests, scripts, and a smoke workflow.
- Done on `2026-04-12`: deployed `trade-next-act-runner` in namespace `gitea-actions` on `sol` using `docker.io/gitea/act_runner:latest` with a `docker:27-dind` sidecar.
- Done on `2026-04-12`: created `trade-gitops-deployer` service account and initial `cluster-admin` binding for first-pass GitOps bootstrap.
- Done on `2026-04-12`: synced `K3S_KUBECONFIG_B64` as an organization secret in `trade-next`.
- Done on `2026-04-12`: verified the runner is `online` in Gitea with labels `ubuntu-latest` and `k3s-deploy`.
- Done on `2026-04-12`: verified workflow execution from `trade-next/trade-gitops`; commit `c566978` completed with status `success` for `runner-smoke / smoke (push)`.
### 20. Prepare a minimal canary namespace for trade on `mevnode`
- Pending. - Pending.
### 20. Bring up `Hasura`, API, and frontend on `mevnode` ### 21. Bring up `Hasura`, API, and frontend on `mevnode`
- Pending. - Pending.
- Bring up `Hasura` only after `Postgres` is healthy. - Bring up `Hasura` only after `Postgres` is healthy.
- Bring up API and frontend only after `Hasura`, `Postgres`, and `Redis` are healthy. - Bring up API and frontend only after `Hasura`, `Postgres`, and `Redis` are healthy.
### 21. Migrate publishers and ingest only after storage and Redis validation pass ### 22. Migrate publishers and ingest only after storage and Redis validation pass
- Pending. - Pending.
### 22. Validate host health, agave health, trade health, and end-to-end flow after rollout ### 23. Validate host health, agave health, trade health, and end-to-end flow after rollout
- Pending. - Pending.
### 23. Keep `mevnode_bot` as a rollback target until the new stack is stable ### 24. Keep `mevnode_bot` as a rollback target until the new stack is stable
- Pending. - Pending.
@@ -333,8 +350,9 @@ Date: `2026-04-12`
- [ ] 16. Define the maximum acceptable swap usage on `mevnode` during rollout. - [ ] 16. Define the maximum acceptable swap usage on `mevnode` during rollout.
- [x] 17. Install and bootstrap `k3s` on `mevnode`. - [x] 17. Install and bootstrap `k3s` on `mevnode`.
- [x] 18. Install `Postgres` and `Redis` on `mevnode`. - [x] 18. Install `Postgres` and `Redis` on `mevnode`.
- [ ] 19. Prepare a minimal canary namespace for trade on `mevnode`. - [x] 19. Bootstrap an organization-scoped Gitea Actions runner on `mevnode`.
- [ ] 20. Bring up `Hasura`, API, and frontend on `mevnode`. - [ ] 20. Prepare a minimal canary namespace for trade on `mevnode`.
- [ ] 21. Migrate publishers and ingest only after storage and Redis validation pass. - [ ] 21. Bring up `Hasura`, API, and frontend on `mevnode`.
- [ ] 22. Validate host health, agave health, trade health, and end-to-end flow after rollout. - [ ] 22. Migrate publishers and ingest only after storage and Redis validation pass.
- [ ] 23. Keep `mevnode_bot` as a rollback target until the new stack is stable. - [ ] 23. Validate host health, agave health, trade health, and end-to-end flow after rollout.
- [ ] 24. Keep `mevnode_bot` as a rollback target until the new stack is stable.