Versions Compared

Key

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

Image Modified

In the case of a failed upgrade, the system can be downgraded manually using the commands below.

Note
titlePersistent Storage is required for a possible downgrade

Downgrade will only work in the case of Persistent Storage is defined and is in use, prior to the downgrade.

For information about Persistent Storage, see Persistent Storage (34.01).


Info
titleNote:

Collect log and error data prior to the downgrade, to be able to analyze the problems.

Code Block
List available PODs:
$ kubectl get pod --namespace <namespace>

Repeat the command for all PODs:
$ kubectl describe pod <pod> --namespace <namespace>

Repeat the command for all PODs:
kubectl logs <pod> --namespace <namespace>


...

  1. Downgrade the system with the following commands:

    Code Block
    Identify the correct revision for the rollback:
    $ helm list --namespace <namespace>
    
    $ helm rollback  <RELEASE> [REVISION] --namespace <namespace>


  2. Verify that the downgrade was successful with the following command:

    Code Block
    Verify that the pods are up and running:
    $ kubectl get pods --namespace <namespace>


Note
titleNote!

Action Required for Rollback from 3.x to 2.x

If you need to perform a helm rollback from a 3.x version to a 2.x version, the existing EC Deployment need to patched after having run the helm rollback command.

This can be done with the following shell command:

Code Block
kubectl get deployments.apps -o custom-columns=NAME:metadata.name --no-headers | while read depl; do \
if [[ -n $(kubectl get deployments.apps $depl -o=jsonpath="{.spec.template.metadata.labels.ECDeployment}") ]]; \
then kubectl patch deployments.apps $depl -p '{"spec":{"template":{"spec":{"readinessGates":null}}}}'; \
fi; \
done

The reason for this is that the custom readiness gate introduced in version 3.0.0 will otherwise block the existing EC Deployments from being fully rolled back.

...