This section discusses about the prerequisites of Image Management and Service.
Image Management and Service
Image service is the first step in the flexible upgrade workflow. Avi Load Balancer Controller hosts images of different versions because SE groups could be potentially in different versions.
The Controller must have additional disk space to host these images.
Avi Load Balancer Controller images for the major versions include the following:
controller.pkg (for VM-based Avi Load Balancer Controller)
controller_docker.tgz (For Docker-based Controller)
Images for the patches include the following:
avi_patch.pkg (Full package)
controller_patch.pkg (Avi Load Balancer Controller package)
se_patch.pkg (SE patch package)
As a part of the upload process, the image service extracts files, and metadata from the package. This information is not only displayed to the user, but it is also used in the upgrade process.
Image service provides an ability to upload, query, and delete Avi Load Balancer image(s) to the system.
Image service supports the upload of Avi Load Balancer patch packages.
Image upload can happen only on the cluster leader. It is not allowed from a cluster member.
Image Bundling
Avi Load Balancer supports composite image or image bundle. The composite image consists of the following:
Base image – Controller image (controller_docker.tgz, controller.pkg, controller ova, controller.qcow2, and so on).
Controller package – It is an optional package.
SE patch image – It is an optional package.
The upgrade workflow using the image bundle, or the composite image is the same as the standard image. When using the image bundle for an upgrade, a patch image can be applied in addition to the base image.
When upgrading from versions 18.x or lesser to 21.1 and higher, in the Avi Load Balancer Controller, change the DefaultTimeoutStartSec (File: /etc/systemd/system.conf) to 120 seconds to avoid timeout during the upgrade.
Uploading Image Using the CLI
The CLI provides better control of the upgrade operations leading to a consistent and predictable workflow.
For uploading the package, use the upload image filename <path-of-the-package> command as shown below.
[admin:controller]: > upload image filename /tmp/controller.pkg
The following show command returns the details of the image metadata. Use the show image <image-name> command as shown below.
[admin:-controller]: > show image +-----------------------------+--------------------------------------------+----------------+ | Name | UUID | Status | +-----------------------------+--------------------------------------------+----------------+ | 18.2.7-5000-20191009.205501 | image-fxxxx22-0f40-45de-8551-15xxxxxxx1fe | SYSERR_SUCCESS | +-----------------------------+-----
For more information about differences in CLI commands and APIs, see Comparison Table for Differences in CLIs Commands and APIs.
Uploading Image Service using the REST API
A POST operation is used for image upload. To get the image details in response, run a GET API request.
Use the following REST API to upload the image for controller.pkg.
URI: /api/image
Method:
POST
root@admin:-controller# curl -X POST -k https://10.58.3.27/api/image -u "admin:admin" -F [email protected] -H "X-CSRFToken: P9e5H5aCtRwtAVIouzJW9eoxWNPSHptc" -H "Cookie: csrftoken= P9e5H5aCtRwtAVIouzJW9eoxWNPSHptc; sessionid= 9ku3n1z3oqa62k7lwgbdm8zcatf75qag" -H "Referer: https://10.58.3.27/api"
Use the following REST API to upload the image for controller_patch.pkg.
root@admin:-controller# curl -X POST -k https://10.58.3.27/api/image -u "admin:admin" -F file=@controller_patch.pkg -H "X-CSRFToken: P9e5H5aCtRwtAVIouzJW9eoxWNPSHptc" -H "Cookie: csrftoken= P9e5H5aCtRwtAVIouzJW9eoxWNPSHptc; sessionid= 9ku3n1z3oqa62k7lwgbdm8zcatf75qag" -H "Referer: https://10.58.3.27/api"
Use the following API to delete the image provided, if it is not in use.
delete image <image-name>
Must-Checks for Upgrade
Prior to upgrade operations, various must-checks are run to check the mandatory and optional requirements for upgrade. The output message is displayed either as an error message or a warning message. Warnings can be skipped, whereas Errors cannot be over-ridden. CLI/API provides the skip_warnings option to control the above behavior.
For the CLI: This is directly integrated into the normal workflow, and there is no separate command.
For the REST API: Add
/preview/at the end of APIs to get previews for that particular flow.
Initiating an upgrade or patch through the CLI will halt at the UPGRADE_PRE_CHECK_WARNING state if the command is executed without the skip_warnings parameter.
Review the warnings using the command show upgrade status detail filter pre_check_status and take any necessary actions.
After addressing the warnings, you can run the upgrade or patch command again with the skip_warnings parameter to allow the operation to continue.
[admin:10-10-10-1]: > upgrade system image_ref 30.3.3-7235-20230110.035149 skip_warnings +-------------+------------------------------------------------------------------------------+ | Field | Value | +-------------+------------------------------------------------------------------------------+ | status_code | SYSERR_UPGRADE_OPS_PREVIEW_RESPONSE | | status | Checks preview for upgrade operations. | | checks | | | | Check Controller Cluster readiness for upgrade operations. | | | Check and inform user to take a backup prior to upgrade operations. | | | Check if se linux is enabled on controller nodes. | | | Check if upgrade operation is already in progress. | | | Check ServiceEngineGroup has an ongoing upgrade operation. | | | Check image version compatibility for upgrade operations. | | | Check ServiceEngine reachability for upgrade operations. | | | Check ServiceEngine disk space for upgrade operations. | | | Check Controller Cluster disk space for upgrade operations. | | | Check and inform Virtual Service(s) disruption for upgrade operations. | | | Check idempotent operations for upgrade operations. | | | Check active versions compatibility for upgrade operations. | | | Check ServiceEngineGroup error recovery options prior to upgrade operations. | | | Check Image state across Cluster members for upgrade operations. | | | Checks for the patch in image bundle. | | | Checks if Gslb Feature is enabled and provides feature specific messages. | | | Checks the system configuration. | | | Check total number of alerts for upgrade operations. | | | Checks if the cloud api versions are compatible after upgrade. | | | Checks if Docker version is compatible. | | | Checks if configured IP type is DHCP or STATIC. | | | Checks if se has a valid license state. | +-------------+------------------------------------------------------------------------------+ Starting upgrade +-------------+-----------------------------------------------------------------------------------------------------------+ | Field | Value | +-------------+-----------------------------------------------------------------------------------------------------------+ | status_code | SYSERR_UPGRADE_SYSTEM_STARTED | | status | 'Upgrade of System (Controller + All SEGroup(s)) started. Use 'show upgrade status' to check the status.' | +-------------+-----------------------------------------------------------------------------------------------------------+
Similarly, use the skip_warning option while performing the patch upgrade.
[admin:10-10-10-1]: > patch controller controller_patch_ref 23.1.1-7189-2p1-20221216.192828 skip_warnings Previewing upgrade
Downloading Upgrade Images
Download upgrade images by logging in to the Broadcom Support portal, and opening the My Downloads page.
