trade-next/trade-docs
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs(migration): record canary app surface rollout

Browse Source
This commit is contained in:
mpabi
2026-04-12 17:20:48 +02:00
parent 182edde414
commit e2c0a04293
1 changed files with 15 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

17
doc/migration-todo.md
View File

@@ -74,6 +74,8 @@ Date: `2026-04-12`
- 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. - 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.
- The first canary environment now exists in `trade-next/trade-gitops` under `environments/sol/trade-r001-canary`. - The first canary environment now exists in `trade-next/trade-gitops` under `environments/sol/trade-r001-canary`.
- Namespace `trade-r001-canary` is live on `sol` with initial quota and limit guardrails, and can reach the shared `Postgres` and `Redis` services in `trade-infra`. - Namespace `trade-r001-canary` is live on `sol` with initial quota and limit guardrails, and can reach the shared `Postgres` and `Redis` services in `trade-infra`.
- The first application surface for `R001` is now live in `trade-r001-canary`: `Hasura`, `trade-api`, and `trade-frontend`.
- The target host `Postgres` on `sol` now has `TimescaleDB` installed and a matching application database/user provisioned for `R001`.
## Migration Risks ## Migration Risks
@@ -295,6 +297,7 @@ Date: `2026-04-12`
- Done on `2026-04-12`: `Postgres` and `Redis` are running on `sol` as host services, bound to `127.0.0.1` and `149.50.96.162` for `k3s` pod access. - Done on `2026-04-12`: `Postgres` and `Redis` are running on `sol` as host services, bound to `127.0.0.1` and `149.50.96.162` for `k3s` pod access.
- 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`.
- Done on `2026-04-12`: installed `TimescaleDB 2.26.2` packages on host `Postgres` for `sol`, enabled `shared_preload_libraries=timescaledb`, and provisioned application role/database `admin/crypto` matching the live `trade-postgres` secret from `trade-staging`.
### 19. Bootstrap an organization-scoped Gitea Actions runner on `mevnode` ### 19. Bootstrap an organization-scoped Gitea Actions runner on `mevnode`
@@ -326,9 +329,19 @@ Date: `2026-04-12`
### 21. Bring up `Hasura`, API, and frontend on `mevnode` ### 21. Bring up `Hasura`, API, and frontend on `mevnode`
- Pending. - Done on `2026-04-12`.
- 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.
- Use `trade-next/trade-gitops` as the source of truth for the canary application surface, not ad-hoc manifests on the host.
- Keep the first application rollout internal to the cluster: `ClusterIP` services and health checks first, public ingress later.
- Reuse the live `R001` application images and live application secrets, but point them at the target host `Postgres` on `sol`.
- Done on `2026-04-12`: added `Hasura`, `trade-api`, and `trade-frontend` manifests to `trade-next/trade-gitops` under `environments/sol/trade-r001-canary`.
- Done on `2026-04-12`: added operator scripts to `trade-next/trade-gitops` for `sol` host preparation, `gitea-registry` secret creation, and live secret sync from `mevnode_bot/trade-staging` into `trade-r001-canary`.
- Done on `2026-04-12`: prepared `trade-r001-canary` secrets on `sol` for `trade-postgres`, `trade-hasura`, `trade-api`, `trade-frontend-tokens`, `trade-basic-auth`, and `gitea-registry`.
- Done on `2026-04-12`: ran `postgres-migrate` and `hasura-bootstrap` jobs successfully on `sol`.
- Done on `2026-04-12`: deployed `Hasura`, `trade-api`, and `trade-frontend` to `trade-r001-canary`; all three deployments reached `Available`.
- Done on `2026-04-12`: verified internal HTTP health checks `200` for `http://hasura:8080/healthz`, `http://trade-api:8787/healthz`, and `http://trade-frontend:8081/healthz`.
- Done on `2026-04-12`: verified GitOps execution through Gitea Actions; commit `6672e10` completed with status `success` for `deploy-trade-r001-canary / apply (push)`.
### 22. Migrate publishers and ingest only after storage and Redis validation pass ### 22. Migrate publishers and ingest only after storage and Redis validation pass
@@ -364,7 +377,7 @@ Date: `2026-04-12`
- [x] 18. Install `Postgres` and `Redis` on `mevnode`. - [x] 18. Install `Postgres` and `Redis` on `mevnode`.
- [x] 19. Bootstrap an organization-scoped Gitea Actions runner on `mevnode`. - [x] 19. Bootstrap an organization-scoped Gitea Actions runner on `mevnode`.
- [x] 20. Prepare a minimal canary namespace for trade on `mevnode`. - [x] 20. Prepare a minimal canary namespace for trade on `mevnode`.
- [ ] 21. Bring up `Hasura`, API, and frontend on `mevnode`. - [x] 21. Bring up `Hasura`, API, and frontend on `mevnode`.
- [ ] 22. Migrate publishers and ingest only after storage and Redis validation pass. - [ ] 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. - [ ] 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. - [ ] 24. Keep `mevnode_bot` as a rollback target until the new stack is stable.