Preparations

Before doing anything to the running installation, the config file for the new installation should be prepared by following these steps:

Retrieve the values.yaml file that you have used previously, or if you want to start from scratch, you extract it from the installation by running these commands:

helm get all <helm name> > <output filename>.yaml
E.g:
helm get all uepe > valuesFromSystem.yaml

Where uepe is the helm name you have selected for your installation. You will see list similar to the one below.

helm list
NAME         	NAMESPACE	REVISION	UPDATED                                 	STATUS  	CHART                             	APP VERSION
external-dns 	uepe     	1       	2024-05-08 15:27:48.258978207 +0200 CEST	deployed	external-dns-7.2.0                	0.14.1     
ingress-nginx	uepe     	1       	2024-05-08 16:18:43.919980224 +0200 CEST	deployed	ingress-nginx-4.10.0              	1.10.0     
uepe         	uepe     	3       	2024-05-10 14:16:17.724426589 +0200 CEST	deployed	usage-engine-private-edition-4.0.0	4.0.0

Retrieve the new version from the repository by running the following command:

helm fetch <repo name>/usage-engine-private-edition --version <version> --untar

For example:

helm fetch digitalroute/usage-engine-private-edition --version 4.0.0 --untar

Next, check the file CHANGELOG.md inside the created folder to find out what may have changed in the new version when it comes to the values-file.
If you are uncertain about how to interpret the content of the file, see below for some examples of keys and how to interpret them:
```
The following values have been removed:
* ```mzOperator.clusterWide```
* ```mzOperator.experimental.performPeriodicWorkflowCleanup```
* ```jmx.remote```
* ```platform.debug.jmx```
```
means that in the values file they should be entered as:
```
mzOperator:
  clusterWide:
  experimental:
    performPeriodicWorkflowCleanup
jmx:
  remote:
platform:
  debug:
    jmx:
```
Each part of the key does not necessarily follow directly after the previous one, but always before any other “parent” on the same level. So in this example of a values.yaml file:
```
debug:
  script:
    enabled: false
  log:
    level:
      codeserver: info
      jetty: 'off'
      others: warn
```
an example of a key could be debug.log.level.jetty.
Make any necessary updates based on changed field you may be using in the values.yaml file you got from the existing installation so it matches the new version.
Take note of any fields that have been deprecated or removed since the last version so any configuration of those fields can be replaced.
When you have updated the values.yamle file you can test it by running this command:

helm upgrade --install uepe digitalroute/usage-engine-private-edition --version 4.0.0 -n uepe -f fromHelm.yaml --dry-run=server

Before doing anything actively to the running installation, the config file for the new installation should be prepared.

First, retrieve the values.yaml you’ve used previously, or if you don’t have it, you can get it from the installation by doing this:

helm get all <helm name> > <output filename>.yaml
E.g:
helm get all uepe > valuesFromSystem.yaml

Where “uepe” is the helm name you’ve chosen for your installation

helm list
NAME         	NAMESPACE	REVISION	UPDATED                                 	STATUS  	CHART                             	APP VERSION
external-dns 	uepe     	1       	2024-05-08 15:27:48.258978207 +0200 CEST	deployed	external-dns-7.2.0                	0.14.1     
ingress-nginx	uepe     	1       	2024-05-08 16:18:43.919980224 +0200 CEST	deployed	ingress-nginx-4.10.0              	1.10.0     
uepe         	uepe     	3       	2024-05-10 14:16:17.724426589 +0200 CEST	deployed	usage-engine-private-edition-4.0.0	4.0.0

Next retrieve the new version from the repository:

helm fetch <repo name>/usage-engine-private-edition --version <version> --untar

E.g.:

helm fetch digitalroute/usage-engine-private-edition --version 4.0.0 --untar

Next, check the file CHANGELOG.md inside the created folder to find out what may have changed in the new version when it comes to the values-file.

In case you’re uncertain about the format of the file, here are some examples of keys and how to interpret them:

The following values have been removed:
* ```mzOperator.clusterWide```
* ```mzOperator.experimental.performPeriodicWorkflowCleanup```
* ```jmx.remote```
* ```platform.debug.jmx```

The above mean that in the values file they are entered as:

mzOperator:
  clusterWide:
  experimental:
    performPeriodicWorkflowCleanup
jmx:
  remote:
platform:
  debug:
    jmx:

Each part of the key doesn’t necessarily follow immediately after the previous one, but before any other “parent” on the same level. So on in this example from values.yaml:

debug:
  script:
    enabled: false
  log:
    level:
      codeserver: info
      jetty: 'off'
      others: warn

One example of a key could be “debug.log.level.jetty”.

Make any necessary updates based on changed field you may be using in the values-file you got from the existing installation so it matches the new version.

TODO: What does the user do if we’ve removed something that they use?

When you’re update the values file you can test it using this command:

helm upgrade --install uepe digitalroute/usage-engine-private-edition --version 4.0.0 -n uepe -f fromHelm.yaml --dry-run=server

Preparations for Upgrade

Preparations