trade-gitops/environments/sol/trade-r001-canary/README.md

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:

./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.