How to Set Helm Values in SmoothGlue Enterprise

SmoothGlue Enterprise makes use of both Crossplane and Flux CD to manage deploying and updating Kubernetes resources, so it is generally not recommended to directly modify Kubernetes resources created by these systems, as any manual changes may later be overridden. This guide will help outline the recommended methods for updating Helm chart values for applications within SmoothGlue Enterprise.

SmoothGlue Enterprise recommends two methods for passing Helm values to SmoothGlue application Helm charts:

• As part of a values file passed to Zarf during the SmoothGlue Enterprise package deployment
• By modifying the per-application *-overrides ConfigMaps and Secrets in the structsure-system namespace

Passing Values During SmoothGlue Enterprise Package Deployment

When deploying or updating SmoothGlue Enterprise, updated Helm values can be passed to the Zarf deployment config. The SmoothGlue Enterprise Zarf package allows values to be provided using the BIGBANG_VALUES_FILE and BIGBANG_SECRETS_FILE variables. These can be set either within a Zarf config file, or directly from the command line. To set the BIGBANG_VALUES_FILE variable on the command line, use the --set flag as shown in the following example:

zarf package deploy zarf-package-smoothglue-amd64-v6.0.0.tar.zst --set
BIGBANG_VALUES_FILE=/path/to/bigbang-values.yaml

To set the BIGBANG_VALUES_FILE variable within a Zarf config file, add the following to your Zarf config file:

package:
  deploy:
    set:
      BIGBANG_VALUES_FILE: /path/to/bigbang-values.yaml

Ensure that your Zarf config file is used by Zarf during package deployment using the ZARF_CONFIG environment variable:

export ZARF_CONFIG=/path/to/zarf-config.yaml
zarf package deploy zarf-package-smoothglue-amd64-v6.0.0.tar.zst

To learn how Big Bang values get passed into individual application Helm charts, see Working with Big Bang Values.

Values passed through the BIGBANG_VALUES_FILE will be stored as ConfigMaps in Kubernetes, while values passed through BIGBANG_SECRETS_FILE will be stored as Secrets, allowing these values to be encrypted at rest. During Helm release reconciliation, values in the ConfigMaps and Secrets are merged together; for more details on this process, refer to the Variable Compositing and Precedence reference page.

For users upgrading SmoothGlue Enterprise versions, note that values applied during previous SmoothGlue Enterprise deployments will be merged with new values provided during the upgrade, so it is not necessary to provide a comprehensive list of all desired Helm values in your BIGBANG_VALUES_FILE during an upgrade.

Unsetting previously-set values carries special considerations; see Unsetting Custom Helm Values.

Modifying Application Override ConfigMaps or Secrets

After SmoothGlue Enterprise is successfully deployed, Helm values may be modified on the running cluster by modifying the per-application *-overrides ConfigMaps and Secrets located in the structsure-system namespace.

Start by listing the override ConfigMaps or Secrets to determine the correct one for your change:

kubectl get ConfigMap -n structsure-system
kubectl get Secret -n structsure-system

After identifying the correct ConfigMap or Secret, view the existing contents of the override file; preferably, you should also create a backup of the file. The following commands will both output the contents of the resource and save a copy to disk:

kubectl get ConfigMap -n structsure-system APPLICATION-overrides -oyaml | tee
cm-APPLICATION-overrides.yaml
kubectl get Secret -n structsure-system APPLICATION-overrides -oyaml | yq '.stringData."values.yaml"= (.data."values.yaml" | @base64d)' | tee secret-APPLICATION-overrides.yaml

Once you are ready to make your changes, you may do so using kubectl edit for ConfigMaps:

kubectl edit ConfigMap -n structsure-system APPLICATION-overrides

To modify values stored in a Secret, the data must be decoded from base64. Save the existing Secret as a file and decode its data using the following command:

kubectl get secret -n structsure-system APPLICATION-overrides -oyaml | yq '.stringData."values.yaml"= (.data."values.yaml" | @base64d) | .data = {}' > secret-APPLICATION-overrides.yaml

Make your edits using your text editor of choice, and after saving the changes, apply the modified values using kubectl apply:

kubectl apply -f secret-APPLICATION-overrides.yaml

Occasionally, while making changes to an override ConfigMap, an edit might break the formatting of the string-encoded YAML. A script like the following can be used to strip trailing whitespace and empty lines which can cause problems with multiline strings:

TMPFILE=$(mktemp)
TMPFILE2=$(mktemp)
NAME=argocd-overrides
kubectl get ConfigMap -n structsure-system $NAME -oyaml > $TMPFILE
kubectl get ConfigMap -n structsure-system $NAME -oyaml | yq '.data."values.yaml" | from_yaml' | sed -re '/^\s*$/d' -e 's/\s*$//' > $TMPFILE2
yq ".data.\"values.yaml\" = load(\"$TMPFILE2\")" $TMPFILE
rm $TMPFILE $TMPFILE2

After making changes to these ConfigMaps or Secrets, Flux CD will periodically check for and apply any detected changes to the Big Bang HelmRelease and then the relevant application HelmRelease(s). If desired, you can force a reconciliation of Flux's HelmReleases using the following commands:

flux reconcile HelmRelease -n bigbang bigbang
flux reconcile HelmRelease -n bigbang APPLICATION

To learn how Big Bang values get passed into individual application Helm charts, see Working with Big Bang Values.

Working with Big Bang Values

SmoothGlue uses the Big Bang umbrella chart as a wrapper around the individual application Helm charts, which provides some auto-configuration of the applications' integrations with each other. For example, the umbrella chart helps configure integrations between Keycloak and other applications. All provided values are first passed through the Big Bang Helm chart before being passed to the appropriate individual application Helm charts, so it is important to pass values at the correct level of the values hierarchy. The correct hierarchy level depends upon whether the application is considered to be part of the Big Bang core, a Big Bang add-on, or a third party application.

To pass a value to directly to the Istio Helm chart, which is part of the Big Bang core, the value should be placed under the following hierarchy:

istio:
  values:
    your_value: 'foobar'

Some Big Bang applications are considered add-ons. For these applications, place your values under a different hierarchy, as shown in the Keycloak example below:

addons:
  keycloak:
    values:
      your_value: 'foobar'

To determine which applications are considered core vs. add-ons, refer to the Big Bang umbrella chart values.yaml.

Finally, some applications packaged with SmoothGlue Enterprise are not part of Big Bang at all, but are configured using Big Bang's generic application wrapper. To set a value for SmoothGlue Console, for example, place the value here:

packages:
  console:
    values:
      your_value: 'foobar'

Unsetting Custom Helm Values

When upgrading a SmoothGlue Enterprise cluster using a Zarf package deployment, existing custom Helm values can be updated with new values using the procedure outlined in Passing Values During SmoothGlue Enterprise Package Deployment. However, because values set during the package deployment are merged with existing values, unsetting values back to the default values carries special considerations.

To unset an existing Helm value, follow the procedure outlined in Modifying Application Override Configmaps or Secrets to remove the value from the override resource on the cluster.

For example, the procedure below "unsets" a pinned GitLab chart Git tag value. For example, if the GitRepository tag for GitLab has been previously overridden, the ConfigMap gitlab-overrides might include a section like the following:

addons:
  gitlab:
    git:
      tag: 7.7.0-bb.0

To unset the tag pin, delete these two lines from the gitlab-overrides ConfigMap using kubectl edit:

    git:
      tag: 7.7.0-bb.0

Be careful to preserve valid YAML when making this change; for example, if no other keys are set for the .addons.gitlab object, set the value to an empty map to ensure the YAML is valid:

addons:
  gitlab: {}

Make sure to follow the procedure in Modifying Application Override ConfigMaps or Secrets to force a Flux CD reconciliation or wait for the HelmReleases to naturally reconcile.