ov-layers/skills/notebook-ollama/SKILL.md
Ollama integration notebook collection provisioned into the workspace volume at deploy time. 6 Jupyter notebooks demonstrating Ollama via requests, OpenAI, ollama lib, Anthropic, HuggingFace, and GPU. Data-only layer — no packages, no services, no dependencies. Use when working with notebook-ollama, Ollama API tutorials, or Jupyter+Ollama integration.
npx skillsauth add overthinkos/overthink-plugins notebook-ollamaInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
| Property | Value |
|----------|-------|
| Dependencies | (none) |
| Packages | (none) |
| Services | (none) |
| Volumes | workspace -> ~/workspace (from jupyter) |
| Data | data/ollama -> workspace volume, dest: ollama |
| Install files | (none) |
This is a data layer — it uses the data: field in layer.yml to map a directory of notebooks to a named volume with a subdirectory destination:
info: "Ollama integration notebook collection"
data:
- src: data/ollama
volume: workspace
dest: ollama
At build time, the contents of data/ollama/ are staged into /data/workspace/ollama/ inside the image.
At deploy time, ov config or ov update copies the staged data into the workspace volume at <workspace>/ollama/. The dest: ollama field places the notebooks in a subdirectory rather than the volume root.
6 Jupyter notebooks covering different Ollama client libraries:
| Notebook | Library | Features |
|----------|---------|----------|
| 00_Ollama_Requests.ipynb | requests | Raw REST API: list, show, generate, chat, stream, embed, copy, delete |
| 01_Ollama_GPU.ipynb | requests | GPU verification: nvidia-smi, inference metrics, VRAM monitoring |
| 02_Ollama_OpenAI.ipynb | openai | OpenAI-compatible API: completions, chat, multi-turn, stream, embed |
| 03_Ollama_Library.ipynb | ollama | Native Python library: all API operations + model management |
| 04_Ollama_HuggingFace.ipynb | ollama | HuggingFace GGUF model import, verification, inference |
| 05_Ollama_Anthropic.ipynb | anthropic | Anthropic-compatible API: chat, system prompts, streaming, tool calling, vision |
Manifest: notebooks.yaml — structured catalog with title, description, and ordering.
The notebooks default to http://localhost:11434 for the Ollama API endpoint. Each notebook reads:
OLLAMA_HOST = os.getenv("OLLAMA_HOST", "http://localhost:11434")
When the ollama image is deployed via ov config ollama, its env_provides automatically injects OLLAMA_HOST=http://ov-ollama:11434 into the global deploy.yml env. Any container configured after ollama (or reconfigured with --update-all) automatically gets the correct Ollama endpoint — no manual environment setup needed.
Setup:
ov config ollama --update-all # deploys ollama + propagates OLLAMA_HOST to all
ov start ollama
ov start jupyter-ml-notebook # OLLAMA_HOST already set via env_provides
Both containers must be on the same ov Podman network for DNS resolution to work.
See /ov:config for --update-all and /ov-layers:ollama for env_provides details.
The ollama Python library creates its HTTP client at import time by reading OLLAMA_HOST from os.environ. Module-level functions (ollama.list(), ollama.generate(), etc.) are bound methods on this cached client. Simply setting a Python variable doesn't propagate to the library.
The notebooks use this pattern to handle both fresh kernels and re-runs:
import os
OLLAMA_HOST = os.getenv("OLLAMA_HOST", "http://localhost:11434")
os.environ["OLLAMA_HOST"] = OLLAMA_HOST
import ollama
import importlib; importlib.reload(ollama) # Rebinds module functions
The newer ollama library returns Pydantic models, not dicts. Model names are accessed via .model attribute (not ["name"]), and the list is .models (not .get("models", [])):
# Old (dict access)
model_names = [m.get("model", "") for m in models.get("models", [])]
# New (Pydantic attribute access)
model_names = [m.model for m in models.models]
llama3.2:latest (3.2B, Q4_K_M)ollama_anthropic.ipynb uses ministral-3:3b-instruct-2512-q4_K_MPull models before running: ov shell ollama -c "ollama pull llama3.2"
# image.yml
jupyter-ml-notebook:
layers:
- jupyter-ml
- notebook-templates
- notebook-finetuning
- notebook-ollama
# ... other layers
# Deploy and start both services
ov config ollama && ov start ollama
ov config jupyter-ml-notebook && ov start jupyter-ml-notebook
# Pull a model, then open notebooks
ov shell ollama -c "ollama pull llama3.2"
# Open http://localhost:8888 -> navigate to ollama/
/ov-images:jupyter-ml-notebook/ov:layer — data field documentation and layer authoring rules/ov:config — data provisioning during ov config setup/ov:deploy — volume backing configuration/ov-layers:notebook-finetuning — sibling data layer pattern (Unsloth fine-tuning notebooks)/ov-layers:notebook-templates — sibling data layer pattern (starter notebooks)/ov-layers:ollama — the Ollama binary layer (server side)/ov-images:ollama — the standalone Ollama image (must be running for notebooks to connect)/ov-images:jupyter-ml-notebook — the image that includes this layerUse when the user asks about:
ollama Python library env var or Pydantic API gotchas/ov:test — declarative testing (tests: block, ov image test, ov test)tools
Use when authoring or modifying a charly PLUGIN — a candy with a `plugin:` block that contributes Providers (verbs/kinds/deploy-targets/steps/builders/commands), its own CUE schema, builtin (compiled-in) or external (out-of-tree git repo). Covers the unified Provider model, the per-plugin CUE-schema contract (single source → Go params for dev + schema-over-Describe RPC for runtime), the SDK, and the loader.
tools
The CUE data-validation / configuration CLI (cue), pinned to v0.16.1. Use when working with the cue candy, installing the cue binary into a box or onto a target:local dev host, or running the offline schema-vendoring pipeline that feeds charly's egress validation.
tools
CUE EGRESS validation — validating (and, where it adds value, generating) the config files charly WRITES to a system BEFORE the bytes hit disk. MUST be invoked before working on charly/egress.go, the vendored schemas under candy/plugin-egress/egress-schemas/vendor/, the ValidateEgress / registerVendoredEgressKind path, the offline `task cue:vendor` pipeline, or adding an egress schema for any written artifact (cloud-init, k8s manifests, traefik routes, runtime config, install ledger, systemd/quadlet units, ssh_config, libvirt XML).
tools
Kubernetes cluster-probe declarative check verb — the `kube:` check verb (nodes, pods, ingress, storage class, addon health, apply/delete, and arbitrary resource GETs) served out-of-process by the candy/plugin-kube plugin (vendored client-go; no external kubectl required).