Downgrade(4.1)

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

Persistent 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 (4.1).

Note:

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

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>

Downgrade the system with the following commands:

Identify the correct revision for the rollback:
$ helm list --namespace <namespace>

$ helm rollback  <RELEASE> [REVISION] --namespace <namespace>

Verify that the downgrade was successful with the following command:

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

Note!

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:

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.