oskar/homelab-codex-ws
1
0
Fork 0
Code Issues Pull requests Actions Packages Projects Releases Wiki Activity
homelab-codex-ws/kb/decisions/backlog-rozjazdy-repo-rzeczywistosc.md
oskar 89be9b9780 feat(kb): SPLIT backlog.md (72 KB) -> 19 dokumentow + cienki indeks 
Rozstrzygniecie 1. Monolit mieszal cztery typy OKF. Rozbity PER TYP po
granicy sekcji `##`:

  10 x decision  — pozycje backlogu (w tym backlog-aktywne 28 KB
                   i backlog-zamkniete 12 KB, ktore zostaja calosciami)
   7 x incident  — bugi/awarie dotad wtopione w backlog: cutover HA ken,
                   checkpoint observera, ha-diag-agent node=unknown,
                   deploy-local ghost-kontenery, paperless-worker config,
                   deploy-node nie przebudowuje obrazu, ollama bez sterownika
   2 x phase     — HA configs-as-code, monitoring floty Prometheus

kb/phases/backlog.md zostaje jako cienki indeks (type: phase, status: active):
oryginalna preambula + wygenerowany spis linkow do wszystkich 19 elementow.
23 przychodzace odwolania zostaja przepiete na ta sciezke w grupie 7.

NIE rozbijano po `###` (38 pozycji w "Aktywne" + 13 w "Zamkniete" = 51
plikow). Rozstrzygniecie mowi "rozbij per typ", a nie per pozycja;
rozdrobnienie do 51 plikow rozerwaloby czytelnosc backlogu.

Kontrola: preambula + 19 sekcji == oryginal z HEAD (multizbior niepustych
linii). Tresc pozycji nietknieta.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-04 16:58:46 +02:00

4.8 KiB
Raw Blame History

okf type visibility status updated links
0.1 decision private active 2026-08-03
../phases/backlog.md

Rozjazdy repo<->rzeczywistosc (z inwentaryzacji 2026-06-30)

Zrodlo: docs/infra/inventory-2026-06-30.md (23 rozjazdy, pelna tabela tam). Weryfikacja 2026-07-02: docs/infra/inventory-verify-2026-07-02.md — bilans: 20 wciaz aktualnych, 2 zmienione, 1 wyjasniony (storage SOLARIA = partycja Windows dual-boot, NIE rozjazd — zdjety z listy). Ponizej te wymagajace akcji, pogrupowane wg ryzyka. Naprawa = osobny task/kilka.

Grupa A — czyste docs, zero ryzyka

  • ✅ ZROBIONE (2026-07-02, commit 886bc85) — forgejo service.yaml owner_node: saturn -> piha (biega na PIHA always-on)
  • ✅ ZROBIONE (2026-07-02, commit 886bc85) — mosquitto service.yaml owner_node: piha -> vps (biega na VPS, nie na PIHA)
  • capabilities SATURN: RAM 8 -> 14GiB; dysk sd-card 64GB -> /dev/sda 159GB
  • capabilities SOLARIA: CPU 24 -> 32 nproc
  • hosts/saturn/services.yaml nie istnieje — 5 kontenerow bez deklaracji
  • hosts/vps/services.yaml niekompletne (4 z 9 z topology); solaria tez (brak planner-agent)

Grupa B — wymaga decyzji

  • npm x2: PIHA (LAN ingress :80/:443) + VPS (public). Repo zna jedna (owner=vps). Decyzja: zostawic oba (intentional, wildcard cert via NPM@PIHA) czy usunac PIHA? Jesli oba zamierzone -> dodac piha do service.yaml + hosts/piha.
  • ✅ ZROBIONE (2026-07-02) — control-plane na SATURN: docker compose down (wolumeny zachowane). Supervisor byl SLEPY (brak mountu repo, WARNING loop "Hosts directory /repo/hosts does not exist" co 30s) — zero ryzyka zdublowanych remediacji przez te 3 dni. Jedyny control-plane = produkcyjny na VPS.
  • ollama: service.yaml owner=solaria ale NIE biega. Wdrozyc czy wyrzucic z repo?

Grupa C — sprzatanie

  • control-plane-ui healthcheck: uzywa curl ktorego NIE MA w obrazie -> failuje w kolko -> UNHEALTHY + log spam (4.2G syslog na SATURN). Fix: wget/nc w healthcheck albo curl w Dockerfile. (Przyczyna rozjazdu #6 znaleziona przy gaszeniu dysku.)
  • homeassistant5 na PIHA (HA "ken" :8123) niedeklarowany -> dodac do hosts/piha + topology
  • VPS: outline-postgres-1 anonimowy image (4e6e670bb069) -> named tag; humanai-landing/mailer/umami do repo. joplin-db postgres:18 -> 17/16 (ocena zdezaktualizowana 2026-07-02: PG18 GA od 09/2025, nie pre-release — bez akcji)
  • PIHA: 33 shadow kontenery poza GitOps (immich, vaultwarden, wikijs, actual, audiobookshelf, elasticsearch, grafana, prom, portainer, code-server, diskover...) -> audyt + stopniowo do hosts/piha/services.yaml
  • zigbee2mqtt topology mowi chelsty-infra, biega na PIHA -> poprawic topology
  • stability-agent / node_exporter owner_node single, biegaja wielomiejscowo -> per-host

Followupy z weryfikacji + rozbrajania min (2026-07-02)

Zrodlo: docs/infra/inventory-verify-2026-07-02.md + sesja 2026-07-02. Zgloszone przy fixie owner_node (886bc85), swiadomie NIE ruszone — osobne decyzje.

  • forgejo brak wpisu w hosts/piha/services.yaml; mosquitto brak w hosts/vps/services.yaml — schemat hostowy wymaga role/exposure/depends_on (miny #2/#3/#16 z audytu).
  • mosquitto na VPS bez mem_limit override w hosts/vps/runtime/ — narusza konwencje CLAUDE.md (kazdy serwis VPS deklaruje mem_limit).
  • drugi mosquitto na chelsty-infra (offline'owa instancja) — pojedyncze owner_node jej nie opisuje; wzorzec per-host jak stability-agent / node_exporter (miny #17/#18).
  • topology.yaml:75: mosquitto zadeklarowany tez jako komponent ai-cluster — rozstrzygnac, czyj jest broker :1883.
  • pi-watchtower-1 na LUSTRO w restart-loopie (nowe z reconu; node-agent healthy).
  • alias lustro nie rezolwuje z SOLARII (nowe z reconu).
  • fleet-prometheus bez formalnego override mem_limit w hosts/vps/runtime/ — limit siedzi w bazowym compose (kosmetyka).

Po odchudzaniu PIHA (2026-07-02, faza 2 modulu 0)

  • llm-gateway: zlokalizowac/zarchiwizowac zrodlo — kod (wlasny FastAPI router -> Ollama@SOLARIA) moze zyc TYLKO w /opt/llm-gateway na PIHA, bez gita; przeszukanie PIHA i repo nie znalazlo innej kopii. Zarchiwizowac do repo/Forgejo zanim padnie nosnik.
  • Prometheus@PIHA: target llm-gateway blednie nazwany watchtower — celuje w :8080 i odpytuje /v1/metrics, dostaje wieczne 404 (llm-gateway nie serwuje metryk). Naprawic nazwe/endpoint albo usunac target.

Tech debt SATURN (z gaszenia dysku 2026-06-30)

  • /opt/anaconda3 16G — najwiekszy pojedynczy zjadacz dysku (env-y Pythona). Decyzja Oskara kiedy/czy czyscic.
  • Dysk 91% -> 83% ugaszone (docker prune + journal + syslog), ale /home zaszyfrowany i ciasny strukturalnie. SATURN dzwiga dev + drugi control-plane + agent-webui — napiecie.