management/docs/issues/0028-mirror-01-ein-ausfall-der-push-mirrors-bleibt.md

type, id, status, created, milestone, priority, area, gitlab_iid, related

type	id	status	created	milestone	priority	area	gitlab_iid	related
issue	0028	done	2026-08-02	M2	low	infrastructure	28

MIRROR-01: Ein Ausfall der Push-Mirrors bleibt unbemerkt — Produktion friert still ein

Import aus management#28 (2026-08-11). Kommentare und Verlauf bleiben dort; kanonisch ist ab jetzt diese Datei (ADR-0012).

Der Push-Mirror ist der einzige Weg von git.lab in die Produktion: Flux zieht ausschließlich aus Gitea (ADR-0001). Fällt er aus, passiert nichts Lautes — Flux reconciled weiter den zuletzt gespiegelten Stand. Die Produktion wirkt gesund und ist eingefroren.

Kein Alarm, keine rote Pipeline, kein Log, das jemand liest. Auffallen würde es erst, wenn sich jemand wundert, warum ein Deploy „nicht ankommt".

Warum das jetzt zählt

Aus #15: Welches Credential in den Mirrors hinterlegt ist, ist nicht rekonstruierbar — die API maskiert es, keine Session hat es dokumentiert. Wir wissen also nicht, ob es ein Ablaufdatum hat. Läuft es ab, tritt genau der stille Fall oben ein.

Stand 2026-08-02 laufen alle geprüften Mirrors fehlerfrei (update_status: finished, last_error: —) — das ist eine Momentaufnahme, keine Zusicherung.

Was zu tun ist

Ein Check auf den Mirror-Status der sechs gespiegelten Repos der Gruppe axion1337.chat:

curl -sS -H "PRIVATE-TOKEN: $TOKEN" \
  "https://git.lab/api/v4/projects/<id>/remote_mirrors"
# relevant: .update_status != "finished"  oder  .last_error != null

Offen ist wo er läuft — beides ist vertretbar:

• Prometheus/Alertmanager auf CFGMON (threadnet-operating) — passt zum vorhandenen Alarmweg, braucht aber ein git.lab-Token auf CFGMON und den Tunnel.
• Scheduled CI-Job auf git.lab, wie canonize_rotation im gitops-Repo — läuft im Lab, kein zusätzliches Credential nach außen, meldet sich über eine rote Pipeline. Dafür merkt er nichts, wenn das Lab selbst aus ist (was aber gerade der Fall ist, in dem die Mirrors ohnehin nicht laufen).

Abgrenzung

Nicht Teil dieses Issues: die Rotation der Tokens selbst (#15) und die Frage, welches Credential dort hinterlegt ist. Hier geht es allein darum, einen Ausfall zu bemerken.

---

Gefunden beim Session-Abschluss 2026-08-02, beim Nachgehen der Randbedingung aus #15.

Erledigt 2026-08-15 — der Mechanismus existiert bereits und läuft

Vor dem Bauen geprüft, ob die Lücke noch besteht. Ergebnis: sie ist geschlossen, und zwar genau auf dem Weg, den dieses Issue als zweite Option nannte (Scheduled CI-Job auf git.lab, Alarm über eine rote Pipeline).

Baustein	Fundstelle	Zustand
Prüfung des Mirror-Status	scripts/stillstandspruefung.py — liest remote_mirrors je Projekt und meldet last_error als Befund; ein Repo ganz ohne aktiven Mirror ebenfalls	vorhanden
Ausführung	.gitlab-ci.yml, Job stillstandspruefung, rules: $CI_PIPELINE_SOURCE == "schedule"	vorhanden
Zeitplan	git.lab-Zeitplan „Stillstandsprüfung (täglich)", cron 42 0 * * *, aktiv, nächster Lauf geprüft	läuft
Alarm	Befunde färben die Pipeline rot — dieselbe Alarmanlage wie bei canonize_rotation	greift

Damit ist der befürchtete Fall abgedeckt: Läuft das Mirror-Credential ab, meldet die API last_error, der nächste tägliche Lauf macht daraus einen Befund und die Pipeline wird rot — statt dass die Produktion still auf dem letzten gespiegelten Stand einfriert. Der Weg ist binnen 24 h wirksam.

Praxisnachweis am selben Tag: Die Prüfung hat real angeschlagen — sie meldete für gameserver, notfallhandbuch und threadnet-wiki „kein aktiver Push-Mirror". Der Code-Pfad läuft also nicht nur theoretisch. (Bei den letzten beiden ist das Fehlen gewollt und begründet, ADR-0016 bzw. mirror: null in der Komponenten-Deklaration; gameserver ist #0032.)

Kleine bleibende Lücke, bewusst nicht gebaut: Geprüft wird last_error, nicht update_status != "finished". Ein Mirror, der ohne Fehlermeldung hängen bliebe, fiele durch — theoretisch möglich, praktisch bisher nie beobachtet. Eine Erweiterung wäre eine Zeile, sollte aber einen Anlass haben statt Vorratsbau.