Upgrade

We recommended that you only change values you need to customize in your values.yml file to ensure smooth upgrading. Always check the upgrading instructions between chart versions.

Upgrading the chart

When upgrading Horizon, you’ll need to pull the latest version of the chart:

$ helm repo update evertrust

Verify that you now have the latest version of Horizon (through the App version column):

$ helm search repo evertrust/horizon
NAME                       	CHART VERSION	APP VERSION	DESCRIPTION
evertrust/horizon          	0.9.3        	2.7.0      	EverTrust Horizon Helm chart

Launch an upgrade by specifying the new version of the chart through the --version flag in your command:

$ helm upgrade <horizon> evertrust/horizon \
 --values override-values.yaml \
 --version 0.9.3

Upgrading the database

Horizon requires that you run a script called horizon-upgrade before installing a newer version of Horizon. This script will migrate the database schemas for compatibility with the new version. You have two options for running that script : either let Helm do it automatically or run the script manually from any computer that has Docker.

Automatic database upgrade

By default, the chart will automatically create a Job that runs an upgrade script when it detects that the Horizon version has changed between two releases. If the upgrade job fails to run, check the job’s pod logs. When upgrading from an old version of Horizon, you may need to explicitly specify the version you’re upgrading from using the upgrade.from key. The created pod will pull an image named horizon-upgrade:2.7.x, so make sure this image will be available to the cluster when upgrading.

Should you wish to disable the automatic upgrade mechanism, just set the upgrade.enabled key to false.

Before upgrading to specific chart version, thoroughly read any Specific chart upgrade instructions for your version.

Manual database upgrade

If for some reason, you need to manually run the upgrade script, you can use the dockerized version of the script provided that your host device has access to the Horizon’s MongoDB database.

You can then run the script through Docker:

$ docker run -it --rm registry.evertrust.io/horizon-upgrade:2.7.x \
   -m <mongo uri> \
   -t <target version> \
   -s <source version> # This is required when upgrading from an older version of Horizon

Or as a Kubernetes job, inside the Horizon cluster:

apiVersion: batch/v1
kind: Job
metadata:
  name: horizon-upgrade
spec:
  template:
    spec:
      containers:
        - name: horizon-upgrade
          image: registry.evertrust.io/horizon-upgrade:2.7.x
          imagePullPolicy: IfNotPresent
          args: [
              "-y",
              "-m", "$(MONGODB_URI)",
              "-s", "<source version>", (1)
              "-t", "<target version>"
          ]
          env:
            - name: MONGODB_URI
              valueFrom:
                secretKeyRef:
                  name: horizon (2)
                  key: mongoUri
      restartPolicy: Never
  backoffLimit: 0
1 The source and target values should be updated to match the desired upgrade path
2 The secret name and key should match where you store the Horizon MongoDB URI, so it will be injected as an environment variable to the Pod.

Specific chart upgrade instructions

Upgrading to 0.3.0

  • Loggers are now configured with an array instead of a dictionary. Check the values.yaml format and update your override values.yaml accordingly.

  • The init dabatabase parameters (initDatabase, initUsername and initPassword) have been renamed and moved to mongodb.horizon.

Upgrading to 0.5.0

  • The ingress definition has changed. The rules and tls keys have been removed in favor of a more user-friendly hostname that will autoconfigure the ingress rules, and a boolean tls key that will enable TLS on that ingress. Check the Ingress section.

Upgrading to 0.9.0

  • clientCertificateDefaultParsingType has been removed and is no longer supported by Horizon. Explicitly set the clientCertificateHeader or use ingress autoconfiguration to continue using client certificate authentication.

  • ingress.type will now be strictly validated. It may fail if you use an unsupported value.

  • mailer.port, mailer.tls and mailer.ssl are no longer set by default. You must now explicitly set if you want to use them.

Upgrading to 0.11.0

  • New Lease CRD is added.

  • akka.conf has been replaced with pekko.conf. It may fail if you use custom configuration otherwise it will be handled by the helm chart.

Upgrade to 0.16.0

  • Switching to native kubernetes leases implementation. CRDs leases aren’t used anymore.