[
https://issues.apache.org/jira/browse/CAMEL-24821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18117828#comment-18117828
]
Karol Krawczyk commented on CAMEL-24821:
----------------------------------------
I looked at this on current main (c953503dcbd0) and two of the three points
describe code that has since changed. Details, so the ticket can be narrowed to
what is still broken.
h3. 1. The volume
The container has mounted the host directory {{~/.camel-test/ollama}} on
{{/root/.ollama}} since commit 050af78ca32c (2026-05-16), in
{{OllamaLocalContainerInfraService}} lines 83-94. So a pulled model should
already survive a restart. If it was pulled again on every start, the bind most
likely failed rather than being absent: the block catches {{IOException}} and
continues with {{LOG.warn("Failed to create Ollama data directory, continuing
without bind mount")}}, which nobody sees at the default level. An unset
{{HOME}}, rootless podman or an SELinux label on the host directory all land
there. Which Camel version did you see the repeated pull on?
h3. 3. The pull is not asynchronous, but nothing ever checks it
{{initialize()}} calls {{container.execInContainer("ollama", "pull",
getModel())}}, which blocks until the process exits, and {{InfraRun}} invokes
{{initialize()}} before it writes the pid file. What is missing is any
verification:
* the {{ExecResult}} is discarded at both pull sites (lines 170 and 179), so
the exit code and stderr are lost. A pull that fails on no network, a bad model
name or a full disk is completely silent, and the service then reports the
instance as running with a model that does not exist.
* {{org.testcontainers.ollama.OllamaContainer}} (testcontainers-ollama 2.0.5)
sets no wait strategy at all - its constructor only asserts image
compatibility, adds the GPU modifier when the nvidia runtime is present, and
calls {{withExposedPorts(11434)}}. Readiness therefore falls through to the
default host-port wait, which is satisfied as soon as the server accepts a
connection.
So there is no point in the code where "the model is present and usable" is
asserted, which fits the "model not found" symptom better than a race with the
pull. I would fix that by checking the exit code and verifying the model
afterwards, for example against {{/api/tags}}.
h3. 2. Choosing the model
This one is real and cheap. {{LocalPropertyResolver}} reads
{{System.getProperty}} first and only then {{container.properties}}, so
{{-Dollama.model=qwen2.5:0.5b}} already works today - the CLI simply has no
front-end for it. The change is a {{System.setProperty}} next to the existing
{{--port}} handling in {{InfraRun}}, plus the regenerated command docs. The
precedent is {{--no-ui}} from CAMEL-24087 (commit 6843dcad5ac4).
One question before I write it: {{--model}} and {{--embedding-model}} are
ollama-specific options on a generic command. Would you rather have a generic
passthrough, say {{--property ollama.model=...}}, which would also cover the
GPU and memory knobs? I will follow whichever you prefer.
The Citrus side cannot be done here: there is no infra action in this
repository, only the documentation of the Citrus {{camel.infra.run}} action.
What Camel can offer it is the property contract above.
h3. What I propose to take
The exit code check plus the model verification, and the CLI option. I would
leave the volume as it is unless you can reproduce the repeated pull on main,
and file the pull progress separately: showing it crosses the reflective
classloader boundary in {{InfraRun}} and would need the {{followLog}} wiring
moved before {{initialize()}}, which affects every infra service, not just
ollama. Note testcontainers also offers
{{OllamaContainer.commitToImage(String)}} as a volume-free way to make the pull
a one-time cost, if the persistence question comes back.
_Reported by Claude Code on behalf of Karol Krawczyk_
> camel infra ollama: keep pulled models in a volume, add --model, and wait for
> the pull
> --------------------------------------------------------------------------------------
>
> Key: CAMEL-24821
> URL: https://issues.apache.org/jira/browse/CAMEL-24821
> Project: Camel
> Issue Type: Improvement
> Components: camel-jbang, camel-test-infra-ollama
> Reporter: Claus Ibsen
> Priority: Major
>
> Found while writing the langchain4j-chat example for camel-jbang-examples
> (CAMEL-24808).
> *camel infra run ollama* starts the Ollama container and pulls its default
> model (granite4:3b, 2.1 GB). Three things make it hard to use:
> # The container mounts no volume, so the model is pulled again on every
> start, and every Citrus test run that starts the service with the camel infra
> action downloads 2.1 GB. The compose file the example used before kept a
> named volume for exactly this reason.
> # The model is fixed to the ollama.model property of the service; neither
> *camel infra run ollama* nor the Citrus infra action can choose a smaller
> one. A tiny model (qwen2.5:0.5b at 400 MB, smollm2:135m under 300 MB) is
> enough for most tests and CI.
> # The pull is asynchronous: the service logs "Pulling the model granite4:3b"
> and prints its JSON about one second later, so a *camel run* that follows the
> README gets "model 'granite4:3b' not found" until the pull is done, with
> nothing telling the user why.
> Proposal: mount a named volume for /root/.ollama so a pull happens once per
> machine; add *--model* (and the embedding model) as an option of *camel infra
> run ollama* and as a service property the Citrus action can pass; wait for
> the pull before reporting the service as running, or at least print the pull
> progress and say it is still running.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
