1. The builtin values.yaml defaults
2. The profile the user selects
3. Users input (-f or --set)

Unfortunately, Helm provides us (1) and (3) together (as .Values), making it hard to insert (2).

However, we can workaround this by placing all of (1) under a specific key (.Values.defaults).
We can then merge the profile onto the defaults, then the user settings onto that.

1. The builtin values.yaml defaults
2. The profile the user selects
3. Users input (-f or --set)

Unfortunately, Helm provides us (1) and (3) together (as .Values), making it hard to insert (2).

However, we can workaround this by placing all of (1) under a specific key (.Values.defaults).
We can then merge the profile onto the defaults, then the user settings onto that.

1. The builtin values.yaml defaults
2. The profile the user selects
3. Users input (-f or --set)

Unfortunately, Helm provides us (1) and (3) together (as .Values), making it hard to insert (2).

However, we can workaround this by placing all of (1) under a specific key (.Values.defaults).
We can then merge the profile onto the defaults, then the user settings onto that.

1. The builtin values.yaml defaults
2. The profile the user selects
3. Users input (-f or --set)

Unfortunately, Helm provides us (1) and (3) together (as .Values), making it hard to insert (2).

However, we can workaround this by placing all of (1) under a specific key (.Values.defaults).
We can then merge the profile onto the defaults, then the user settings onto that.

defaults:
  # Name allows overriding the release name. Generally this should not be set
  name: ""
  # revision declares which revision this gateway is a part of
  revision: ""

  # Controls the spec.replicas setting for the Gateway deployment if set.
  # Otherwise defaults to Kubernetes Deployment default (1).
  replicaCount:

  kind: Deployment

  rbac:

1. The builtin values.yaml defaults
2. The profile the user selects
3. Users input (-f or --set)

Unfortunately, Helm provides us (1) and (3) together (as .Values), making it hard to insert (2).

However, we can workaround this by placing all of (1) under a specific key (.Values.defaults).
We can then merge the profile onto the defaults, then the user settings onto that.

defaults:
  hub: gcr.io/istio-testing
  tag: latest

  # ImagePullSecrets for operator ServiceAccount, list of secrets in the same namespace
  # used to pull operator image. Must be set for any cluster configured with private docker registry.
  imagePullSecrets: []

  # Specify image pull policy if default behavior isn't desired.
  # Default behavior: latest images will be Always else IfNotPresent.
  imagePullPolicy: ""

defaults:
  global:

    # ImagePullSecrets for control plane ServiceAccount, list of secrets in the same namespace
    # to use for pulling any images in pods that reference this ServiceAccount.
    # Must be set for any cluster configured with private docker registry.
    imagePullSecrets: []

    # Used to locate istiod.
    istioNamespace: istio-system

    externalIstiod: false
    remotePilotAddress: ""

defaults:
  global:
    # Used to locate istiod.
    istioNamespace: "istio-system"

  base:
    # Validation webhook configuration url
    # For example: https://$remotePilotAddress:15017/validate
    validationURL: ""

  istiodRemote:
    # Sidecar injector mutating webhook configuration url
    # For example: https://$remotePilotAddress:15017/inject
    injectionURL: ""

ion: {{ index $gateway.labels "app.kubernetes.io/version" | default (index $gateway.labels "version") | default .Values.revision | default "latest" }} istio.io/rev: {{ .Values.revision | default "default" }} install.operator.istio.io/owning-resource: {{ .Values.ownerName | default "unknown" }} operator.istio.io/component: "IngressGateways" sidecar.istio.io/inject: "false" annotations: istio.io/rev: {{ .Values.revision | default "default" }} {{- if .Values.meshConfig.enablePrometheusMerg }} prometheus.io/port:...