## Context The Runway CloudSQL handover to the Database Excellence team ([runway/team#936](https://gitlab.com/gitlab-com/gl-infra/platform/runway/team/-/work_items/936)) includes the operational knowledge needed to run CloudSQL instances provisioned by Runway. One recurring need is connecting **DB Lab** (GCP project `gitlab-db-lab`) to Runway production CloudSQL databases so DB Lab can scrape production data. The first case is the Artifact Registry database, requested in [postgres-ai/collaboration-tracking#23](https://gitlab.com/gitlab-org/database-team/postgres-ai/collaboration-tracking/-/work_items/23): - CloudSQL instance: `runway-db-artifact-registry-gke` - GCP project: `gitlab-runway-production` - DB Lab host: `lab-ar-cloudsql-01-db-db-lab.c.gitlab-db-lab.internal` (created in [config-mgmt!15466](https://ops.gitlab.net/gitlab-com/gl-infra/config-mgmt/-/merge_requests/15466)) - Refresh mode: logical (`pg_dump` / `pg_restore`), because CloudSQL gives no filesystem or WAL-G access Runway CloudSQL instances are **PSC-only** (`ipv4_enabled = false`, `psc_enabled = true`) and `psc_allowed_consumer_projects` only allows `gitlab-runway-<env>`. The GKE VPCs have no private services access peering. As a result, `gitlab-db-lab` cannot reach these instances today. Peering `db-lab` with Runway's `gke-network` is intentionally avoided; instead, `gitlab-db-lab` gets its own PSC endpoint pointing at the instance's service attachment. ## Goal Write a runbook in the runbooks repo, under [`docs/runway/`](https://gitlab.com/gitlab-com/runbooks/-/tree/master/docs/runway), that documents the repeatable process for linking Runway production CloudSQL network services to the `gitlab-db-lab` GCP project. The runbook must define the MRs that are needed, in which repo, in what order, and how to verify each step. DB Lab can then be configured to scrape production data from Runway CloudSQL production databases. Proposed file: `docs/runway/cloudsql_dblab_access.md` (also link it from `docs/runway/README.md`). ## Proposed process and MRs to document {+ TBD +} ## Content the runbook should cover - [ ] Architecture overview: why PSC endpoint in `gitlab-db-lab` rather than VPC peering with Runway's `gke-network`. - [ ] Prerequisites and required access (Runway provisioner approvers, config-mgmt approvers, change management per the Production Engineering process). - [ ] Ordered MR checklist with links to the repos, the files to edit, and example MRs (provisioner!2068, config-mgmt!15864). - [ ] How to find the connection details: instance connection name, PSC service attachment, DNS name, Postgres version, private IP. - [ ] Security notes: connector enforcement stays `REQUIRED`, `ENCRYPTED_ONLY` SSL mode, least-privilege source user, and data masking decision for clones handed to developers. - [ ] Verification steps and rollback steps. - [ ] Applicability to other Runway CloudSQL instances, including how to onboard the next one, and a note on the differences for Cloud Run provisioned instances (to be confirmed). - [ ] Ownership: the runbook lives with DBE and is reviewed jointly with Runway during the co-ownership period. ## Acceptance criteria - [ ] New document exists in [`docs/runway/`](https://gitlab.com/gitlab-com/runbooks/-/tree/master/docs/runway) of the runbooks repo and is linked from `docs/runway/README.md`. - [ ] The document lists every MR (repo, change, order, approvers) needed to link a Runway production CloudSQL instance to `gitlab-db-lab`. - [ ] The Artifact Registry case ([provisioner!2068](https://gitlab.com/gitlab-com/gl-infra/platform/runway/provisioner/-/merge_requests/2068) and [config-mgmt!15864](https://ops.gitlab.net/gitlab-com/gl-infra/config-mgmt/-/merge_requests/15864)) is included as a worked example, updated once the MRs are merged and applied. - [ ] Verification and rollback steps are documented and have been tested at least once. - [ ] The document is reviewed by a Runway SME (@s.abbasi) and a DBE reviewer. ## Open questions - Is the same `psc_extra_consumer_projects` approach also needed for Cloud Run provisioned CloudSQL instances (scope of #936)? - Should the db-lab PSC endpoint code live in a reusable config-mgmt module so the next instance is a one-line change? - Does the Artifact Registry data need masking before clones are shared with developers? (collaboration-tracking#23) ## Related - Runway handover: [runway/team#936](https://gitlab.com/gitlab-com/gl-infra/platform/runway/team/-/work_items/936) - DB Lab request: [postgres-ai/collaboration-tracking#23](https://gitlab.com/gitlab-org/database-team/postgres-ai/collaboration-tracking/-/work_items/23) - Existing runbooks: [`docs/runway/cloudsql_backup_restore.md`](https://gitlab.com/gitlab-com/runbooks/-/blob/master/docs/runway/cloudsql_backup_restore.md), [dbo#771](https://gitlab.com/gitlab-com/gl-infra/data-access/dbo/dbo-issue-tracker/-/work_items/771)