72 lines
3.5 KiB
Markdown
72 lines
3.5 KiB
Markdown
# trade-r001-canary
|
|
|
|
Minimal canary namespace for migration baseline `R001` on `sol`.
|
|
|
|
## Purpose
|
|
|
|
- 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`, the first canary `trade-ingestor` path, and the first DLOB hot-path components.
|
|
|
|
## Current Guardrails
|
|
|
|
- Namespace: `trade-r001-canary`
|
|
- ResourceQuota:
|
|
- `requests.cpu=2`
|
|
- `limits.cpu=6`
|
|
- `requests.memory=4Gi`
|
|
- `limits.memory=12Gi`
|
|
- `pods=20`
|
|
- `services=10`
|
|
- `configmaps=20`
|
|
- `secrets=30`
|
|
- `persistentvolumeclaims=4`
|
|
- `requests.storage=100Gi`
|
|
- LimitRange:
|
|
- default request: `100m`, `128Mi`
|
|
- default limit: `1`, `1Gi`
|
|
- per-container maximum: `2`, `4Gi`
|
|
|
|
## Notes
|
|
|
|
- This namespace is intentionally conservative until item `14` and the validator protection envelope are fully defined.
|
|
- 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-publisher-all` now targets the same host validator path on `sol` and writes `dlob-all:*` 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`.
|
|
- `dlob-all-redis-to-postgres-derived-writer` rebuilds the live full-market derived DLOB path on `sol`.
|
|
- The canary workflow re-runs:
|
|
- `postgres-migrate`
|
|
- `hasura-bootstrap`
|
|
- `api-token-seed`
|
|
before it waits for `Hasura`, `trade-api`, `trade-frontend`, `trade-ingestor`, and the DLOB hot/all-path deployments to become healthy.
|
|
- The canary `trade-ingestor` now follows the live `R001` path on `sol`: it reads `dlob_hot_derived_latest` first for hot markets and falls back to `dlob_all_derived_latest`.
|
|
- `api-token-seed` restores the frontend read token in `api_tokens`, so `trade-api` and `trade-frontend` can be validated against the reconstructed derived tables after each deploy.
|
|
|
|
## Operator Flow
|
|
|
|
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
|
|
```
|
|
|
|
After the prerequisites are seeded, push to `main` and let `deploy-trade-r001-canary` apply the environment.
|