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