Glasswall Halo upgrade

From time to time, you will need to upgrade Glasswall Halo to stay up to date with the latest fixes, features, and releases.

Upgrading Glasswall Halo

1. Set the default Kubernetes namespace

Ensure your current Kubernetes context is set to the cdrplatform namespace:

kubectl config set-context --current --namespace=cdrplatform

2. Identify the latest image and chart versions

Use the Azure CLI to list available image tags in the Glasswall Artifact Registry:

az acr repository show-tags   --repository <repository>   --name glasswallhub   --username "${token_ID}"   --password "${token}"   --orderby time_desc

Replace <repository> with the appropriate image repository name.

3. Authenticate to the Helm registry

Log in to the Glasswall Helm registry using your credentials:

helm registry login glasswallhub.azurecr.io   --username "${token_ID}"   --password "${token}"

4. Pull the latest Helm chart

Download and extract the required Helm chart version:

helm pull oci://glasswallhub.azurecr.io/helm/<repository>   --version "${version}"   --untar   --untardir .

Replace <repository> with the chart repository name and ${version} with the desired chart version.

5. Upgrade the Helm release

Run the Helm upgrade command using the required image tag and repository:

helm upgrade --install <chart-name> <chart-name>   --set image.tag=<tag>   --set image.repository=glasswallhub.azurecr.io/<repository>

Replace the placeholders with the appropriate chart name, image tag, and repository.

Note: always review the release notes before upgrading to ensure compatibility and to understand any breaking changes.

After upgrading: historical data and reporting

Reporting data shown in the portal (processed-file history, risk reports, ICAP reports) is stored in MongoDB, while files in flight are held on the persistent volume. An upgrade migrates the platform services; it does not by itself move or reprocess historical reporting records.

Set expectations accordingly after an upgrade:

• Historical records remain in MongoDB. The portal reads reporting data through the cdrplatform-metrics-projection service. If historical files are not visible immediately after an upgrade, confirm that MongoDB and the metrics-projection service are running and have completed reconciliation before assuming data loss.
• Schema or projection changes between distant versions can mean that records created on the old version are reprojected before they reappear in the portal. Allow time for this to complete.
• Large version jumps (for example, upgrading across several minor versions at once) are higher risk. Where possible, upgrade incrementally and review the release notes for each intervening version for data-migration notes.

If historical records are still not visible after the platform is healthy and reconciliation has completed, do not delete or recreate volumes—contact Glasswall Support with your source and target versions so the migration can be investigated.