Probing the real server (192.168.1.72:11434) after it was opened to the LAN:
/v1/models returns exactly one model, gemma4:e2b. Without pinning it the
bot would request the built-in default llama3.1:8b and every reply would
fail with "model not found", so set it explicitly on both bots.
Also raise CONJURER_AI_TIMEOUT_SECONDS to 240. Self-hosted generation is far
slower than a hosted API, particularly the first request after the model is
evicted from VRAM. It applies to every backend, so it is deliberately not
set higher than needed.
Caveat recorded honestly: at the time of writing, generation on that server
does not complete. /v1/models answers instantly, but both /v1/chat/
completions (180s) and native /api/generate with num_predict=5 (60s) return
nothing, and /api/ps shows no model ever becomes resident - so the model
never finishes loading. Ollama is 0.32.14 and gemma4:e2b is 5.1B Q4_K_M
(~3.5GB) despite the "e2b" name. That is a server-side problem, not a
configuration one; these values are correct and take effect once it loads.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Wires CONJURER_OLLAMA_URL into the test bot and the deploy bot so the
self-hosted backend from conjurer#25 is selectable. No API key exists for
Ollama - the endpoint is the whole configuration - and until it is set the
backend refuses to be selected, so this is what turns it on.
NOTE, verified from the LAN before committing: 192.168.1.72 answers ping
(0.4ms) but only port 22 is open - 11434 refuses. Ollama binds to
127.0.0.1:11434 by default, so it is not reachable off-host yet. This env
var is correct but inert until the server listens on the network:
sudo systemctl edit ollama.service
[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"
sudo systemctl daemon-reload && sudo systemctl restart ollama
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Pairs with conjurer#18: each bot advertises its own callback so the shared
librarian answers results/pongs back to the bot that asked - test bot
http://192.168.1.73:32442, deploy bot :32443. No CONJURER_MAIN_BOT
repointing needed for the librarian anymore; DEPLOY-BOT.md updated (only
the musician stays single-target).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Wyniki wyszukań (librarian) i eventy 'now playing' (musician) POST-owane do
bota ginęły, bo droga powrotna do bota była krucha:
* Service 'bot' był NodePort BEZ przypiętego nodePort -> k8s losował port z
30000-32767 przy każdym (od)tworzeniu Service, a musician/betoniarka z
Dockera adresują bota na sztywno http://192.168.1.73:32442. Rozjazd = każdy
POST leci w zamknięty port. Przypinam nodePort: 32442.
* Librarian jest w tym samym klastrze co bot, a mimo to szedł przez nodePort
węzła. Przełączam na DNS Service'u http://bot:5000 - odporne na
przetasowania nodePortu (nodePort zostaje tylko dla zewnętrznych z Dockera).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
gitea