oskar 510fe0b600 feat(kb): frontmatter OKF dla 39 session logow

Session logi zostaja w docs/sessions/ (decyzja z etapu 1). Dodany wylacznie
blok frontmattera: type: session-log, visibility: private, status: active,
updated = data ostatniego commita pliku.

Tresc nietknieta — kazdy plik to +9/-0 linii.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

2026-08-04 16:58:04 +02:00

3.7 KiB

Raw Blame History

okf

type

visibility

status

updated

links

0.1

session-log

private

active

2026-06-22

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ąć.

3.7 KiB Raw Blame History