Vss Deploy Helm

VSS Helm deploy

Use this workflow for the VSS sample app Helm chart at sample-applications/video-search-and-summarization/chart. The chart’s real dependencies are ovms, minioserver, audioanalyzer, postgresql, rabbitmq, videoingestion, videosearch, vdmsvectordb, multimodaldataprep, multimodalembeddingms, vectorretriever, vllm (alias of vllm-server), summaryui, and searchui (aliases of vssui).

If the user asks to map Compose or setup.sh settings to Helm values, read references/helm-values-map.md.

Answer contract when the cluster is not reachable

The user may be planning ahead, or kubectl/the cluster/the chart may be unavailable here. In that case do not stall and do not invent output. Answer with the exact command sequence instead: the bootstrap step, the override files to stack in order, the values the operator must fill in, the helm install / helm upgrade command with its namespace, and how to verify. State plainly that the commands were not executed. Never end the answer by asking whether to run them.

Environment setup (run first)

This skill drives the Video Search & Summarization app through its real source files, so the VSS application must be present and you must run commands from its app root. Do this before anything else, and it works whether or not the VSS source is already in your workspace.

Run the bundled bootstrap. It resolves the app root in this order and prints it as the only line on stdout:

1. Walk up from the current directory looking for a VSS app root - a directory carrying all three markers setup.sh, docker/, and pipeline-manager/.
2. Ask git for the enclosing repository (git rev-parse --show-toplevel) and check whether it holds sample-applications/video-search-and-summarization, or is itself a VSS app root. This is what makes your own clone - or a fork - work unchanged.
3. Reuse a checkout a previous bootstrap already placed in ${XDG_CACHE_HOME:-$HOME/.cache}/vss-src/edge-ai-libraries.

If any of those hit, that checkout is reused and NO clone is performed. Only when all three miss does it clone - and then only a shallow (--depth 1), single-branch, sparse checkout of just sample-applications/video-search-and-summarization from main:

# SKILL_DIR is THIS skill's own directory (shown to you when the skill loads);
# in-repo it is .github/skills/vss-deploy-helm. Works the same if the skill is installed standalone.
SKILL_DIR=".github/skills/vss-deploy-helm"
APP_ROOT="$(bash "$SKILL_DIR/scripts/vss-bootstrap.sh")"
cd "$APP_ROOT"

Every command below assumes the working directory is this APP_ROOT. To pull from a fork/branch or reuse a specific checkout dir, override VSS_REPO_URL, VSS_REPO_BRANCH, or VSS_CLONE_DIR before running it. The bootstrap refuses to overwrite an existing non-VSS clone destination.

Prerequisites

1. Confirm a reachable Kubernetes cluster, kubectl, and Helm 3:

   kubectl cluster-info
   kubectl get nodes
   helm version

2. Confirm dynamic PV provisioning if using PVCs:

   kubectl get storageclass

3. For GPU/NPU, discover resource keys before writing values:

   kubectl get nodes -o json | jq -r '.items[] | "\(.metadata.name):\n" + (.status.allocatable | to_entries | map(select(.key | test("gpu|npu|vpu|accel";"i"))) | map("  \(.key): \(.value)") | join("\n"))'

   Common Intel keys are gpu.intel.com/i915, gpu.intel.com/xe, and npu.intel.com/accel.

1. Start from the real chart values

Work from the chart directory:

cd sample-applications/video-search-and-summarization/chart
helm dependency update
helm dependency list

Create/edit user_values_override.yaml for user-specific values. Do not commit filled secrets.

Minimum required values for most modes:

global:
  usePvc: true
  keepPvc: true
  huggingfaceToken: "hf_..."   # needed for gated/private Hugging Face models
  vlmName: "Qwen/Qwen3-VL-4B-Instruct"
  llmName: ""                  # optional OVMS split-model summarization model
  embeddingModelName: ""       # set per mode below
  modelDownload:
    image:
      repository: intel/model-download
      tag: "2026.2.0-ww30"
      pullPolicy: IfNotPresent
    ovmsReleaseTag: "v2026.1"
  proxy:
    http_proxy: ""
    https_proxy: ""
  env:
    POSTGRES_USER: "vsadmin"
    POSTGRES_PASSWORD: "change-me"
    MINIO_ROOT_USER: "minioadmin"
    MINIO_ROOT_PASSWORD: "change-me-8chars"
    RABBITMQ_DEFAULT_USER: "guest"
    RABBITMQ_DEFAULT_PASS: "change-me"

# Summary/OVMS model workspace:
ovms:
  claimSize: "20Gi"

# Search model caches (needed only when search is enabled):
multimodaldataprep:
  modelPvc:
    enabled: true
    size: "10Gi"
multimodalembeddingms:
  modelPvc:
    enabled: true
    size: "10Gi"

Why these matter:

• global.usePvc enables the service-specific claims; OVMS, video-ingestion, Multimodal DataPrep, and the embedding service no longer share one PVC.
• global.keepPvc: true avoids re-downloading/re-converting models after uninstall, but stale PVCs can also preserve incompatible old state. The vLLM subchart's vllm-model-cache PVC does not currently honor global.keepPvc and is deleted with the release.
• ovms.claimSize sizes the summary-mode OVMS model workspace.
• multimodaldataprep.modelPvc and multimodalembeddingms.modelPvc independently configure search model caches.
• global.vlmName is required for summary/unified modes and is used by OVMS or by vLLM.
• global.embeddingModelName is required when search components are enabled.
• global.modelDownload controls the image used by the OVMS and video-ingestion init containers. Each init container starts its local REST service, submits a download job, waits for completion, and exits before the application container starts.

2. Choose the mode using the real override files

Use exactly these chart override files:

Embedding model rule:

• Search-only and dual UI use a multimodal embedding model, for example global.embeddingModelName: "CLIP/clip-vit-b-32".
• Unified summary+search uses a text embedding model, for example global.embeddingModelName: "QwenText/qwen3-embedding-0.6b".