Closed robrakaric closed 1 month ago
I agree with the approach on this so that we can make sure we aren't taking on the responsibility of maintaining separate Helm charts for Ollama when someone is already doing a really good job of that. I'm planning on thoroughly testing your Open WebUI chart out as soon as I can and will report back on what I find.
On an initial quick try I just did, I saw that the ollama.enabled
setting worked as expected, but did not try passing any config values to the Ollama chart yet. I'm planning to also test the case of deploying Ollama separately and passing in the ollamaUrl
setting to make sure everything works as expected with both use cases. It might be a couple days before I can get everything.
Sounds like a plan @0xThresh. I just tested it with GPU and model download support, to see how it'd perform in a real use-case.
This was the values.yaml
I used:
ollama:
# gets the chart installed
enabled: true
# took me awhile to figure out that another ollama key needs to be nested here for some options, like gpu
ollama:
gpu:
enabled: true
type: 'nvidia'
number: 1
models:
- llama3
- codellama
- deepseek-coder
runtimeClassName: nvidia
persistentVolume:
enabled: true
size: 50Gi
ingress:
enabled: true
class: nginx
host: openweb-ui.lan
Add this to append more Ollama urls:
externalHosts:
- https://urltoanotherollama/
- https://urltoyetanotherollama/
It works, but I do get a warning:
coalesce.go:286: warning: cannot overwrite table with non table for open-webui.ollama.ollama.models (map[])
coalesce.go:286: warning: cannot overwrite table with non table for open-webui.ollama.ollama.models (map[])
coalesce.go:286: warning: cannot overwrite table with non table for open-webui.ollama.ollama.models (map[])
Maybe it's not happy about the ollama.ollama nested key. I'm not sure. I don't get the error when I deploy the Ollama chart by itself using the same configuration values. Maybe you have some ideas.
I think it's a good idea not to reinvent the wheel and instead leverage what already works well and is community-driven. However, I notice that it's not the official Helm Chart from Ollama (https://github.com/ollama). Before proceeding with this breaking change and defining the Ollama Helm Chart as a dependency, I would suggest starting a new discussion to explore the possibility of moving the Helm Chart from https://github.com/otwld/ollama-helm to the official Ollama repository https://github.com/ollama and further developing it there with even more community involvement and power.
It looks like this is the official Helm chart from Ollama: https://artifacthub.io/packages/helm/ollama-helm/ollama I found that here: https://github.com/ollama/ollama?tab=readme-ov-file#package-managers The Artifact Hub entry for Ollama maps to this repo: https://github.com/otwld/ollama-helm
Considering that the Ollama repo links to that chart in Artifact Hub, I think it's safe to assume that this is as close to an official Ollama chart as we have, and we should be safe to use it.
There was already some chatter about this in the discord (development channel) between myself and @0xThresh , but wanted to formalize it as an issue.
Currently, the helm repo houses a template for both open-webui and ollama resources. There is an existing Ollama helm repo and chart that seems to work very well.
This issue proposes to remove the Helm resources for Ollama, and instead add Ollama as a dependency in
Chart.yaml
(see below example). This way, users can opt to either enable or disable the installation of the depedency, a common pattern in Helm chart usage. With that, all of the values nested underollama:
invalues.yaml
would be passed to the Ollama chart, which has its own documentation, reducing duplication of effort.It would entail also adding an additional step in the
helm-release.yaml
workflow to download the dependency.I've created a bit of a PoC playground for this here: https://github.com/robrakaric/open-webui-helm/tree/main/charts/open-webui
This would be a breaking change for existing users of the chart, but I figure it's best to have this discussion early on in the chart development process.