oskar/homelab-codex-ws
1
0
Fork 0
Code Issues Pull requests Actions Packages Projects Releases Wiki Activity
homelab-codex-ws/kb/phases/kb-m3-ocr-worker.md
oskar 8beb28ac4c 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:53:57 +02:00

2.3 KiB
Raw Blame History

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

Modul 3 — Paperless OCR-worker (SOLARIA + fallback PIHA)

Ciezki OCR odseparowany od serwisu. Worker na SOLARIA (moc), fallback PIHA (wolno). Realizuje wzorzec "compute on-demand z fallback". Zalezy od: 2 (serwis+Redis dziala).

Cel

Przetwarzac OCR dokumentow (w tym batch 70k zalacznikow z maili) na mocy SOLARII, z gracefull fallback gdy SOLARIA offline — zadania czekaja w kolejce, nie gina.

Wymogi

  • Worker Paperless (ten sam obraz, tryb worker/consumer) na SOLARIA, podpiety do Redis@PIHA (broker z modulu 2) przez Tailscale.
  • services/paperless-worker/ — compose + service.yaml (owner_node=solaria).
  • Fallback: gdy SOLARIA offline -> zadania OCR czekaja w Redis (naturalne dla Celery/task queue). OPCJONALNIE: lekki worker na PIHA (male concurrency) domiela wolno, by nie blokowac w nieskonczonosc. Decyzja: kolejka-czeka vs slaby-worker-piha.
  • Worker na SOLARIA moze uzyc GPU/wielu rdzeni (PAPERLESS_TASK_WORKERS wyzsze niz na PIHA).
  • Batch 70k zalacznikow (modul 5 / faza-2) routowany przez ten worker — sizing/partie.

Do zweryfikowania przez CC

  • Czy Paperless-ngx wspiera oddzielny worker na innym hoscie dzielacy Redis+Postgres+ storage (WSPOLNY storage to wyzwanie — worker musi widziec te same pliki!). UWAGA: to kluczowe — OCR-worker potrzebuje dostepu do storage dokumentow. Opcje: (a) storage na PIHA montowany przez siec (NFS/sshfs) na SOLARIA — wolne/kruche, (b) worker wysyla wynik OCR z powrotem bez wspoldzielenia storage, (c) inny podzial. CC musi zweryfikowac architekture Paperless consumer/worker.
  • Jak Paperless dzieli prace: consumer (obserwuje folder) vs task-worker (OCR) — ktora czesc idzie na SOLARIA.
  • Latencja Tailscale PIHA<->SOLARIA dla Redis/Postgres (czy akceptowalna).
  • Co sie dzieje gdy worker@SOLARIA znika w polowie zadania (retry? lost?).

Kryteria ukonczenia

  • OCR wykonuje sie na SOLARIA gdy dostepna (weryfikowalne: obciazenie CPU tam, nie PIHA).
  • SOLARIA offline -> zadania czekaja / domielane wolno, ZERO utraty zadan.
  • SOLARIA wraca -> kolejka sie rozladowuje.
  • Batch-mode dla 70k zalacznikow przetestowany na probce.
  • W GitOps: services/paperless-worker/ + hosts/solaria/services.yaml + topology.