[jira] [Commented] (CAMEL-24821) camel infra ollama: keep pulled models in a volume, add --model, and wait for the pull

["Karol Krawczyk (Jira)" <ji...@apache.org>]

    [ 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)