Runway infra readiness for Artifact Registry remaining items

Summary

Tracks the remaining Runway side infrastructure work for Artifact Registry (https://gitlab.com/gitlab-org/ops/artifact-registry) production readiness.

Derived from the Initial Feature Readiness Assessmen, filtered to items owned by or gating by the Runway team.

Context

Artifact Registry is a new Go satellite service deployed on Runway GKE with PostgreSQL, Redis, and GCS. It is a Runway v2 workload(.runway/fairway.yaml generates the chart via Fairway, .runway/deployment.yaml is consumed by runwayctl).

Already done items from Runway's side

Remaining items

  1. Cells setup Tracked separately in here.
  2. Observability —> metrics, logs, dashboards
    • Validate metrics pipeline end-to-end: AR pod -> agent-otelcol -> Mimir. Confirm scrape configuration picks up the metrics Service that Fairway generates.
    • Validate logs pipeline end-to-end: AR stdout/stderr -> clickhouse -> Loki.
    • Build the AR service dashboard in runbooks under the standard Runway pattern using the already existing archetype(AR team can create the dashboard in a self-service way).
    • Verify dashboards are populated with real data from the AR staging deployment (not just rendered — actually receiving metrics/logs from live pods).
  3. Tracing Tracked in runway/team#962.
  4. Load testing and scalability Owned by the AR team. Runway can provide support only.
  5. CloudSQL Backup and restore validation
  6. Runway monitoring Runbooks already ship two archetypes that cover Runway managed CloudSQL / Memorystore, dashboards can be generated by the AR team in a self-service way.

Out of scope

  • K8s RBAC manifest — not needed for AR (Vault + ESO model in use).
  • PostgreSQL version compatibility testing — AR-team owned.
  • Regional GCS for data sovereignty — post-GA concern.
  • Circuit breaker for Redis JWT cache — blocked on auth redesign; likely LabKit concern, not Runway/Fairway.
Edited by Sahand Abbasi