Mumble cutover and recovery
The published mumble chart owns the application and its optional Bitnami PostgreSQL subchart. This directory contains only cluster-specific values. The initial Argo sync used mumble.enabled=false to bring up an independent mumble-postgresql Service/StatefulSet/PVC while the legacy Mumble Deployment kept using the shared database. After a final dump/restore with Mumble stopped, mumble.enabled=true adopted the existing Service and Deployment. The old shared database and its PVC were not changed or removed.
The final dump is retained outside Git at /home/feedc0de/migration-backups/mumble-2026-10-19/final-cutover.dump on arschrock (mode 0600). All 14 Mumble table row counts matched after restore, including 33 users and 18 channels. The current default/mumble Deployment uses mumble-postgresql.default.svc.cluster.local. Its Recreate strategy avoids two server processes using the same database. If rollback is needed, freeze writes again and account for any writes made in the new database; blindly pointing Mumble back at the old copy would lose them.
default/mumble-secrets contains the application's database, SuperUser, and registry passwords. default/mumble-postgres is generated once by the source repository's guarded bootstrap helper: a random PostgreSQL administrator password plus the existing Mumble database password. Neither Secret is in this public repository. Preserve and back up these Secrets with the new PostgreSQL PVC. The certificate remains default/brunner-ninja-tls, managed separately by cert-manager. No Mumble PVC exists; durable Mumble state is in PostgreSQL.
The Service retains TCP/UDP port 64738 and the MikroTik operator annotations. Kubernetes/MetalLB should allocate the LoadBalancer address; the operator follows it. The old 192.168.0.14 pin is not a GitOps value. Do not delete the Service to change addressing. During a PostgreSQL restore, pause Argo auto-sync or scale the Mumble Application only with a recorded recovery plan, then resume once data is consistent.