Reverts the MODEL_CHOICES/MODEL_LABELS additions from 2609ab5. The .27 models are
gone from the family console, so the two dropdown entries would have been dead
options that error when selected (and they were offered to every user).
The list is back to exactly the original 10 cloud entries. Existing sessions that
still reference a removed id fall back to the default rather than erroring, since
the server validates the id against MODEL_CHOICES.
docs/dsh-architecture.md: drop the 'Local Ollama models' section, and add a warning
that auto/* are OmniRoute *routers* — when OmniRoute's pool is exhausted they fail
with 'Maximum combo retry limit reached' and DSH shows it as 'Model returned no
response', which is not a DSH bug.
Verified on .13: all four instances report 10 models with no ollama entries, and a
real streamed reply comes back through DSH on an explicit model.
The local 14B model is not usable from this machine (8.25 tok/s prompt
processing; pi sends a 9,510-token agent prompt against a 4,096 context, so it
was truncated to 2,050 and still needed ~4 min before the first token). Nothing
about the panel was worth keeping for it.
- portal/tools.py: drop the 'Ollama Local LLM' tile (no other references remain)
- services.toml: drop the ollama allowlist entry; 8 services remain
- service_controller.py + docs: keep the generic 'systemd-system' kind but drop
the ollama-specific wording and mark it as currently unused
Verified on .13: /api/services no longer lists ollama, the deployed tools.py has
0 ollama matches, the other 8 cards still report correctly, portal is healthy.
The dropdown is built from the hardcoded MODEL_CHOICES list in app.py, not from
OmniRoute, so 'ollama/qwen2.5*' existed upstream but could never appear in DSH.
- add ollama/qwen2.5:14b and ollama/qwen2.5-coder:14b to MODEL_CHOICES + MODEL_LABELS
- labels note that Ollama must be started first, since it now boots off on .27
- docs/dsh-architecture.md: new section on model selection, incl. the rebuild
requirement (app.py is baked into the image via COPY . .) and the ordering trap
that a model can be live in OmniRoute yet invisible in DSH
Verified: /api/models lists both ids on 3081-3084, and real streamed replies come
back from both local models through DSH.
The ollama card was wired to 'systemctl --user', but the .27 user unit was
removed when Ollama moved to services.ollama (NixOS system service). The panel
therefore reported Stopped while the service was Running and its buttons failed.
- new controller kind 'systemd-system' -> sudo -n <canonical systemctl> ...
- resolve systemctl to its store path first: NixOS puts a symlink on PATH but
the NOPASSWD sudoers rule names the store path, so bare 'sudo systemctl' does
not match (verified: full path exit=0, bare name 'a password is required')
- _remote() now shlex.join()s the remote command; ssh joins trailing argv with
spaces, which was word-splitting the 'sh -c' wrapper and failing with a sudo
usage error
- services.toml: ollama -> kind=systemd-system, target=ollama (matches the
sudoers rule verbatim), default_state=running
- docs/portal-architecture.md: document the three controller kinds + gotchas
Verified end-to-end from .13: start->running, stop->stopped, start->running,
real systemctl agrees, and /v1/models lists both qwen2.5 models over the LAN.
