diff --git a/doc/migration-todo.md b/doc/migration-todo.md index 47365b5..42f863c 100644 --- a/doc/migration-todo.md +++ b/doc/migration-todo.md @@ -70,6 +70,8 @@ Date: `2026-04-12` - `trade-docs` - 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`. +- 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 @@ -196,6 +198,7 @@ Date: `2026-04-12` - 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`: 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`. ### 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`: `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. -### 20. Bring up `Hasura`, API, and frontend on `mevnode` +### 21. Bring up `Hasura`, API, and frontend on `mevnode` - Pending. - Bring up `Hasura` only after `Postgres` is 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. -### 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. -### 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. @@ -333,8 +350,9 @@ Date: `2026-04-12` - [ ] 16. Define the maximum acceptable swap usage on `mevnode` during rollout. - [x] 17. Install and bootstrap `k3s` on `mevnode`. - [x] 18. Install `Postgres` and `Redis` on `mevnode`. -- [ ] 19. Prepare a minimal canary namespace for trade on `mevnode`. -- [ ] 20. Bring up `Hasura`, API, and frontend on `mevnode`. -- [ ] 21. Migrate publishers and ingest only after storage and Redis validation pass. -- [ ] 22. Validate host health, agave health, trade health, and end-to-end flow after rollout. -- [ ] 23. Keep `mevnode_bot` as a rollback target until the new stack is stable. +- [x] 19. Bootstrap an organization-scoped Gitea Actions runner on `mevnode`. +- [ ] 20. Prepare a minimal canary namespace for trade on `mevnode`. +- [ ] 21. Bring up `Hasura`, API, and frontend on `mevnode`. +- [ ] 22. Migrate publishers and ingest only after storage and Redis validation pass. +- [ ] 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.