oskar/homelab-codex-ws
1
0
Fork 0
Code Issues Pull requests Actions Packages Projects Releases Wiki Activity
homelab-codex-ws/docs/sessions/2026-06-22-kb-postgres-piha.md
oskar c0ffb6abf7 docs(kb): sesja 2026-06-22 — spine relokowany na PIHA + przygotowanie hosta 
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-25 18:52:35 +02:00

3.6 KiB
Raw Blame History

Sesja 2026-06-22 — KB spine relokowany na PIHA + przygotowanie hosta

Cel

Przenieść spine KB (Postgres + pgvector) z SOLARIA na PIHA, przygotować host PIHA pod kontener z twardym limitem pamięci, zdeployować i zweryfikować schemat. SOLARIA bywa offline — zapytania KB muszą działać 24/7, więc spine musi stać na always-on maszynie.

DECYZJA

  • Spine Postgres + pgvector przeniesiony SOLARIA → PIHA. Powód: PIHA (Raspberry Pi 5) jest always-on, SOLARIA bywa offline; zapytania KB mają działać 24/7. SOLARIA zostaje do GPU/embeddingów (bge-m3) i indexera.
  • Archiwum maili .eml docelowo też na PIHA (NVMe).

PIHA — przygotowanie hosta

  • Swap: dodano 4GB swapfile (/swapfile), utrwalony w /etc/fstab. Brak swapa był ryzykiem OOM dla Home Assistant.
  • Cgroup memory: kernel nie eksponował cgroup memory controllera → dopisano cgroup_enable=memory cgroup_memory=1 do /boot/firmware/cmdline.txt (backup: cmdline.txt.bak) + reboot. Po reboocie cgroup.controllers zawiera memory, docker mem_limit faktycznie działa (wcześniej był ignorowany).

Relokacja w git

Praca w worktree task/kb-postgres-piha, zmergowana do master jako commit 2b3cb89.

  • Override SOLARIA (hosts/solaria/runtime/kb-postgres/) usunięty; wpis z hosts/solaria/services.yaml zdjęty.
  • Dodany hosts/piha/runtime/kb-postgres/docker-compose.override.yml:
    • mem_limit: 1g, mem_reservation: 512m (soft reservation ignorowany przez kernel — nieszkodliwe; twardy mem_limit chroni HA przed OOM).
    • Tuning Postgresa pod małą maszynę: shared_buffers 256MB, effective_cache_size 512MB, work_mem 8MB, maintenance_work_mem 64MB, max_connections 30.
  • Obraz pgvector/pgvector:pg16 potwierdzony arm64.
  • Named volume kb_postgres_data na NVMe (docker data-root = /home/docker → /dev/nvme0n1p3, ~170GB wolne).
  • inventory/topology.yaml + hosts/piha/services.yaml — wpisy przeniesione.

Deploy na PIHA

  • Kontener healthy.
  • Schemat envelope + extension vector zweryfikowane w działającej bazie.
  • mem_limit 1g zaaplikowany po force-recreate (zwykły up nie podmienia limitu).

Google Takeout (bulk Gmail)

  • Pobrany: 15GB zip, jeden plik; Mail po rozpakowaniu ~26.9GB.
  • Leży na SOLARIA ~/Downloads, NIE rozpakowany jeszcze.
  • Docelowo: transfer na PIHA NVMe → import. Czeka na importer (etap 3).

Higiena git

  • Cała praca przez worktree: task/kb-foundations (zmergowany i sprzątnięty), task/kb-postgres-piha (zmergowany).
  • Master deploy-only, czysty.

GOTCHA PIHA (do zapamiętania)

~/.ssh/id_rsa na PIHA miał perms 0640 → git fetch przez SSH padał (bad permissions). Fix: chmod 600 ~/.ssh/id_rsa. To ta sama klasa problemów uid/permisji co wcześniej na PIHA — przy onboardingu PIHA warto sprawdzać perms kluczy.

Następny krok

Importer bulk Gmail (worktree task/kb-gmail-import):

  • CLI w packages/kb-mail, mbox → archiwum (.eml) + envelope, idempotentny, --dsn na PIHA.
  • Potem: transfer Takeout na PIHA NVMe + run.

BACKLOG (osobno, nieruszane w tej sesji)

  • hosts/piha/capabilities.yaml rozjazd danych: mówi memory 4GB / sd-card 32GB; realnie 8GB RAM + NVMe 170GB. Ten sam typ rozjazdu danych co przy 8-dniowej ślepocie floty — do poprawienia.
  • KB_TEST_DSN w packages/kb-mail/tests/test_db.py — wskazuje na solaria, powinien piha.
  • Deklaratywny zapis cgroup_enable + swap dla PIHA — firmware/host config jest poza obecnym GitOps; rozważyć jak go ująć.