Rolling Software Upgrade for AMF

The rolling software upgrade uses one of the following processes:

  • Upgrading or migrating the build from an older version to a newer version

  • Upgrading the patch for the required deployment set of application pods

The applications must be available all the time, where:

  • Any new version (or even multiple newer versions) is expected to get deployed with a new build version or patch.

  • Any unstable deployment upgrade is reverted to a previous stable version.

  • Rolling upgrade process gets activated with a zero downtime, by incrementally updating pod instances with new ones.

Note

The rolling software upgrade is supported from an older version to a newer version within the same major release.

Prerequisites

The prerequisites for upgrading AMF must not have changes to the following functions:

  • Set of features supported in the old and new builds

  • Addition, deletion, or modification of the existing CLI behavior

  • Interface changes within the peer or across the pods

Recommendations

The following is a list of recommendations:

  • Configuration changes aren’t recommended during the upgrade process.

  • All the required configuration changes should be performed, when the upgrade process gets completed.

Failure Handling

It’s recommended to use the manual process to downgrade the system to a previous healthy build. The following are some of the failure scenarios:

  • Crash, pods deployment, and others during the processes

  • New events or procedures after the successful upgrade