Versions Compared

Version Old Version 2 New Version Current
Changes made by

Wei Siong Siow

linda wong

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Excerpt
nameActualUpgrade

Upgrade

To perform the actual upgrade you should use the same command as the test command described previously earlier minus the --dry-run=server flag, for example like this:

Code Block
helm upgrade --install uepe digitalroute/usage-engine-private-edition --atomic --cleanup-on-fail --version 4.0.0 -n uepe -f valuesFromSystem.yaml

If the upgrade was successful, the output will look like this:

Code Block
helm upgrade --install uepe digitalroute/usage-engine-private-edition --atomic --cleanup-on-fail --version 4.0.0 -n uepe -f valuesFromSystem.yaml
Release "uepe" has been upgraded. Happy Helming!
NAME: uepe
LAST DEPLOYED: Fri May 10 15:02:37 2024
NAMESPACE: uepe
STATUS: deployed
REVISION: 4
TEST SUITE: None
NOTES:
Usage Engine Private Edition 4.0.0 has been deployed successfully!
Check out the CHANGELOG.md in this chart for information about what has been changed, added and removed in this version.

Scale up the platform stateful set again so the platform starts back up using the following command:

Code Block
kubectl scale --replicas=1 sts/platform -n uepe

Excerpt
nameAfterUpgrade

After Upgrade

When the Usage Engine installation has been upgraded, ensure that any ECDs supporting rolling upgrade are still running as expected. If there are ECDs that have been configured for manual upgrade before the upgrade, see the section below.

Also ensure to enable any batch workflow groups again so that the batch processing can start again.

Preparing ECDs
Excerpt
namePreparingECDsForUpgrade

Before you start the actual upgrade, these steps are recommended to avoid issues in processing caused by the restarts during the upgrade:

  1. Disable any batch workflow groups and let any running batch workflows finish their runs.

  2. For real-time workflows, check which types of real-time workflows the ECs are running. If an ECD hosts workflows that allow for scaling and use an ingress for incoming traffic, the ECD will, by default, be upgraded through a rolling upgrade, which means that there will always be at least one workflow running even during the upgrade.

    However, if the real-time workflow does not support scaling, for example, because it uses fixed ports or storage that is not shared, the EC will become unavailable for a certain time during the upgrade. To gain control over when the EC becomes unavailable, you can edit the ECD by setting manualUpgrade to true before the upgrade. With this setting, the ECD will keep running on the old version until the upgrade has been performed and it can then be restarted on the new version in the EC Deployment Interface (4.3).

Info

Example - Editing ECD to Manual Upgrade

Option 1

Run the following command:

Code Block
kubectl get ecd -n <namespace>

kubectl edit ecd <ecd-name> ggsn-ecdn namespace

And change manualUpgrade to true:

Code Block
spec:
    .....
    manualUpgrade: true

Option 2

Run the following command:

Code Block
kubectl patch ecdeployment <ecd-name> ggsn-ecdn <namespace> --type=merge -p $'spec:\n  manualUpgrade: true'

When the upgrade is completed, the ECDs can be upgraded by editing the ECD in Desktop Online.

...