Upgrading Genesys CX Insights

This page describes how to upgrade your Genesys CX Insights deployment to a later release. For information about compatible releases, see the Product Alert. This page is applicable to deployments that use Kubernetes Descriptors. If you deployed using Helm, see Upgrade GCXI using Helm.

Important

In keeping with Genesys' commitment to diversity, equality, and inclusivity, beginning with release 9.0.019.01, some pod names are changed; this document refers to "gcxi-primary" and "gcxi-secondary" pods. In release 9.0.019.00 and earlier, these pods were named "gcxi-master" and "gcxi-slave".

If SAML is enabled in your environment, before you update GCXI, see the instructions in Genesys CX Insights User's Guide pertaining to Updating Genesys CX Insights when SAML is enabled.

Default user

Beginning with release 100.0.020.0000 (9.0.020), the default user for all Genesys CX Insights images has changed to genesys (id = 500); previously, the default user was root. In scenarios where you upgrade from release 9.0.019 or earlier to release 9.0.020 or later, this can result in an error due to volume mount permission settings; to prevent this, you must perform one of the following:

• Change ownership of volumes — This is the recommended method; complete the following steps before you upgrade to release 9.0.020 or later
  1. Execute the following commands to stop the pods:

     kubectl scale deploy/gcxi-secondary --replicas=0
     kubectl scale deploy/gcxi-primary --replicas=0

  2. Execute the following commands to change user:group ownership of volumes (log, backup, shared):

     chown -R 500:500  /mnt/log
     chown -R 500:500  /genesys/gcxi/shared

  OR

• Continue to run GCXI containers under user root. — See the documentation that is appropriate to your container runtime:
  • Docker-compose (see user directive)
  • Kubernetes (see runAsUser directive)

After you have completed one of the preceding changes, proceed with Upgrading Genesys CX Insights from 9.0.x to a later 9.0.x release

Procedure: Upgrading Genesys CX Insights from 9.0.x to a later 9.0.x release

Steps

1. Obtain the latest GCXI image (for example, gcxi:9.0.019.00)
2. Execute the following command to retag the image:

   docker tag <repository name>/<image>:<release> <image>:<release>

   where

   <repository name> is the identifier for the repository from which you downloaded the files,

   <image> is the name of the image file, and <release> is the release number.

   For example:

   docker tag pureengage-docker-production.jfrog.io/gcxi:9.0.019.00 gcxi:9.0.019.00

3. Execute the following command to back up the GCXI meta db:

   kubectl apply -f <destination path>/gcxi-backup.yaml

   where <destination path> is the folder in which the Genesys Installation Package (IP) is stored.

4. Execute the following commands to stop the containers:

   kubectl scale deploy/gcxi-secondary --replicas=0

   kubectl scale deploy/gcxi-primary --replicas=0

5. Open the gcxi.properties file for editing, and change the value of GCXI_VERSION to match the release you are installing. For example:

   GCXI_VERSION=9.0.019.00

6. Execute the following commands to load gcxi.properties into Kubernetes:

   kubectl delete configmap gcxi-config

   kubectl create configmap gcxi-config --from-env-file=<destination path>/gcxi.properties --namespace genesys

   where <destination path> is the folder in which the Genesys Installation Package (IP) is stored.

7. Execute the following commands to update GCXI images in Kubernetes:

   kubectl set image deployment/gcxi-<primary|secondary> gcxi=gcxi:<release>

   Where:

   • <release> is the same string as you entered for the GCXI_VERSION.

   For example:

   kubectl set image deployment/gcxi-primary gcxi=gcxi:9.0.019.00

   kubectl set image deployment/gcxi-secondary gcxi=gcxi:9.0.019.00

8. Execute the following command to start the PRIMARY container:

   kubectl scale deploy/gcxi-primary --replicas=1

   Wait until PRIMARY container has started (Tomcat is up, and MicroStrategyWeb page is available).

9. Execute the following command to start the SECONDARY container:

   kubectl scale deploy/gcxi-secondary --replicas=1

Upgrading the meta and history database

Use the following procedure to optionally upgrade the meta/hist database.

Procedure: Upgrading meta PostgreSQL

Purpose: If you have previously installed Genesys CX Insights with an older release of PostgreSQL hosting the meta and history database, you can optionally upgrade PostgreSQL using the steps in this procedure. The latest PostgreSQL release is required for new installations; when upgrading Genesys CX Insights you can continue to use the installed release of PostGreSQL for the meta and history database, but Genesys recommends that you upgrade PostgreSQL when you upgrade Genesys CX Insights.

Prerequisites

Follow the instructions in Upgrading Genesys CX Insights from 9.0.x to a later 9.0.x release to upgrade Genesys CX Insights before upgrading the PostgreSQL meta and history database.

Steps

1. Execute the following command to back up the GCXI meta db:

   kubectl apply -f <destination path>/gcxi-backup.yaml

   where <destination path> is the folder in which the Genesys IP is stored, for example:

   kubectl apply -f /genesys/gcxi/gcxi-backup.yaml

2. Execute the following commands to stop currently running containers:

   kubectl scale deploy/gcxi-secondary --replicas=0

   kubectl scale deploy/gcxi-primary --replicas=0

3. Execute the following command to delete the postgres container:

   kubectl delete -f <destination path>/gcxi-postgres.yaml

   where <destination path> is the folder in which the Genesys CX Insights is installed.

4. Move the local meta database folder (usually a subfolder of /genesys/gcxi/data) to a backup location. Once the upgrade is complete, you can delete this folder from the backup location; should the upgrade fail, you can restore this folder and restart the old postgres container.
5. Optionally, set the nodeSelector for the postgres pod; it is not set by default. If you do not have a shared volume set up for the /data folder (for example NFS), failing to set the nodeSelector can result in your meta database being stored locally on one one node, while the PostgreSQL schemas are stored on the other node:
   1. Open the gcxi-postgres.yaml file for editing.
   2. Uncomment the ## nodeSelector example ## section, and edit it as described in the comments, so that node-selector is set to worker node. Ensure that the label in nodeSelector matches the one applied to the node.
6. From the IP of the updated release of Genseys CX Insights, get the gcxi-postgres.yaml file, open it for editing, and change the image: parameter to reflect the release of PostGreSQL you are installing.
7. Execute the following commands to start the postgres container using the new gcxi-postgres.yaml file:

   1. kubectl create -f <destination path>/gcxi-postgres.yaml

      where <destination path> is the folder in which the new Genesys IP is stored, for example:

      kubectl create -f /genesys/gcxi/gcxi-postgres.yaml

   2. Execute the following command to verify the state of the gcxi-postgres pod:

      kubectl get pods | grep 'gcxi-postgres*'

      The pod status should be Running, for example:

      gcxi-postgres-5cd4d45754-mss6p   1/1       Running     0          6d

      If it has any other state, wait a few minutes and check again (it may take some time).

8. Execute the following command to initialize the new postgres container:

   kubectl apply -f <destination path>/gcxi-init.yaml

9. Restore the database using the two backup files (two pg_dums mstr_meta and two mstr_hist files):
   1. Examine the pg_dumps backup files, and copy the timestamp value. For example, if the file name is mstr_hist...20210414-095919.pgdump, copy the string 20210414-095919.
   2. Open the gcxi-restore.yaml file for editing, and populate the RESTORE_TAG parameter using the timestamp value you saved from the pgdump files. For example:

   3. - name: RESTORE_TAG
      value: 20210414-095919

   4. Execute the following command to restore the meta and history database:

      kubectl apply -f <destination path>/gcxi-restore.yaml

   5. Execute the following command and verify that the gcxi-restore-* job is Completed:

      kubectl get pod

10. Start your GCXI pods by start both PRIMARY and SECONDARY pods:

    kubectl scale deploy/gcxi-primary --replicas=1

    Wait until PRIMARY is done (wait until Tomcat is up, and MicroStrategyWeb page is available).

11. Execute the following command to start the SECONDARY container:

    kubectl scale deploy/gcxi-secondary --replicas=1