Tenant-Board (Admin)

Status: live (2026-05-01). Erste echte Tenant-Migration End-to-End durchgelaufen (leander von shared-1 → shared-2). Auto-Provisioning neuer Shared-Hosts ueber Hetzner-API + cloud-init ebenfalls live.

Das Tenant-Board im Admin-Portal ist eine Kanban-Sicht aller Tenants über alle Server. Damit lassen sich Tenants zwischen Shared-Hosts verschieben (Live-Migration mit pg_dump + S3-Sync + Synapse-rsync).

Wozu das Ganze?

Bei wachsender Last sollen Tenants sich selbständig auf die Server verteilen können. Statt SSH-Sessions, manueller Datenmigration und nervösen Konfig-Edits genügt ein Drag-and-Drop.

Aufbau

Bereich	Inhalt
Spalten-Header	Server-Name, IP, Status (active/full/maintenance/offline), Tenant-Count + Auslastungs-Bar
Karten	Pro Tenant: Workspace-Name, Subdomain, Status-Punkt, User-Zähler, Synapse-Port
Pro-Upgrade-Spalte	Gold gestrichelt, am Ende. Tenant hierhin ziehen → Migration zu eigenem dedizierten Server (noch nicht verfügbar)

Erreichbar über Admin-Portal → Sidebar → Tenant-Board.

Drag-and-Drop-Migration

1. Karte mit der Maus auf eine andere Spalte ziehen
2. Bestätigungs-Dialog erscheint mit Downtime-Hinweis (30 s – 5 min)
3. Klick auf "Migration starten" → Backend orchestriert die Schritte:
   • preflight — Target-Host hat Kapazität? Source-Status?
   • freeze — Tenant-Schreibzugriff sperren (Tenant-Setting maintenance.frozen)
   • snapshot — pg_dump custom-format + MinIO mc mirror + Synapse-Daten als tar
   • transfer — rsync über Tailscale zum Target
   • restore — DB-User + DB anlegen, pg_restore, Bucket erstellen, Synapse starten
   • cutover — DNS via Bunny umstellen + ServerOrder.sharedHostId/Port aktualisieren + Source-Container stoppen
   • verify — Synapse /_matrix/client/versions Health-Check
   • cleanup — Tarball auf Target löschen, Freeze aufheben

Während der Migration zeigt ein Live-Progress-Panel unten rechts die Schritte mit Status-Punkten (running/success/error) und Step-Messages.

Bei Fehler

• Status wird auf failed gesetzt, Source bleibt unverändert (kein Rollback nötig — die alten Daten waren nie weg)
• Tenant wird automatisch entfrozen
• Error-Message bleibt im Panel sichtbar bis manuell geschlossen

Auto-Provisioning neuer Shared-Hosts

Auf der Seite Shared Hosts gibt es zwei Buttons:

• 🟦 Auto-provisionieren — Hetzner-API legt einen neuen Server an, cloud-init richtet alles ein (~10 Min). Auswahl per Modal:
  • Server-Typ: CCX13 (8 GB) / CCX23 (16 GB) / CCX33 (32 GB) / CCX43 (64 GB)
  • Location: FSN1, NBG1, HEL1, ASH
  • Max-Tenants: Default passt zur RAM-Groesse
• + Manuell anlegen — bestehenden Server registrieren (z.B. via prilog-infra/ops/scripts/setup/shared-host.sh aufgesetzt)

Der neue Host wechselt automatisch von provisioning auf active, sobald sein Agent sich beim Backend meldet. Wartende Shared-Tenants werden dann automatisch zugewiesen.

Loeschen leerer Hosts: Trash-Button auf der Karte (nur sichtbar wenn 0 Tenants — nach Hetzner-Server-Loeschung in der Hetzner-Konsole).

Voraussetzungen — werden bei Auto-Provisioning automatisch erfuellt

Damit die Migration-Engine zwischen zwei Hosts laeuft, muss auf jedem Host vorhanden sein:

Voraussetzung	Auto-Provisioning	Manuelles Setup
Postgres lokal (sudo -u postgres)	✓ cloud-init	✓ shared-host.sh
MinIO + mc alias 'local'	✓ cloud-init	✓ shared-host.sh
Cluster-SSH-Key in /root/.ssh/id_ed25519	✓ cloud-init	shared-host.sh, wenn CLUSTER_SSH_KEY env gesetzt
Wildcard-Cert via Bunny DNS-Challenge	✓ cloud-init	✓ shared-host.sh
prilog-agent installiert + WS-verbunden	✓ cloud-init	✓ shared-host.sh

Phase 3 (geplant)

• Pro-Upgrade (shared → dedicated) — derzeit per HTTP 501 abgelehnt. Erfordert Hetzner-VPS-Provisioning vorher.
• Auto-Balancing-Hinweise im UI — "Host bei 90% — verschiebe Tenant X"
• Migration-Historie mit Filterung nach Tenant, Datum, Erfolg/Fehler.
• Source-Cleanup-Cron — automatisch Daten auf altem Host nach 24h Sicherheitsfenster loeschen.