Summary
Think of this as persona: an internal senior Admin defines a curated LLM catalog at Helm install time. Those models show up in the OpenEverest UI as a dropdown so users/developers deploy with one click (no raw YAML). Inference stays OpenAI-compatible for end users; they offload config manifests to OpenEverest + KubeAI via provider-kubeai.
Why
KubeAI’s model catalog is install-time. Today the provider only exposes free-text source/profile fields. Catalog models configured at install must also appear in the UI.
Scope
- Add Helm
modelCatalog (or equivalent) with curated entries (name, source, engine/version, resource profile, defaults).
- Surface catalog on the Provider CR so UI can bind a select (
optionsPath).
- UI: model dropdown from catalog; optional advanced/raw fields.
- Sync still creates a correct KubeAI
Model; clients use /openai/v1/... as usual.
- Docs for Admin catalog + user pick flow (changes = Helm upgrade).
Checklist
Additional notes
Touch points: topology.yaml (UI), versions.yaml (engine versions ≠ model catalog), charts/provider-kubeai/values.yaml, deploy/kubeai/values-gpu.yaml.
Resources
Summary
Think of this as persona: an internal senior Admin defines a curated LLM catalog at Helm install time. Those models show up in the OpenEverest UI as a dropdown so users/developers deploy with one click (no raw YAML). Inference stays OpenAI-compatible for end users; they offload config manifests to OpenEverest + KubeAI via
provider-kubeai.Why
KubeAI’s model catalog is install-time. Today the provider only exposes free-text source/profile fields. Catalog models configured at install must also appear in the UI.
Scope
modelCatalog(or equivalent) with curated entries (name, source, engine/version, resource profile, defaults).optionsPath).Model; clients use/openai/v1/...as usual.Checklist
Model; OpenAI API works.Additional notes
Touch points:
topology.yaml(UI),versions.yaml(engine versions ≠ model catalog),charts/provider-kubeai/values.yaml,deploy/kubeai/values-gpu.yaml.Resources