homelab-gitops/apps/minecraft-paper/CUTOVER.md

Paper cutover and rollback

Current safety gate: server.enabled=false and dynmap.route.enabled=false. The byobu process remains the sole writer of /home/feedc0de/mcserver and the old host PostgreSQL minecraft database. Paper chart Git tag v26.3-166 is published as chart 26.3.166-0, with that exact JAR baked into the matching image. The new PostgreSQL has a retained 8 GiB PVC and a preliminary dump; its Secret remains cluster-managed, not in this public repository.

After ATM10 has been cut over and checked:

1. Ask the operator to type stop in the Paper console. Confirm Java has exited, port 25565 is free, and no old PostgreSQL plugin connections remain. Record world*/ file counts/sizes and take a final pg_dump -Fc of the host database. Keep the host database and previous dump untouched.
2. Check the kube context, new namespace, new PVC UID, and database pod before restoring the final dump only into paper-postgresql. Since the preliminary dump is present, restore with --clean --if-exists and --single-transaction. Confirm all nine table counts match the final dump.
3. Enable server.enabled, but leave dynmap.route.enabled=false. Commit and let Argo launch one pod on arschrock. The init container first copies each changed plugin config to .pre-kubernetes, then changes the three PostgreSQL hosts and Dynmap's bind address. Verify game port 25565, both direct arschrock addresses, dynamic LoadBalancer address, plugin database access, and the internal paper-dynmap Service.
4. In one GitOps change, enable the Paper chart's Dynmap route and remove the old default/mcmap route and its middleware/legacy Service definitions. Verify https://brunner.ninja/mcmap serves the new Dynmap before deleting the manually managed legacy EndpointSlice. Move the old source manifest under traefik/legacy-services/_deleted/. Dynmap needs no MikroTik forward.
5. Add and verify Grafana panels for player count, CPU, memory, network, and executing node after both services are healthy.

Rollback requires disabling the Kubernetes game Deployment and waiting for its pod to terminate before restarting byobu. If plugins wrote to the new database, export/reconcile those writes into the old database first; starting against the stale old database loses data. Restore the .pre-kubernetes configuration files only once the pod is stopped. Keep the new PVC and both database dumps for recovery.