Thore CimbalandClaude Fable 5
0f3f155bc5
- README: Repo-Topologie-Abschnitt (git.lab = Quelle der Wahrheit, nie direkt zu Gitea pushen); Ausnahme Deploy-Uebergabe-Issues bleiben auf dem Gitea-Tracker (CFGMON erreicht git.lab nicht) - issue-migration: alle 4 Repos migriert (62 Issues), gitops-Nummernverschiebung dokumentiert, Cutover-Stand Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PKhFj1S3UdD6xL2fbWPeYj
132 lines
6.5 KiB
Markdown
132 lines
6.5 KiB
Markdown
# Backlogs
|
|
|
|
Zentrale Sammlung offener Punkte über alle Hosts und Dienste hinweg. Ein Eintrag
|
|
landet hier, wenn er bewusst nicht sofort erledigt wurde — damit er nicht in einer
|
|
Chat-Historie oder einem Kopf verschwindet.
|
|
|
|
## Repo-Topologie (seit 2026-08-01)
|
|
|
|
**Kanonisch lebt dieses Repo auf `git.lab`** (`axion1337.chat/Backlogs`, nur im
|
|
Lab bzw. via VPN erreichbar — das Lab ist die Quelle der Wahrheit).
|
|
`rohana.axion1337.de/sorb/Backlogs` ist ein **Push-Mirror**: git.lab überschreibt
|
|
ihn bei jedem Push per Force. Deshalb **nie direkt zu Gitea pushen** — solche
|
|
Commits gehen beim nächsten Mirror-Lauf verloren (Rettung: `.patch` von Gitea
|
|
ziehen + `git am`, siehe [Kanonisierung](verfahren/deploy-uebergabe.md)).
|
|
|
|
**Eine bewusste Ausnahme:** Die **Deploy-Übergabe-Issues** laufen weiter auf dem
|
|
Gitea-Mirror (dortiger Issue-Tracker), weil CFGMON und andere Hosts außerhalb
|
|
des Labs `git.lab` nicht erreichen — eine Übergabe muss aber von beiden Seiten
|
|
lesbar/kommentierbar sein.
|
|
|
|
## Aufbau
|
|
|
|
```
|
|
hosts/ ein File pro Host, benannt nach dem Hostnamen
|
|
shared/ Themen, die mehrere Hosts betreffen (DNS-Zone, Mail-Policy)
|
|
verfahren/ wiederkehrende Abläufe zwischen Personen und Hosts, plus AARs
|
|
```
|
|
|
|
Faustregel für die Einordnung: **Der Eintrag gehört dorthin, wo die Arbeit
|
|
stattfindet, nicht dorthin, wo das Symptom auftritt.** Ein down-Target in Prometheus
|
|
auf CFGMON, dessen Ursache ein blockierter Port auf dem Gameserver ist, gehört nach
|
|
`hosts/game.md` — mit Querverweis von CFGMON.
|
|
|
|
## Hosts
|
|
|
|
| Host | Adressen | Rolle | Backlog |
|
|
|---|---|---|---|
|
|
| **CFGMON** | `188.245.193.243`, `2a01:4f8:c17:93eb::1`, privat `10.0.0.3` | Monitoring-Stack, Gitea, Traefik | [hosts/cfgmon.md](hosts/cfgmon.md) |
|
|
| **game** | `157.90.155.206` (`game.axion1337.de`) | Pterodactyl / Gameserver | [hosts/game.md](hosts/game.md) |
|
|
| **matrix** | `49.13.132.245` (`matrix.axion1337.de`) | Matrix-Homeserver | [hosts/matrix.md](hosts/matrix.md) |
|
|
| **Overmind** | `10.58.73.17` (`git.lab`, **nur im Homelab auflösbar**) | GitLab + CI-Runner (Lab) | [hosts/overmind.md](hosts/overmind.md) |
|
|
|
|
## Übergreifend
|
|
|
|
| Thema | Backlog |
|
|
|---|---|
|
|
| DNS-Zone `axion1337.de` und Mail-Policy (IONOS) | [shared/zone-axion1337.md](shared/zone-axion1337.md) |
|
|
|
|
## Verfahren
|
|
|
|
`hosts/` und `shared/` halten **offene Punkte**, [verfahren/](verfahren/) hält
|
|
**wie wir arbeiten** — Abläufe, die zwischen Personen oder über mehrere Hosts
|
|
hinweg gelten und deshalb an kein einzelnes Projekt-Repo gehören.
|
|
|
|
| Verfahren | Inhalt |
|
|
|---|---|
|
|
| [Deploy-Übergabe](verfahren/deploy-uebergabe.md) | „einer baut, ein anderer rollt aus": Issue-Vorlage, Prüfliste, AAR |
|
|
|
|
Zur Deploy-Übergabe gehört die Issue-Vorlage
|
|
`.gitea/ISSUE_TEMPLATE/deploy-uebergabe.yaml` — sie erscheint beim Anlegen eines
|
|
Issues in diesem Repo als **Deploy-Übergabe**. Die Übergabe-Issues laufen auf dem
|
|
**Gitea-Mirror** (siehe Repo-Topologie oben: CFGMON erreicht git.lab nicht), weil
|
|
das Verfahren repo-übergreifend gilt; der fachliche Inhalt bleibt im jeweiligen
|
|
Projekt-Repo.
|
|
|
|
## Konventionen
|
|
|
|
**IDs** sind pro Datei fortlaufend mit einem Präfix, das den Ort benennt:
|
|
`CFGMON-01`, `GAME-01`, `MATRIX-01`, `ZONE-01` — ein Präfix pro Datei in `hosts/`
|
|
bzw. `shared/`, keine Liste losgelöst vom tatsächlichen Datei-Bestand. IDs werden
|
|
**nicht wiederverwendet** — ein erledigter Punkt behält seine Nummer, damit
|
|
Querverweise und Commit-Messages dauerhaft stimmen. Auch wenn eine ganze Datei
|
|
entfällt (siehe `hosts/k3s.md`, entfernt 2026-07-30), wird ihr Präfix nicht für
|
|
etwas anderes wiederverwendet.
|
|
|
|
Das Präfix für DNS-Themen ist bewusst `ZONE-` und nicht `DNS-`: `DNS-01` ist der
|
|
Name eines ACME-Challenge-Typs und käme in genau diesen Backlogs ständig als
|
|
Fachbegriff vor.
|
|
|
|
**Status:**
|
|
|
|
| Wert | Bedeutung |
|
|
|---|---|
|
|
| `offen` | noch nicht angefasst |
|
|
| `in Arbeit` | läuft gerade |
|
|
| `wartet auf …` | blockiert, mit Angabe worauf |
|
|
| `erledigt` | fertig, mit Datum — Eintrag bleibt stehen, siehe unten |
|
|
| `verworfen` | bewusst **nicht** umgesetzt, mit Datum und Begründung — nicht dasselbe wie `erledigt`: es ist nichts passiert, sondern es wurde entschieden, es zu lassen |
|
|
|
|
Erledigte **und** verworfene Punkte werden **nicht gelöscht**, sondern nach unten
|
|
in den Abschnitt „Erledigt" verschoben (verworfene Punkte darin klar als solche
|
|
kennzeichnen). Der Grund: bei mehreren Hosts ist die Frage „haben wir das damals
|
|
eigentlich gemacht, und warum so — oder haben wir es bewusst gelassen?" häufiger
|
|
als die Frage „was ist noch offen".
|
|
|
|
**Jeder Eintrag braucht** einen Status, eine Beschreibung des tatsächlichen
|
|
Zustands, und einen konkreten nächsten Schritt. Wenn eine Aussage nicht direkt
|
|
verifiziert ist (aus einer Konsole, einer Doku, einer Ableitung statt einer
|
|
Messung von dem betroffenen System selbst), wird kurz dazugeschrieben, woher sie
|
|
stammt — eine unbestätigte Vermutung, die wie ein Befund aussieht, kostet beim
|
|
nächsten Mal mehr Zeit als sie spart.
|
|
|
|
**Zeitkritisches** bekommt ein Datum in der Statuszeile, nicht nur „bald".
|
|
|
|
**Gegenstücke in anderen Host-Dateien** (z. B. ein Punkt, der von zwei Seiten
|
|
beschrieben wird, wie ein Push von `matrix` auf einen offenen Port bei `CFGMON`)
|
|
werden beim Schließen einer Seite **auf der anderen Seite mitaktualisiert**, nicht
|
|
nur verlinkt und stehen gelassen — sonst bleibt eine Seite unbemerkt veraltet.
|
|
|
|
## Verhältnis zu den Projekt-Repos
|
|
|
|
Dieses Repo hält die offenen Punkte. Die **Konfiguration** liegt weiter in den
|
|
jeweiligen Projekt-Repos, z. B. `sorb/threadnet-operating` für den
|
|
Monitoring-Stack auf CFGMON. Damit nichts doppelt geführt wird, verweisen die
|
|
Projekt-Repos hierher statt eigene Backlog-Dateien zu pflegen.
|
|
|
|
## Verhältnis zu Projekt-Issues
|
|
|
|
Die Projekt-Repos führen ihren eigenen Feature-/Fix-Backlog als Issues — **seit
|
|
2026-08-01 auf git.lab** (Migration per gitops#48, alte Gitea-Issues tragen einen
|
|
Verweis auf ihr GitLab-Gegenstück). Das bleibt dort, wird hier **nicht**
|
|
dupliziert. Faustregel für die Abgrenzung:
|
|
|
|
- **Reiner Projekt-Scope** (eine Funktion in einem Repo, ein Bug in einem Service):
|
|
Issue im jeweiligen Projekt auf git.lab, kein Eintrag hier.
|
|
- **Host-/Infrastruktur-Scope** (betrifft einen Host direkt, oder eine Entscheidung
|
|
über mehrere Hosts/Repos hinweg, z. B. wo ein CI-Runner laufen soll): Eintrag
|
|
hier, mit Verweis auf betroffene Issues statt deren Inhalt zu wiederholen.
|
|
- **Beides zugleich** (ein Host-Thema hat ein konkretes Gegenstück als Issue, z. B.
|
|
ein fehlender Gitea-Runner blockiert CI in mehreren Repos): kurzer Eintrag hier
|
|
mit Link zum führenden Issue, statt den Issue-Inhalt hierher zu kopieren.
|