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

feat(sol): add agave-backed dlob hot path for canary
Some checks failed
deploy-trade-r001-canary / apply (push) Failing after 5m41s
Details

Browse Source
This commit is contained in:
mpabi
2026-04-12 18:10:42 +02:00
parent 948c37c3f5
commit e1e993e2ac
26 changed files with 1110 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
environments/sol/trade-r001-canary/README.md
View File

@@ -7,7 +7,7 @@ Minimal canary namespace for migration baseline `R001` on `sol`.
- Reserve a dedicated namespace for the first reconstructed trade deployment.
- Put hard upper bounds on namespace-level CPU, memory, object count, and PVC growth before application manifests land.
- Verify that workloads in the namespace can resolve and reach the shared `trade-infra` services for `Postgres` and `Redis`.
- Recreate the `R001` application surface in a controlled way: `Hasura`, `trade-api`, `trade-frontend`, and the first canary `trade-ingestor` path.
- Recreate the `R001` application surface in a controlled way: `Hasura`, `trade-api`, `trade-frontend`, the first canary `trade-ingestor` path, and the first DLOB hot-path components.
## Current Guardrails
@@ -34,16 +34,21 @@ Minimal canary namespace for migration baseline `R001` on `sol`.
- Current shared infrastructure endpoints expected by canary workloads:
- `postgres-host.trade-infra.svc.cluster.local:5432`
- `redis-host.trade-infra.svc.cluster.local:6379`
- `agave-rpc-host.trade-infra.svc.cluster.local:8899`
- `agave-ws-host.trade-infra.svc.cluster.local:8900`
- `agave-grpc-host.trade-infra.svc.cluster.local:10000`
## Application Surface
- `postgres` in this namespace is an `ExternalName` alias that points to `postgres-host.trade-infra.svc.cluster.local`.
- `Hasura` uses the live `R001` secrets copied from `trade-staging`, but connects to the host `Postgres` on `sol`.
- `trade-api` and `trade-frontend` use the current live images from Gitea registry and the same bootstrap wrapper/config pattern as the source environment.
- `dlob-publisher-hot` now targets the host validator on `sol` through `trade-infra` services and writes `dlob-hot:*` into the shared Redis host service.
- `dlob-hot-redis-to-postgres-raw-writer` and `dlob-hot-postgres-to-postgres-derived-writer` rebuild the first live DLOB derived path on `sol`.
- The canary workflow re-runs:
- `postgres-migrate`
- `hasura-bootstrap`
before it waits for `Hasura`, `trade-api`, `trade-frontend`, and `trade-ingestor` to become healthy.
before it waits for `Hasura`, `trade-api`, `trade-frontend`, `trade-ingestor`, and the DLOB hot-path deployments to become healthy.
- The current canary `trade-ingestor` is intentionally pinned to the schema already reconstructed on `sol` and reads from `dlob_stats_latest`.
- The exact live `R001` ingestor path that reads `dlob_*_derived_latest` remains a follow-up substep after the DLOB writer chain is reconstructed.
@@ -52,8 +57,11 @@ Minimal canary namespace for migration baseline `R001` on `sol`.
From the repository root:
```bash
./environments/sol/trade-infra/scripts/prepare-sol-agave-access.sh
kubectl apply -k environments/sol/trade-infra
./environments/sol/trade-r001-canary/scripts/prepare-sol-postgres.sh
./environments/sol/trade-r001-canary/scripts/create-gitea-registry-secret.sh
./environments/sol/trade-r001-canary/scripts/create-trade-dlob-rpc-secret.sh
./environments/sol/trade-r001-canary/scripts/sync-live-secrets.sh
```