nxtgauge-gitops/clusters/production
sync-test d503a32de7
All checks were successful
sync-to-forgejo / sync (push) Successful in 10s
feat(ai): fix Ollama resource limits and bring LiteLLM under GitOps management
Phase 1 of the AI architecture doc ("Improve Generation Quality") —
qwen3:4b and qwen3:8b were already pulled onto the Ollama PVC, and
apps/litellm/base/configmap.yaml already had the correct model_list
mapping every feature alias to them instead of gemma3:270m. Neither
was actually in effect:

1. apps/litellm was never included in
   clusters/production/kustomization.yaml, so it was only ever
   deployed by a one-off manual `kubectl apply` and has been
   completely outside GitOps ever since (same root cause as the
   ai-guard registry drift found earlier). Added it to the root
   kustomization. Corrected its image reference from
   registry.nxtgauge.com/litellm:latest (doesn't appear to exist) to
   ghcr.io/berriai/litellm:latest, matching what's actually running
   live — adopting this file without that fix would have broken a
   working deployment the moment Flux started managing it.

2. apps/ollama/base/deployment.yaml's memory limit (1500Mi) was too
   small to ever load qwen3:4b (~2.5GB) or qwen3:8b (~5.2GB) — every
   model alias in the (also-never-applied) LiteLLM config was
   therefore unusable regardless of what it was named. Raised to
   4 CPU / 8Gi limit (node has 16GB total, was at ~26% memory use) and
   added OLLAMA_KEEP_ALIVE=30m so a loaded model survives the gaps
   between bursty feature requests instead of reloading from disk on
   every first call after 5+ minutes idle.
2026-07-21 06:30:13 +05:30
..
flux-system fix(flux): simplify ImageUpdateAutomation commit messages 2026-07-05 22:40:48 +00:00
kustomization.yaml feat(ai): fix Ollama resource limits and bring LiteLLM under GitOps management 2026-07-21 06:30:13 +05:30