Upgrade

This document provides a high-level overview of processes that are involved during the Platform9 Edge Stack (PES) on-premises upgrade process. This upgrade process is very similar to the PMK Installation process and follows similar steps except for a few other upgrade specific processes.

Upgrade Process

The upgrade process is broken down into four main steps.

Download & Install - The PES stack upgrade entails running the install.sh script, which upgrades the binaries and the associated components.
DU upgrade - The DU upgrade is accomplished via the newly upgraded airctl using the upgrade-du command.
HostAgent upgrade - This is actually a two-part process
1. The first part is to clean up the (docker and rpm) caches of all existing hosts via the configure-hosts command.
2. The second part upgrades the host agent software on ALL the hosts. (see details below)
Cluster upgrade - This update is executed via an API upgrade on each cluster.

Download & Install

This is similar to the Installation, you can download a newer version and run install exactly the way you would do that during install. The install.sh script will prompt you to upgrade as required.

Bash
    
​x
 
wget https://raw.githubusercontent.com/platform9/support-locker/master/edge-stack/download.shchmod +x ./download.sh​#./download.sh <secret> <version># in the following example super-secret-word is the secret provided by Platform9 team# v-5.3.0-15312 is the version to download and install​./download.sh super-secret-word v-5.3.0-15312chmod +x ./install.sh./install.sh v-5.3.0-15312
Copy

Upgrade DU

Run the configure-localhost command first to make sure that IPv4/IPv6 settings are configured, and the HAProxy configuration is initialized.

Bash
    
 
$ /opt/pf9/airctl/airctl configure-localhost --config /opt/pf9/airctl/conf/airctl-config.yaml
Copy

The next task after the installation is to upgrade the DU.

Bash
    
$ /opt/pf9/airctl/airctl upgrade --disk /opt/pf9/airctl/du-v-5.2.0-1558488.qcow2 --config /opt/pf9/airctl/conf/airctl-config.yaml--- backing up management plane to /tmp/airctl_backup_662140784/backup.tar.gz ---adding missing VmIp field to state fileadding missing PrivKeyPath field '/home/centos/.ssh/id_rsa' to state filebackup saved to /tmp/airctl_backup_662140784/backup.tar.gz--- deleting management plane ---done--- creating new management plane ------ restoring from backup ---starting management plane ...preparing configuration database for restore operation ...restoring configuration database ...preparing management plane for restore operation ...restoring main database ...re-configuring the management plane ...restore operation completed successfully--- upgrade complete ---
Copy

Configure Host and HostAgent Upgrade

Platform9 uses a two-step upgrade, the first step is to do configure-hosts to update any yum-repos or add docker images (this is being deprecated and moving to a centralized registry for images and a centralized yum-repo). This step is also needed if you want to change the DU Name to IP mapping.

Before running host upgrade, ensure the airct-config.yaml has the right file names set in parameters hostAgentRepo and dockerRepo.

To upgrade the nodes, run configure-hosts followed by upgrade-hosts. This will only upgrade nodes listed in the airctl-config.yaml.

Bash
    
 
/opt/pf9/airctl/airctl configure-hosts[airctl-1-1672253-128.pf9.localnet] |                     HOST                      | SUCCESS | MESSAGE |[airctl-1-1672253-128.pf9.localnet] |-----------------------------------------------|---------|---------|[airctl-1-1672253-128.pf9.localnet] | 10.128.147.243                                | true    |         |[airctl-1-1672253-128.pf9.localnet] | 10.128.146.10                                 | true    |         |[airctl-1-1672253-128.pf9.localnet] | test-pf9-rbk-c7-pmk-a-1672253-400-1.novalocal | true    |         |
Copy

Bash
    
 
/opt/pf9/airctl/airctl upgrade-hostssuccess
Copy

Host Status

You can obtain the status of each host's kubernetes version and hostagent version before you proceed to the next step

Bash
    
 
/opt/pf9/airctl/airctl host-statusDU hostagent version:  5.3.0.3772.a458a6dHost  IP           UUID                    Hostagent  Kube Version   Status----  ----         ----                    ---------  ------------   ------t-3 10.128.147.73  46eb0159-58d7-46fb-bbc0 5.3.0-3772 1.20.5-pmk.1917  okt-2 10.128.147.185 5a2c84eb-6ca4-41b3-90a9 5.3.0-3772 1.20.5-pmk.1917  okt-1 10.128.146.212 dfa46c4f-0e23-41a8-a74e 5.3.0-3772 1.20.5-pmk.1917  ok
Copy

Now you are ready to upgrade your cluster whenever you would like.

Upgrade Cluster

You can also upgrade the cluster upgrade via the Qbert API. There may be other specific considerations for upgrading the cluster, which can be found on the upgrade your cluster page.

API For Host Data

In the DU shell, users can obtain relevant data by querying the hostagent on the node by running REST API GET at http://localhost:8082/v1/hosts/<host uuid> and noting the host_agent section in the output. The version field represents the hostagent version that is currently running, while the status field has one of two values, either running_or _updating. The default status is _running_,while the updating state indicates that it has received the command and is updating and processing it. If the host reports offline, the hostagent is down or connectivity to the host is broken.

Bash
    
 
curl -s -H "X-Auth-Token: $TOK" http://localhost:8082/v1/hosts/f72dd9ca-06ca-4846-be21-833b7edd8336 | jq .host_agent{  "status": "running",  "version": "5.1.0-3534.991bd2f"}
Copy

Additionally, users can upgrade the hostagent on the host using the REST API to invoke a PUT via http://localhost:8082/v1/hosts/<host uuid>/hostagent using a request body containing the name, version and URL of the node for the hostagent package.

Bash
    
curl -s -H "X-Auth-Token: $TOK" -X PUT http://localhost:8082/v1/hosts/f72dd9ca-06ca-4846-be21-833b7edd8336/hostagent  --data '{"name":"hostagent", "version":"5.2.0-3788-289b32e", "url": "http://localhost:9080:private/pf9-hostagent-5.2.0-3788-289b32e.rpm"}'
Copy

Rollback

Considerations

Any cluster created on the DU after the DU upgrade will cease to communicate with the DU after the DU is rolled back. Such clusters will have to be destroyed. Nodes will have to be cleaned up and then connected to the rolled back DU before bootstrapping a fresh cluster.
Rollback was designed to be used shortly after a failed upgrade and is not intended as a general purpose backup/restore feature. This is because it saves and restores virtual machine and virtual network XML files, which are not very portable. The “backup” and “restore” commands, when used with pristine copies of the virtual disk (from the official release) are the recommended mechanism. A separate instruction guide will be provided for the backup and restore feature.

How to

Use these steps to stop and unconfigure the DU.

These commands may or may not fail, depending on the actual state of the failed upgraded DU.

Bash
    
 
$ airctl stop​$ airctl unconfigure-du
Copy

To roll back to the previous DU, use this command.

Bash
    
 
$ airctl rollback --dir /tmp/airctl_backup_156579090deleting recently created VM...donerecovering previous VM...recovering state file...recovering configuration state...
Copy

To start the DU, use this command.

Bash
    
 
$ airctl start --config /opt/pf9/airctl/conf/airctl-config.yaml​starting management plane ...​your management plane web UI is accessible at: https://airctl-7.pf9.localnet​find credentials to login by running get-creds​$ airctl status​management plane is started
Copy

Do validations:
The Kubernetes nodes and clusters should show as connected.

Last updated on

Was this page helpful?