fix: retry LLM template model pulls#68
Merged
Merged
Conversation
First boot can race device network setup. If Ollama gives up after one failed pull, Open WebUI remains reachable but never gets a model until a user knows to pull it manually. Retrying keeps the app self-healing when DNS or internet connectivity appears after the containers start, while making the waiting state visible in the service logs. Co-Authored-By: ChatGPT <noreply@openai.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
The LLM template starts two services: Ollama and Open WebUI. Open WebUI can be healthy before the configured model exists, because the Ollama container downloads the model in a background task after the API starts. That is useful for large models because the UI comes up quickly, but it creates a bad failure mode when the device is not online yet.
We hit that during validation: Ollama started, Open WebUI was reachable, but the first automatic pull failed because DNS/network was not available. The background task exited after that one failure. From the user's point of view the app looked alive, but Open WebUI showed an empty model picker forever. Nothing in the UI made it clear that the app had already given up, and the only way forward was to know enough to manually call Ollama's pull API.
That is the wrong behavior for an edge device first boot. Network readiness can lag app startup, especially when the device is being configured over USB, Wi-Fi is being connected after deployment, or DNS briefly fails. The template should be self-healing in that situation: keep the server available, keep trying the configured model, and make the waiting/retry state visible in the service logs.
This keeps the design simple. It does not add a custom status UI or block Open WebUI behind a large download. It only makes the existing first-run puller persistent instead of one-shot, with clear log messages telling the user that the model picker may stay empty until the download succeeds.
Tests
bash -n python/llm/ollama/entrypoint.shregistry.ollama.aiDNS failed, leaving Open WebUI up with no model. With this change, that failure path logs the problem and retries with capped backoff instead of permanently giving up.