docs(migration): record gitea runner bootstrap on sol
This commit is contained in:
@@ -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.
|
||||||
|
|||||||
Reference in New Issue
Block a user