tidb 2.0.0 — remove exposeServer, run db-init as a cron

[jacobecox]

Two maintainer rulings, applied in place on the shipped 2.0.0 (nothing is deployed on it). lastModified bumped; version untouched.

1. exposeServer removed

It opened public inbound on the server workload but rendered no loadBalancer.direct, so TCP 4000 was never published — the workload's only http port is TiDB's unauthenticated status/API port 10080, which is what the canonical endpoint would have served. All three archived test rounds recorded it as never tested.

Testing proved this closed a live exposure, not an absent listener. The workload still gets a canonical endpoint, and it now returns 403 RBAC: access denied on /status, /info, /settings, /schema and /. The positive control is what makes that meaningful: from inside the GVC the same port answers unauthenticated with {"connections":0,"version":"8.0.11-TiDB-v8.5.7",...}.

A values file still setting exposeServer now fails at render with an explanation — verified through cpln helm install, not just helm template, and it created nothing. Being silently ignorable is how this defect survived three rounds.

Removed rather than fixed: a proper fix needs a direct LB on 4000 plus a decision about exposing 10080, which deserves its own version.

2. db-init is now a cron, was standard

As a standard workload it completed, was restarted by the platform, completed again — reporting ready: false and Deployment does not have minimum availability permanently while the cluster was perfectly healthy (measured: 7 restarts, every one exitCode: 0, reason Completed).

Safe because the script is already idempotent: it fast-exits when the database exists, before reaching the non-idempotent CREATE USER.

Measured:

• Database created ~61 s after install — the next */5 tick, not the 5-minute worst case — and confirmed in the database itself (testappdb, user tidbtest), not from job status.
• Runs 2 and 3 took the fast-exit path in 191 ms and 317 ms, and Bootstrap complete matches exactly one line, on the run-1 replica only — proving CREATE USER was never re-reached.
• Status surface now reads ready: true, message: '', four successful executions, and zero occurrences of minimum availability.
• The retyped workload stored type: cron with the job block verbatim and no orphaned rolloutOptions.

autoCreateDatabase.schedule (default */5 * * * *) only controls how soon after install the database appears.

The honest trade-off: a cron re-runs on its schedule forever, so this is not "runs once and stops". What it fixes is that the standard workload also re-ran forever while reporting permanently unhealthy. Same repetition, native run-to-completion semantics, and controllable.

Testing

9 PASS · 0 FAIL. render-vs-stored 0 unexplained differences; drift gate fully Unchanged by the second upgrade.

The round also caught four documentation defects, all mine from the first commit — including Important Notes still asserting the exact behaviour this change removes, and the new bullet landing below ## Links. All four fixed in the second commit.

Two findings that outlive this template

Both make a teardown verification vacuous, which is the worst place for a false success because the cost is billing resources nobody knows are running. Both now in CLAUDE.md.

• cpln helm uninstall exited 0 having deleted nothing, printing ECONNABORTED — the release still read deployed with four workloads and two volumesets live. A retry worked. Trusting the exit code would have left a running TiDB cluster behind.
• cpln policy get silently truncates at 50 records, so an org-wide sweep for leftovers can come back clean while missing everything past the cap. --max 0 returns the full set.

Briefing updated.

🤖 Generated with Claude Code