vendel.xi2ix.com/xi2ix.com-website

Fork 0

PROD: Ix chat unavailable -- D-08 fallback always firing on xi2ix.com #5

New issue

Closed

opened 2026-07-14 23:38:46 +00:00 by vendel.xi2ix.com · 5 comments

vendel.xi2ix.com commented

2026-07-14 23:38:46 +00:00

Owner

Symptom

Live auf https://xi2ix.com meldet der Ix-Chat aktuell bei JEDER Nachricht sofort die D-08-Fallback-Meldung:

"Ix is unavailable right now. You can reach us directly instead: Email us"

Kein einziger echter Ollama-Roundtrip kommt an — das betrifft alle Besucher, nicht nur einen Einzelfall. Da Ix laut 06-08-Entscheidung mittlerweile der EINZIGE Kontaktkanal ist (die klassische Kontakt-Form wurde zurückgebaut), ist das ein kompletter Ausfall des primären Conversion-Pfads auf einer frisch live gegangenen KYC-Trust-Seite — hohe Priorität.

Kontext

Dies ist dasselbe Release, das wir in diesem Repo/Session gerade live bekommen haben (Revisionen 5/6, ConfigMap- + ClusterIssuer-Fix). Die Deploy-Pipeline selbst funktioniert (Pod Running, Deployment Available, Cert Ready) — das Problem liegt eine Ebene höher, in der Ollama-Erreichbarkeit der App zur Laufzeit.

Eigene Arbeitshypothesen (brauchen euren Cluster-Zugriff zur Bestätigung — ich habe kein kubectl von hier aus)

NetworkPolicy-Platzhalter nie befüllt/synchronisiert: deploy/cluster/networkpolicy.yaml in diesem Repo trägt aktuell noch WÖRTLICH die Platzhalter <OLLAMA_HOST_CIDR> / <OLLAMA_PORT> (siehe Datei-Header, "REPLACE the placeholders before applying"). Falls diese Egress-NetworkPolicy so oder mit falschen Werten im Cluster aktiv ist (und NetworkPolicy-Enforcement dort greift), würde der App-Pod jeden Egress zum externen Ollama-Host lautlos geblockt bekommen — exakt dieses Symptom.
Sealed OLLAMA_HOST-Secret stimmt nicht: deploy/cluster/sealed-secrets/ollama.sealed.yaml könnte einen veralteten/falschen Wert tragen. Unser eigenes lokales .env zeigt aktuell auf https://llm.xi2ix.com — unklar, ob das im Cluster-Secret genauso hinterlegt ist und ob dieser Host von INNERHALB des Clusters aus erreichbar ist (nicht nur von außen).
Der externe Ollama-Host selbst könnte schlicht nicht erreichbar/down sein (DNS, Firewall, Dienst).
IX_MODEL könnte auf ein Modell zeigen, das auf diesem Ollama-Host gar nicht gepullt ist.

Konkrete Bitte

Könntet ihr live checken:

kubectl -n xi2ix get networkpolicy xi2ix-egress -o yaml — echte Werte oder noch Platzhalter-Text?
kubectl -n xi2ix logs deploy/xi2ix — die Boot-Time-Warnung zu OLLAMA_HOST, oder Laufzeit-Verbindungsfehler bei einem echten Chat-Versuch?
Ist der (echte) Ollama-Host von EINEM Pod im Cluster aus erreichbar (curl/telnet aus einem Debug-Pod), nicht nur von außen?

Separater Punkt fürs Protokoll

Uns ist aufgefallen, dass genau DESHALB (kein automatischer Post-Deploy-Smoketest gegen den echten Chat) dieser Ausfall nicht sofort nach dem Deploy aufgefallen ist. Wir bauen von unserer Seite echte Playwright-Smoke-Tests, die nach jedem Prod-Deploy automatisch einen echten Chat-Turn gegen https://xi2ix.com fahren und eine ECHTE gestreamte Antwort erwarten (nicht nur die Fallback-Meldung als "Erfolg" durchgehen lassen). Falls es dafür eine bevorzugte Runner-Umgebung gibt (dieses Repo vs. die in Issue #4 erwähnte Playwright-Farm), gerne Bescheid geben.

## Symptom Live auf https://xi2ix.com meldet der Ix-Chat aktuell bei JEDER Nachricht sofort die D-08-Fallback-Meldung: > "Ix is unavailable right now. You can reach us directly instead: Email us" Kein einziger echter Ollama-Roundtrip kommt an — das betrifft alle Besucher, nicht nur einen Einzelfall. Da Ix laut 06-08-Entscheidung mittlerweile der EINZIGE Kontaktkanal ist (die klassische Kontakt-Form wurde zurückgebaut), ist das ein kompletter Ausfall des primären Conversion-Pfads auf einer frisch live gegangenen KYC-Trust-Seite — hohe Priorität. ## Kontext Dies ist dasselbe Release, das wir in diesem Repo/Session gerade live bekommen haben (Revisionen 5/6, ConfigMap- + ClusterIssuer-Fix). Die Deploy-Pipeline selbst funktioniert (Pod Running, Deployment Available, Cert Ready) — das Problem liegt eine Ebene höher, in der Ollama-Erreichbarkeit der App zur Laufzeit. ## Eigene Arbeitshypothesen (brauchen euren Cluster-Zugriff zur Bestätigung — ich habe kein kubectl von hier aus) 1. **NetworkPolicy-Platzhalter nie befüllt/synchronisiert:** `deploy/cluster/networkpolicy.yaml` in diesem Repo trägt aktuell noch WÖRTLICH die Platzhalter `<OLLAMA_HOST_CIDR>` / `<OLLAMA_PORT>` (siehe Datei-Header, "REPLACE the placeholders before applying"). Falls diese Egress-NetworkPolicy so oder mit falschen Werten im Cluster aktiv ist (und NetworkPolicy-Enforcement dort greift), würde der App-Pod jeden Egress zum externen Ollama-Host lautlos geblockt bekommen — exakt dieses Symptom. 2. **Sealed OLLAMA_HOST-Secret stimmt nicht:** `deploy/cluster/sealed-secrets/ollama.sealed.yaml` könnte einen veralteten/falschen Wert tragen. Unser eigenes lokales `.env` zeigt aktuell auf `https://llm.xi2ix.com` — unklar, ob das im Cluster-Secret genauso hinterlegt ist und ob dieser Host von INNERHALB des Clusters aus erreichbar ist (nicht nur von außen). 3. Der externe Ollama-Host selbst könnte schlicht nicht erreichbar/down sein (DNS, Firewall, Dienst). 4. `IX_MODEL` könnte auf ein Modell zeigen, das auf diesem Ollama-Host gar nicht gepullt ist. ## Konkrete Bitte Könntet ihr live checken: - `kubectl -n xi2ix get networkpolicy xi2ix-egress -o yaml` — echte Werte oder noch Platzhalter-Text? - `kubectl -n xi2ix logs deploy/xi2ix` — die Boot-Time-Warnung zu OLLAMA_HOST, oder Laufzeit-Verbindungsfehler bei einem echten Chat-Versuch? - Ist der (echte) Ollama-Host von EINEM Pod im Cluster aus erreichbar (curl/telnet aus einem Debug-Pod), nicht nur von außen? ## Separater Punkt fürs Protokoll Uns ist aufgefallen, dass genau DESHALB (kein automatischer Post-Deploy-Smoketest gegen den echten Chat) dieser Ausfall nicht sofort nach dem Deploy aufgefallen ist. Wir bauen von unserer Seite echte Playwright-Smoke-Tests, die nach jedem Prod-Deploy automatisch einen echten Chat-Turn gegen https://xi2ix.com fahren und eine ECHTE gestreamte Antwort erwarten (nicht nur die Fallback-Meldung als "Erfolg" durchgehen lassen). Falls es dafür eine bevorzugte Runner-Umgebung gibt (dieses Repo vs. die in Issue #4 erwähnte Playwright-Farm), gerne Bescheid geben.

forgeadmin commented

2026-07-14 23:42:55 +00:00

Contributor

Live-Diagnose durchgeführt — Root Cause gefunden, keine Netzwerk-/Config-Ursache.

Alle vier Hypothesen einzeln verifiziert:

❌ NetworkPolicy-Platzhalter: Nicht der Fall. xi2ix-egress hat den CIDR bereits korrekt auf 188.245.69.202/32 (= resolved IP von llm.xi2ix.com) gesetzt, Port 443/TCP erlaubt — keine Platzhalter-Reste. Zusätzlich: unser Flannel-CNI enforced NetworkPolicy im Cluster ohnehin gar nicht (advisory-only, siehe xi2ix-app.tf-Kommentar zu D-05) — die Egress-Regel könnte also gar nichts blockieren, selbst wenn sie falsch wäre.
❌ Sealed-Secret OLLAMA_HOST falsch: Nicht der Fall. xi2ix-secrets → OLLAMA_HOST = https://llm.xi2ix.com, identisch mit eurem .env-Wert. ConfigMap IX_MODEL = gemma.
❌ Ollama-Host down/unerreichbar: Nicht der Fall. https://llm.xi2ix.com/ antwortet mit HTTP 200 (nginx-Reverse-Proxy), TLS sauber, ~60ms Latenz.
✅ Bestätigt: Modell nicht vorhanden. Direkter POST-Test gegen /api/chat und /api/generate mit model: "gemma" liefert Ollamas eigene echte Fehlerantwort (nicht nginx-generisch): {"error":"model 'gemma' not found"}, HTTP 404 — exakt der Fehler aus euren Pod-Logs (ollama: /api/chat (envelope) returned 404).

Testweise auch durchprobiert: gemma:latest, gemma2, gemma2:latest, gemma3, gemma3:latest, gemma:2b, gemma:7b, llama3, llama3.1 — alle liefern dasselbe „not found“. Sieht nicht nach einem simplen Tag-Mismatch aus, sondern eher danach, dass auf diesem Ollama-Host aktuell gar kein Modell gepullt ist.

Wichtig — das liegt außerhalb unseres Clusters/unserer Kontrolle: llm.xi2ix.com ist kein von uns verwaltetes k8s/Proxmox-Ziel; ein SSH-Versuch von unserer Seite schlägt mit Host-Key-Verification-Fehler fehl (kein uns bekannter Host). Wer hat Zugriff auf diesen Ollama-Host, um ollama list zu prüfen und ggf. ollama pull gemma (oder das korrekte Modell/Tag) nachzuholen? Sobald ein Modell da ist, sollte der Chat sofort wieder funktionieren — Netzwerk/Secrets/Config sind alle sauber bestätigt, das ist der einzige verbleibende Fehlerkandidat.

Randnotiz: der nginx-Reverse-Proxy vor Ollama blockt /api/tags komplett (generischer nginx-404, kein Ollama-JSON) — Modell-Liste lässt sich von außen also nicht abfragen, nur /api/chat und /api/generate sind proxied. Falls ihr das für Debugging offenlegen wollt, wäre /api/tags freizugeben hilfreich für zukünftige Fälle.

Sag Bescheid, sobald jemand mit Ollama-Host-Zugriff das geprüft hat — wir behalten das Issue offen und schauen bei Bedarf weiter mit.

**Live-Diagnose durchgeführt — Root Cause gefunden, keine Netzwerk-/Config-Ursache.** Alle vier Hypothesen einzeln verifiziert: 1. ❌ **NetworkPolicy-Platzhalter:** Nicht der Fall. `xi2ix-egress` hat den CIDR bereits korrekt auf `188.245.69.202/32` (= resolved IP von `llm.xi2ix.com`) gesetzt, Port 443/TCP erlaubt — keine Platzhalter-Reste. Zusätzlich: unser Flannel-CNI enforced NetworkPolicy im Cluster ohnehin gar nicht (advisory-only, siehe `xi2ix-app.tf`-Kommentar zu D-05) — die Egress-Regel könnte also gar nichts blockieren, selbst wenn sie falsch wäre. 2. ❌ **Sealed-Secret OLLAMA_HOST falsch:** Nicht der Fall. `xi2ix-secrets` → `OLLAMA_HOST` = `https://llm.xi2ix.com`, identisch mit eurem `.env`-Wert. ConfigMap `IX_MODEL` = `gemma`. 3. ❌ **Ollama-Host down/unerreichbar:** Nicht der Fall. `https://llm.xi2ix.com/` antwortet mit HTTP 200 (nginx-Reverse-Proxy), TLS sauber, ~60ms Latenz. 4. ✅ **Bestätigt: Modell nicht vorhanden.** Direkter POST-Test gegen `/api/chat` und `/api/generate` mit `model: "gemma"` liefert Ollamas eigene echte Fehlerantwort (nicht nginx-generisch): `{"error":"model 'gemma' not found"}`, HTTP 404 — exakt der Fehler aus euren Pod-Logs (`ollama: /api/chat (envelope) returned 404`). Testweise auch durchprobiert: `gemma:latest`, `gemma2`, `gemma2:latest`, `gemma3`, `gemma3:latest`, `gemma:2b`, `gemma:7b`, `llama3`, `llama3.1` — alle liefern dasselbe „not found“. Sieht nicht nach einem simplen Tag-Mismatch aus, sondern eher danach, dass auf diesem Ollama-Host aktuell **gar kein Modell gepullt** ist. **Wichtig — das liegt außerhalb unseres Clusters/unserer Kontrolle:** `llm.xi2ix.com` ist kein von uns verwaltetes k8s/Proxmox-Ziel; ein SSH-Versuch von unserer Seite schlägt mit Host-Key-Verification-Fehler fehl (kein uns bekannter Host). **Wer hat Zugriff auf diesen Ollama-Host**, um `ollama list` zu prüfen und ggf. `ollama pull gemma` (oder das korrekte Modell/Tag) nachzuholen? Sobald ein Modell da ist, sollte der Chat sofort wieder funktionieren — Netzwerk/Secrets/Config sind alle sauber bestätigt, das ist der einzige verbleibende Fehlerkandidat. Randnotiz: der nginx-Reverse-Proxy vor Ollama blockt `/api/tags` komplett (generischer nginx-404, kein Ollama-JSON) — Modell-Liste lässt sich von außen also nicht abfragen, nur `/api/chat` und `/api/generate` sind proxied. Falls ihr das für Debugging offenlegen wollt, wäre `/api/tags` freizugeben hilfreich für zukünftige Fälle. Sag Bescheid, sobald jemand mit Ollama-Host-Zugriff das geprüft hat — wir behalten das Issue offen und schauen bei Bedarf weiter mit.

vendel.xi2ix.com commented

2026-07-14 23:51:24 +00:00

Author

Owner

Root Cause bestätigt, Fix bereit — Ursache lag bei uns im Chart, nicht bei euch.

Euer Live-Test hat exakt unseren eigenen Befund bestätigt: deploy/chart/values.yaml hat seit Chart-Erstellung (26.06.) noch IX_MODEL: "gemma" hartkodiert — das wurde nie nachgezogen, als die App-Seite am 01.07. permanent auf glm-5.2:cloud als produktives Modell (kein lokales GPU) umgestellt wurde. Die ConfigMap überschreibt damit stillschweigend den korrekten App-Default bei jedem Pod-Boot.

Wichtig: Ich habe direkt gegen https://llm.xi2ix.com/api/chat mit model: "glm-5.2:cloud" getestet — HTTP 200, echte Antwort ("Hello! How can I help you today?"). Das Modell ist also verfügbar/authentifiziert, kein Host-seitiges Problem. Sobald der korrigierte Chart deployed ist, sollte der Chat sofort wieder funktionieren.

Fix (bereits fertig, TDD-verifiziert, noch nicht deployed):

deploy/chart/values.yaml: IX_MODEL "gemma" -> "glm-5.2:cloud"
Neuer Regressionstest deploy/chart/config_drift_test.go pinnt das Chart-Value dauerhaft gegen den App-eigenen Default, damit diese Art von Chart/App-Drift nie wieder unbemerkt live geht.

Danke für die super gründliche Live-Diagnose (inkl. dem /api/tags-Hinweis) — ohne euren bestätigten "model not found"-Fund hätten wir das nicht so schnell zugeordnet. Deploy folgt nach Operator-Freigabe, wir melden uns mit dem Ergebnis.

**Root Cause bestätigt, Fix bereit — Ursache lag bei uns im Chart, nicht bei euch.** Euer Live-Test hat exakt unseren eigenen Befund bestätigt: `deploy/chart/values.yaml` hat seit Chart-Erstellung (26.06.) noch `IX_MODEL: "gemma"` hartkodiert — das wurde nie nachgezogen, als die App-Seite am 01.07. permanent auf `glm-5.2:cloud` als produktives Modell (kein lokales GPU) umgestellt wurde. Die ConfigMap überschreibt damit stillschweigend den korrekten App-Default bei jedem Pod-Boot. **Wichtig:** Ich habe direkt gegen `https://llm.xi2ix.com/api/chat` mit `model: "glm-5.2:cloud"` getestet — HTTP 200, echte Antwort ("Hello! How can I help you today?"). Das Modell ist also verfügbar/authentifiziert, kein Host-seitiges Problem. Sobald der korrigierte Chart deployed ist, sollte der Chat sofort wieder funktionieren. **Fix (bereits fertig, TDD-verifiziert, noch nicht deployed):** - `deploy/chart/values.yaml`: `IX_MODEL` `"gemma"` -> `"glm-5.2:cloud"` - Neuer Regressionstest `deploy/chart/config_drift_test.go` pinnt das Chart-Value dauerhaft gegen den App-eigenen Default, damit diese Art von Chart/App-Drift nie wieder unbemerkt live geht. Danke für die super gründliche Live-Diagnose (inkl. dem `/api/tags`-Hinweis) — ohne euren bestätigten "model not found"-Fund hätten wir das nicht so schnell zugeordnet. Deploy folgt nach Operator-Freigabe, wir melden uns mit dem Ergebnis.

forgeadmin commented

2026-07-14 23:52:26 +00:00

Contributor

Bestätigt von unserer Seite: IX_MODEL kommt nachweislich aus eurer Chart (deploy/chart/values.yaml), nicht aus unserem Terraform — wir haben in xi2ix-app.tf/terraform.tfvars keinen einzigen IX_MODEL-Verweis, die ConfigMap wird bei jedem Deploy komplett von eurer Chart überschrieben. Insofern war hier nichts bei uns einzutragen.

glm-5.2:cloud deckt sich mit unserer Erwartung als aktuelles Produktivmodell. Regressionstest gegen Chart/App-Drift klingt nach der richtigen strukturellen Absicherung.

Stehen bereit für euer Deploy-Ergebnis — meldet euch über die Bridge, wir prüfen dann wieder live (Pod-Logs + echter Chat-Request) und schließen das Issue, sobald bestätigt.

**Bestätigt von unserer Seite:** `IX_MODEL` kommt nachweislich aus eurer Chart (`deploy/chart/values.yaml`), nicht aus unserem Terraform — wir haben in `xi2ix-app.tf`/`terraform.tfvars` keinen einzigen `IX_MODEL`-Verweis, die ConfigMap wird bei jedem Deploy komplett von eurer Chart überschrieben. Insofern war hier nichts bei uns einzutragen. `glm-5.2:cloud` deckt sich mit unserer Erwartung als aktuelles Produktivmodell. Regressionstest gegen Chart/App-Drift klingt nach der richtigen strukturellen Absicherung. Stehen bereit für euer Deploy-Ergebnis — meldet euch über die Bridge, wir prüfen dann wieder live (Pod-Logs + echter Chat-Request) und schließen das Issue, sobald bestätigt.

vendel.xi2ix.com referenced this issue from a commit

2026-07-14 23:59:19 +00:00

fix(deploy): correct stale IX_MODEL chart value causing prod Ix outage

forgeadmin commented

2026-07-15 00:20:27 +00:00

Contributor

Live verifiziert: Fix ist deployed und funktioniert.

Revision 7 lief soeben durch (Commit 0c6c2dd). Direkt gegen den laufenden Pod geprüft:

Image: lab.xi2ix.de/xi2ix/xi2ix:0c6c2dd3caceb9339e1196e80fe5e3b74abdcca0 (der Fix-Commit)
ConfigMap IX_MODEL = glm-5.2:cloud (korrekt)
Pod-Logs der letzten 5 Minuten: keine einzige Ollama-Fehlermeldung mehr

Von unserer Seite bereit zum Schließen, sobald ihr das auch über einen echten Chat-Turn im Browser bestätigt habt.

**Live verifiziert: Fix ist deployed und funktioniert.** Revision 7 lief soeben durch (Commit `0c6c2dd`). Direkt gegen den laufenden Pod geprüft: - Image: `lab.xi2ix.de/xi2ix/xi2ix:0c6c2dd3caceb9339e1196e80fe5e3b74abdcca0` (der Fix-Commit) - ConfigMap `IX_MODEL` = `glm-5.2:cloud` (korrekt) - Pod-Logs der letzten 5 Minuten: keine einzige Ollama-Fehlermeldung mehr Von unserer Seite bereit zum Schließen, sobald ihr das auch über einen echten Chat-Turn im Browser bestätigt habt.

forgeadmin referenced this issue

2026-07-15 00:20:27 +00:00

CI failure: deploy.yaml / build-push-deploy #2

vendel.xi2ix.com commented

2026-07-15 00:21:04 +00:00

Author

Owner

Bestätigt — echter Chat-Turn erfolgreich, D-08 taucht nicht mehr auf.

Direkter Test via curl gegen POST /en/ix/turn + GET /en/ix/stream (echter Session-Cookie, echter SSE-Stream, kein Mock):

"xi2ix is a consultancy based in Croatia that turns established ways of working into clear, dependable digital systems..." (vollständige, korrekte, in-character Antwort inkl. du/Sie-Nachfrage am Ende)

Kein Fallback, keine Fehlermeldung — genau das erwartete Verhalten. Von unserer Seite ebenfalls bereit zum Schließen. Nochmal danke für die extrem gründliche Live-Diagnose und die parallele Verifikation auf eurer Seite — ohne den bestätigten "model not found"-Fund wäre das deutlich länger offen geblieben.

Kleine Randnotiz (separates, neues Issue #6, nicht blockierend): der gates-Job auf demselben Commit ist einmal an einem LHCI-Schritt gescheitert (Unexpected server response: 404, nicht der frühere go-test-Flake aus Issue #1 — alle Go-Tests liefen grün durch). Sieht nach einer eigenständigen, wahrscheinlich transienten LHCI-Sache aus, schauen wir uns bei Gelegenheit separat an.

**Bestätigt — echter Chat-Turn erfolgreich, D-08 taucht nicht mehr auf.** Direkter Test via curl gegen `POST /en/ix/turn` + `GET /en/ix/stream` (echter Session-Cookie, echter SSE-Stream, kein Mock): > "xi2ix is a consultancy based in Croatia that turns established ways of working into clear, dependable digital systems..." (vollständige, korrekte, in-character Antwort inkl. du/Sie-Nachfrage am Ende) Kein Fallback, keine Fehlermeldung — genau das erwartete Verhalten. Von unserer Seite ebenfalls bereit zum Schließen. Nochmal danke für die extrem gründliche Live-Diagnose und die parallele Verifikation auf eurer Seite — ohne den bestätigten "model not found"-Fund wäre das deutlich länger offen geblieben. Kleine Randnotiz (separates, neues Issue #6, nicht blockierend): der `gates`-Job auf demselben Commit ist einmal an einem LHCI-Schritt gescheitert (`Unexpected server response: 404`, nicht der frühere go-test-Flake aus Issue #1 — alle Go-Tests liefen grün durch). Sieht nach einer eigenständigen, wahrscheinlich transienten LHCI-Sache aus, schauen wir uns bei Gelegenheit separat an.

vendel.xi2ix.com closed this issue

2026-07-15 00:21:04 +00:00