Use this skill from deploy/helm/nvca-operator.
Values Flow
Two install paths, and only one of them renders values from a stack.
nvca-operator/values.yaml the chart's own defaults
-> make install values=<path> the values file, used directly
stack environment
-> scripts/render_values_from_stack_env.sh stack-aware generated values
-> make install-from-stack the generated values
Either accepts additional_values=<path> for further overrides.
Permanent Defaults
Edit nvca-operator/values.yaml directly. There is one chart and no vendoring
step, so that file is the source of truth.
Only defaults that suit every consumer belong there. Values tied to one deployment are supplied by whoever installs the chart:
- the compute-plane stack sets them under
deploy/stacks/nvcf-compute-plane/, includingnameOverride,fullnameOverrideandselfManaged.nvcaVersion - an ngc-managed install passes
ngcConfig.serviceKeyand thehelmManaged.*values on the command line
image.tag ships empty so templates fall back to appVersion, which the
release stamps at packaging time.
Deploy-time Overrides
Use additional_values for one-off validation or environment-specific values:
make install-from-stack \
stack_repo=../../../deploy/stacks/self-managed \
stack_env=local \
additional_values=override.yml
Use deploy-time overrides for secrets, credentials, cluster-specific IDs, and temporary validation changes.
Validation
make lint
make template
make validate
tools/ci/validate-helm-chart deploy/helm/nvca-operator/nvca-operator \
-f tools/ci/helm-validate-values/nvca-operator.yaml
Gotchas
- Install-time values are layered after generated stack-aware values.
- Use
yqcarefully for nested keys and quoted strings. Chart.yamlname stays in git and must match the subproject's service_name; the release refuses to publish when they differ. Only the version is set at packaging time, andappVersionis stamped from the nvca release the chart installs.- Never commit real service keys or rendered secret material.