[
https://issues.apache.org/jira/browse/CAMEL-24821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18123995#comment-18123995
]
Claus Ibsen commented on CAMEL-24821:
-------------------------------------
[~kkrawczyk] sorry it took so long to reply to your question.
Option B, please: a generic {{--property key=value}} on {{camel infra run}}
(repeatable), set as a system property next to the existing {{--port}}
handling, so {{camel infra run ollama --property ollama.model=qwen2.5:0.5b}}
works, and the same covers the embedding model, the GPU and memory settings and
the properties of the other services. A short example in the Ollama docs and
the regenerated command docs would make it easy to find.
The rest of your analysis matches what I see on main:
* The pull check is done (PR 26718, in 4.23.0), and the pull already blocks
before the service is reported as running.
* For the volume: the bind mount of {{~/.camel-test/ollama}} is there, so no
named volume is needed. If anything, the "continuing without bind mount"
warning could be more visible.
* Showing the pull progress can be a separate ticket, as it touches every infra
service.
So this ticket is now the {{--property}} option, for 4.24.0.
_Claude Code on behalf of Claus Ibsen_
> 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
> Assignee: Karol Krawczyk
> Priority: Major
> Fix For: 4.24.0
>
>
> 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)
