Overriding Helm Chart Values¶

The Traceable Platform is installed as a collection of Helm charts orchestrated by the Traceable Installer (TI). This guide explains how to override the default values.yaml of any of those charts at installation (or upgrade) time using a single TI values file.

Overview¶

You do not edit each chart's values.yaml directly. Instead, you provide an override file to clustermgr (via --ti-values). Inside that file, the cluster.helmValues block lets you target either all charts at once or one specific chart.

cluster:
  helmValues:
    global:                 # applies to ALL charts
      key: value
    mongodb:               # applies ONLY to the "mongodb" chart
      persistence:
        mountPath: /data

Scope	Path	Applies to
Global	`cluster.helmValues.global`	Every chart in the platform
Per-chart	`cluster.helmValues.<chartName>`	Only the named chart

Everything you place under a scope is merged into that chart's values.yaml, overriding the chart defaults.

Prerequisites¶

Access to clustermgr and the installer workflow (see Multi-Node Installation)
The chart name(s) you want to override (see Per-chart overrides)
Knowledge of the value keys exposed by the target chart's values.yaml

How overrides are applied¶

Global overrides¶

Values under cluster.helmValues.global are injected into every platform chart. Use this for settings that are common across components — for example, a pod security context required cluster-wide:

cluster:
  helmValues:
    global:
      podSecurityContext:
        fsGroup: 1001
        runAsUser: 1001

Because global values reach every chart, scope keys carefully. A common pattern is to nest the override under the sub-chart key (as with postgresql: above) so it only takes effect where that key is meaningful.

Per-chart overrides¶

Values under cluster.helmValues.<chartName> are injected into only that chart, leaving every other chart untouched. This is the most precise and recommended way to tune a single component:

cluster:
  helmValues:
    mongodb:
      persistence:
        mountPath: /data
    traceable-router:
      service:
        type: LoadBalancer

In the example above, mongodb gets a custom mount path and traceable-router is exposed as a LoadBalancer — no other chart is affected.

Precedence¶

When the same key is set in more than one place, the most specific value wins:

chart default values.yaml  <  cluster.helmValues.global  <  cluster.helmValues.<chartName>

A per-chart override always takes precedence over a global override, which in turn overrides the chart's packaged defaults.

Creating and applying an override file¶

Step 1: Author the override file¶

Create a file, for example traceable-overrides.yaml:

cluster:
  helmValues:
    global:
      # Common settings for all charts
      imagePullSecrets:
        - name: regcred
    traceable-router:
      # Expose the platform edge via a cloud load balancer
      service:
        type: LoadBalancer
    mongodb:
      persistence:
        mountPath: /data

Step 2: Pass it to the installer¶

Provide the file with --ti-values. You can supply multiple values files; later files override earlier ones:

./clustermgr install-ti \
    --dns=${DNS_FOR_PLATFORM} --multi-node \
    --registry-host="pkg.harness.io/ieq3j_9otlwbpfz-uryoda/docker-external" \
    --registry-prefix="" \
    --registry-user=${REPO_USER} --registry-password=${REPO_PWD} \
    --ti-values traceable-installer-values.yaml \
    --ti-values traceable-overrides.yaml

For one-off scalar overrides you can also use --ti-set key=value instead of a file. See the Helm configuration flags in Multi-Node Installation.

Advanced: block-scalar overrides with templating¶

cluster.helmValues.<chartName> accepts either a nested YAML map (as shown above) or a block-scalar string. The string form is required when an override needs installer templating — for example, injecting namespace-derived UID/GID values on OpenShift.

cluster:
  helmValues:
    global: |
      podSecurityContext:
        fsGroup: {{ int .tfi.fsGroup }}
        runAsUser: {{ int .tfi.runAsUser }}

    postgresql: |
      postgresql:
        primary:
          podSecurityContext:
            fsGroup: {{ int .tfi.fsGroup }}
          containerSecurityContext:
            runAsUser: {{ int .tfi.runAsUser }}

Here {{ int .tfi.runAsUser }} and {{ int .tfi.fsGroup }} are resolved by the installer from the namespace's SCC range. See the OpenShift Configuration guide for a complete example.

Use the map form for static values and the block-scalar (|) form only when you need installer template expressions.

Examples¶

Expose the edge router as a LoadBalancer (cloud)¶

cluster:
  helmValues:
    traceable-router:
      httpsEnabled: true
      httpEnabled: false
      service:
        type: LoadBalancer
        primaryPortDef:
          name: https
          port: 443
          targetPort: https
        secondaryPortDef:
          port: 0

Select the ingress routing mode and controller¶

cluster:
  helmValues:
    traceable-ingress:
      router: envoy
      controller: traefik-ingress

Apply a common annotation to all charts¶

cluster:
  helmValues:
    global:
      commonPodAnnotations:
        team: platform

Troubleshooting¶

Override does not take effect¶

Symptoms: A value you set is not reflected in the deployed resource.

Causes & solutions:

Wrong chart name. Confirm the <chartName> key matches the chart exactly. A typo silently does nothing.
Wrong key path. The override path must match the chart's values.yaml structure. Verify against the chart defaults.
Precedence. A per-chart override or a later --ti-values file may be overriding your value. Remember: global < <chartName>, and later --ti-values files win.

Global value applied where it should not be¶

Symptoms: A setting under global causes errors in an unrelated chart.

Solution: Move the override to a per-chart scope (cluster.helmValues.<chartName>) so it only reaches the intended chart, or nest it under the sub-chart key so it is ignored elsewhere.

Template rendering error in a block-scalar override¶

Symptoms: Installation fails with a Go-template parse error.

Solution: Ensure block-scalar overrides that contain Go template expressions (e.g. {{ .tfi.runAsUser }}) use the string (|) form and that referenced variables are available. In documentation, wrap such blocks in raw/endraw tags to prevent the docs site from interpreting them.

Support¶

For help building override files, contact support@harness.io.

When requesting support, provide:

Your override file(s)
The chart name and key path you are trying to override
Output of kubectl get <resource> -n traceable -o yaml showing the current (unexpected) value