homelab-codex-ws/kb/phases/kb-m0-piha-slim.md
oskar 0858e25c81 feat(kb): przenosiny type=phase do kb/phases/ (14 plikow, bez SPLIT)
Plany faz KB (modul 5 fazy 2/3/4/mailowa, moduly 0/2/3/4, documents-ingest,
raport fallback-dedup, eval retrieval-pilot) oraz prometheus-cutover-etap2,
subsystem-a-naprawa, okit-cloudflare.

git mv + frontmatter, tresc nietknieta.

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

2.6 KiB

okf type visibility status updated links
0.1 phase private active 2026-07-02

Modul 0 — Odchudzic PIHA (prerekwizyt filaru dokumentow)

Prerekwizyt modulow 2/4 (Paperless/Nextcloud na PIHA). Bez tego PIHA nie ma komfortowego zapasu RAM. Laczy sie z backlogiem grupy C (audyt shadow-kontenerow).

STATUS: prerekwizyt RAM SPELNIONY (2026-07-02)

Faza 1 (audyt read-only) + faza 2 (egzekucja po review Oskara) wykonane — szczegoly: docs/infra/piha-slim-audit-2026-07-02.md (sekcja "Korekta po review

  • egzekucja").
  • Kryterium >= 1.5Gi available: SPELNIONE. Przed egzekucja: 2.8Gi available (used 5.1Gi, swap 2.0Gi). Po ubiciu elasticsearch+diskover: 3.8Gi available (used 4.1Gi, swap 1.9Gi). Zapas ponad kryterium: +2.3Gi.
  • Ubite (jedyne dwa): elasticsearch (~895Mi) + diskover (~7Mi) — stack /home/pi/diskover, kontenery i siec usuniete, dane ES (bind mount esdata, 22MB) zostawione na dysku.
  • Decyzje po review: llm-gateway ZOSTAJE (wlasny kod Oskara, router LLM -> Ollama@SOLARIA, czesc systemu agentowego; zrodlo tylko w /opt/llm-gateway na PIHA — archiwizacja w backlogu); immich ZOSTAJE NA PIHA na stale (24/7, SOLARIA sesyjna); forgejo_dind / code-server / portainer / mqtt-exporter — zostaja.
  • Otwarte (nie blokuje Paperlessa): obserwacja stabilnosci swap pod normalnym obciazeniem; GitOps-yzacja tego co zostaje (hosts/piha/services.yaml) wg backlogu rozjazdow.

Cel

Zwolnic RAM na PIHA (dzis: 3.1Gi available, swap 2G uzyty) tak, by lekki Paperless- serwis wszedl z zapasem, nie na styku swap.

Wymogi

  • Audyt 33 shadow-kontenerow (lista w docs/infra/inventory-2026-06-30.md).
  • Zidentyfikowac kandydatow do usuniecia/przeniesienia/wylaczenia:
    • elasticsearch 1Gi — kto tego uzywa? (wikijs? diskover?) — jesli martwy, ubic
    • diskover — jednorazowy indekser? czy chodzi ciagle bez potrzeby?
    • duplikaty exporterow / stare agent-system-* kontenery
    • cokolwiek Up ale bez konsumenta
  • Cel: >= 1.5Gi available STABILNIE (bez swap pod presja) przed deployem Paperlessa.

Do zweryfikowania przez CC

  • Per shadow-kontener: kto go wola (docker network, zaleznosci, porty konsumowane)?
  • Czy usuniecie czegos nie zerwie dzialajacego serwisu (np. elasticsearch pod wikijs)?
  • docker stats przed/po — realny zysk RAM.

Kryteria ukonczenia

  • PIHA ma >= 1.5Gi available stabilnie, swap nie rosnie pod normalnym obciazeniem.
  • Usuniete/przeniesione kontenery udokumentowane (co, dlaczego, dokad).
  • Zmiany zgodne z GitOps (te ktore zostaja -> do hosts/piha/services.yaml).
  • NIE ubijac na slepo — kazdy kandydat zweryfikowany (kto uzywa) przed usunieciem.