cockroach 2.0.0 — deploy into an existing GVC

[jacobecox]

Review diff: git diff 4a83634..HEAD -- cockroach/versions/2.0.0/
(4a83634 is the verbatim cp -R of 1.5.0; everything real is in the three commits after it.)

Why a major version

The chart no longer creates a GVC — it deploys into the user's existing one. The upgrade across that boundary is destructive: a chart that stops declaring a GVC makes helm upgrade prune it, taking every workload, volumeset and identity inside.

2.0.0 ships a render-time fail on the legacy gvc key. Tested against a live 1.5.0 release in its own chart-created GVC: the in-place upgrade with the old values file was refused at render (identity.yaml:2:4), the release stayed at revision 1, and the GVC, workloads, volumeset and identity all still existed afterwards.

The three-layer defence passed with both arms of each. Both previously-unproven assumptions are now measured: CPLN_GVC is present in the PgBouncer container under inheritEnv: false (backend list correctly formed — 3 hosts single-location, 9 multi-location), and the boot GVC read returns 200 with only the new scoped targetKind: gvc policy.

Three pre-existing defects found while testing

1. The documented restore could not work. backup.sh runs BACKUP INTO with no target — a full-cluster backup — and 1.x told users to restore with a bare RESTORE FROM LATEST IN. CockroachDB refuses a full-cluster restore onto a cluster that already has user databases, and this template always creates mydb/myuser. Reproduced on a real cloud backup:

ERROR: full cluster restore can only be run on a cluster with no tables or databases
but found 5 descriptors: mydb, public, t_direct, t_app, backup_probe

Both documented paths now restore real rows end to end — from S3 (500 / 3 / 1, md5 payloads intact) and from GCS (120). New caveat documented: the full-cluster path returns ERROR: … node liveness error: restarting in background and bounces a node for ~2 min while nevertheless succeeding, which reads as failure.

2. SURVIVE REGION FAILURE failed silently — bare under set -e in a backgrounded subshell, printing neither an error nor a completion line while the install reported success, leaving the database at the default zone survival goal. Now verified on 9 nodes across 3 regions: SHOW SURVIVAL GOAL → region, and stopping all three aws-us-east-2 replicas produced zero failed reads or writes across a 2-minute region outage — with a control (two regions down) producing real unavailability, so the probe discriminates.

3. replicas: 0 silently suspended a location that still counted as a region no node ever joined. Refused at render, alongside 8 other negatives and a positive control.

Two more found in round 1, fixed on maintainer ruling

internal_access.type: workload-list denied the nodes each other when PgBouncer is off. The self-inclusion existed only in the pgbouncer.enabled branch. Measured: node status → 2,false,false / 3,false,false while every replica reported ready: true. Fourth instance of this class in one batch (etcd-multi-location, clickhouse, pgedge, cockroach).

Re-tested with an enforcement control that isolates the firewall as the only variable — identical containers, identical psql, identical host, only the list differs. Listed client: INSERT 0 1 then 3 rows. Unlisted: rc=2 on 5/5 attempts with real connection timeouts. node status from each of the three replicas → 1,true,true / 2,true,true / 3,true,true.

A one-node deployment could never start. Each node builds its --join list from every replica except itself, so a single node gets an empty list: ERROR: invalid argument "" for "-j, --join" flag, exit 4, permanent crash loop. validateReplicas ("must have at least 1 replica") actively read as endorsing it. Now refused at render; the smallest supported shape (3 in one location) forms in 119 s and recovers to 3/3 after three rolling restarts.

multiZone: true wedges silently in some locations — isolated by three controlled probes to stateful + block volumeset in aws-us-west-2; the same location is fine for standard workloads and volume-less stateful ones, and east-1/east-2 are unaffected. Per maintainer ruling this is a platform limitation, so the knob stays and the user is told to confirm their locations support multi-zone first (values.yaml, README Configuration, Important Notes, briefing).

Testing

29 PASS · 0 FAIL across two rounds. Drift gate clean — both no-op upgrades fully Unchanged, stored specs byte-identical. The rendered-vs-stored ordering difference in inboundAllowWorkload (chart renders self-first, API stores sorted) causes no churn, matching etcd and clickhouse.

Two platform findings recorded in CLAUDE.md: a firewall change took 559 s here (new high-water mark — and 286 s for the same knob in the same location next round, so propagation is not location-attributable), and cpln gvc update --set locationLinks+=… prints success while applying nothing.

One open question, non-blocking

A two-node deployment still renders — the new guard fires only on a total of exactly 1, matching the ruling as given. Two nodes start but lose quorum if either dies, so the floor arguably belongs at 3 (CockroachDB's default replication factor). One line to change if you want it.

Briefing updated in the same PR.

🤖 Generated with Claude Code