Skip to content

How to Upgrade this Package

The Big Bang mattermost-operator chart is generated from the upstream operator’s all-in-one manifest, with Big Bang customizations layered on the Deployment.

Upgrading the operator version

Renovate handles operator version bumps for you. It opens an MR that bumps the appVersion, chart version, the helm.sh/images annotation, and the values.yaml image tag, and regenerates the CHANGELOG and README.

That MR also pulls the upstream operator’s all-in-one manifest for the new version — https://raw.githubusercontent.com/mattermost/mattermost-operator/v<VERSION>/docs/mattermost-operator/mattermost-operator.yaml — and disseminates its resources into the chart, adding the standard Big Bang Helm labels and templating the namespaces:

  • the CustomResourceDefinitions go to chart/mattermost-operator-crds/;
  • every other resource (ServiceAccount, ClusterRole, ClusterRoleBinding, Service, Deployment) goes to chart/templates/upstream/.

You do not edit any of those files by hand — they are rewritten from upstream on each bump. The only Big-Bang-authored templates are those directly under chart/templates/ (e.g. version-check.yaml, bigbang/); leave the upstream copy of a resource to the automation.

The Deployment is the only manual step

chart/templates/upstream/deployment.yaml is the one routed file that carries Big Bang customizations, so it can’t simply be overwritten. When — and only when — a new operator version changes the upstream Deployment, the MR replaces it with the raw upstream Deployment behind a {{ fail }} guard, so CI fails until you reconcile it. (If upstream didn’t change the Deployment, it’s left as-is and there’s nothing to do.)

To reconcile it:

  1. Re-apply the Big Bang value mappings that the raw upstream Deployment does not carry: replicas, image ({{ .Values.image.repository }}:{{ .Values.image.tag }}), resources, imagePullSecrets, securityContext, nodeSelector, affinity, and tolerations. Keep the upstream args, command, env, and ports as they are.
  2. Delete the comment block and the {{ fail }} line at the top of the file.
  3. Push, and confirm CI passes.

How to test the upgrade

Cluster setup

Always make sure your local bigbang repo is current before deploying.

  1. Export your Ironbank/Harbor credentials (this can be done in your ~/.bashrc or ~/.zshrc file if desired). These specific variables are expected by the k3d-dev.sh script when deploying metallb, and are referenced in other commands for consistency:

export REGISTRY_USERNAME='<your_username>'
export REGISTRY_PASSWORD='<your_password>'
2. Export the path to your local bigbang repo (without a trailing /): Note that wrapping your file path in quotes when exporting will break expansion of ~. 
export BIGBANG_REPO_DIR=<absolute_path_to_local_bigbang_repo>
e.g. 
export BIGBANG_REPO_DIR=~/repos/bigbang
3. Run the k3d_dev.sh script to deploy a dev cluster (-a flag required if deploying a local Keycloak): 
"${BIGBANG_REPO_DIR}/docs/reference/scripts/developer/k3d-dev.sh"
4. Export your kubeconfig: 
export KUBECONFIG=~/.kube/<your_kubeconfig_file>
e.g. 
export KUBECONFIG=~/.kube/Sam.Sarnowski-dev-config
5. Deploy flux to your cluster: 
"${BIGBANG_REPO_DIR}/scripts/install_flux.sh" -u "${REGISTRY_USERNAME}" -p "${REGISTRY_PASSWORD}"

Deploy Bigbang Mattermost

  helm upgrade -i bigbang ${BIGBANG_REPO_DIR}/chart/ -n bigbang --create-namespace \
  --set registryCredentials.username=${REGISTRY_USERNAME} --set registryCredentials.password=${REGISTRY_PASSWORD} \
  -f https://repo1.dso.mil/big-bang/bigbang/-/raw/master/tests/test-values.yaml \
  -f https://repo1.dso.mil/big-bang/bigbang/-/raw/master/chart/ingress-certs.yaml \
  -f https://repo1.dso.mil/big-bang/bigbang/-/raw/master/docs/assets/configs/example/dev-sso-values.yaml \
  -f ./docs/dev-overrides/minimal.yaml \
  -f ./docs/dev-overrides/mattermost-testing.yaml
  ```
This will deploy the following apps for testing:

Mattermost, Mattermost Operator
Grafana, Prometheus, ElasticSearch (if enabled)

- Make sure Mattermost Operator pods/services is up and running with healthy status. 
- Scaled Mattermost via Operator
- Accessed web UI

## Big Bang Integration Testing

As part of your MR that modifies bigbang packages, you should modify the bigbang [bigbang/tests/test-values.yaml](https://repo1.dso.mil/big-bang/bigbang/-/blob/master/tests/test-values.yaml?ref_type=heads) against your branch for the CI/CD MR testing by enabling your packages.

To do this, at a minimum, you will need to follow the instructions at [bigbang/docs/developer/test-package-against-bb.md](https://repo1.dso.mil/big-bang/bigbang/-/blob/master/docs/developer/test-package-against-bb.md?ref_type=heads) with Mattermost, Mattermost Operator, and MinIO enabled (the below is a reference; actual changes could be more depending on the package MR).
```yaml
addons:
  mattermost:
    enabled: true
    sso:
      enabled: true
    values:
      enterprise:
        enabled: true
      monitoring:
        enabled: true

  mattermostOperator:
    enabled: true
    git:
      tag: null
      # branch: 33-implement-istio-authorization-policies
      branch: "renovate/ironbank"
    values:
      istio:
        hardened:
          enabled: true
          # enabled: false

  minio:
    enabled: true
    # git:
    #   tag: null
    #   branch: master

Chart Additions

automountServiceAccountToken

The mutating Kyverno policy named update-automountserviceaccounttokens is leveraged to harden all ServiceAccounts in this package with automountServiceAccountToken: false. This policy is configured by namespace in the Big Bang umbrella chart repository at chart/templates/kyverno-policies/values.yaml.

This policy revokes access to the K8s API for Pods utilizing said ServiceAccounts. If a Pod truly requires access to the K8s API (for app functionality), the Pod is added to the pods: array of the same mutating policy. This grants the Pod access to the API, and creates a Kyverno PolicyException to prevent an alert.

Files that need integration testing

If you modify any of these things, you should perform an integration test with your branch against the rest of bigbang. Some of these files have automatic tests already defined, but those automatic tests may not model corner cases found in full integration scenarios.

  • ./chart/templates/bigbang/*
  • ./chart/templates/clusterrole.yaml
  • ./chart/templates/clusterrolebinding.yaml
  • ./chart/values.yaml if it involves any of:
  • monitoring changes
  • network policy changes
  • kyverno policy changes
  • istio hardening rule changes
  • service definition changes
  • TLS settings

Follow the standard process for performing an integration test against bigbang.