Chapter 3. 3scale operator-based upgrade guide: from 2.11 to 2.12
Upgrade Red Hat 3scale API Management from version 2.11 to 2.12, in an operator-based installation to manage 3scale on OpenShift 4.x.
To automatically obtain a micro-release of 3scale, make sure automatic updates is on. To check this, see Setting up the 3scale operator for micro releases.
In order to understand the required conditions and procedure, read the entire upgrade guide before applying the listed steps. The upgrade process disrupts the provision of the service until the procedure finishes. Due to this disruption, make sure to have a maintenance window.
3.1. Prerequisites to perform the upgrade
This section describes the required configurations to upgrade 3scale from 2.11 to 2.12 in an operator-based installation.
- An OpenShift Container Platform (OCP) 4.6, 4.7, 4.8, 4.9, or 4.10 cluster with administrator access.
- 3scale 2.11 previously deployed via the 3scale operator.
Make sure the latest CSV of the
threescale-2.11channel is in use. To check it:- If the approval setting for the subscription is automatic you should already be in the latest CSV version of the channel.
- If the approval setting for the subscription is manual make sure you approve all pending InstallPlans and have the latest CSV version.
- Keep in mind if there is a pending install plan, there might be more pending install plans, which will only be shown after the existing pending plan has been installed.
3.2. Upgrading from 2.11 to 2.12 in an operator-based installation
To upgrade 3scale from version 2.11 to 2.12 in an operator-based deployment:
- Log in to the OCP console using the account with administrator privileges.
- Select the project where the 3scale-operator has been deployed.
- Click Operators > Installed Operators.
- Select Red Hat Integration - 3scale > Subscription > Channel.
Edit the channel of the subscription by selecting threescale-2.12 and save the changes.
This will start the upgrade process.
Query the pods' status on the project until you see all the new versions are running and ready without errors:
$ oc get pods
Note- The pods might have temporary errors during the upgrade process.
- The time required to upgrade pods can vary from 5-10 minutes.
- After new pod versions are running, confirm a successful upgrade by logging in to the 3scale Admin Portal and checking that it works as expected.
Check the status of the APIManager objects and get the YAML content by running the following command. <myapimanager> represents the name of your APIManager:
$ oc get apimanager <myapimanager> -o yaml
The new annotations with the values should be as follows:
apps.3scale.net/apimanager-threescale-version: "2.12" apps.3scale.net/threescale-operator-version: "0.9.0"
After you have performed all steps, 3scale upgrade from 2.11 to 2.12 in an operator-based deployment is complete.
3.2.1. Upgrading the external MySQL version to 8.0
If your 3scale deployment has the external databases mode enabled and uses MySQL 8.0, set the authentication plugin to mysql_native_password for 3scale 2.12.
Add the following to the MySQL configuration file.
[mysqld] default_authentication_plugin=mysql_native_password
3.2.2. Removing unused MessageBus variables
If your 3scale deployment has the external databases mode enabled, you must manually remove the MESSAGE_BUS_* field from the system-redis secret.
Remove
MESSAGE_BUS_*fields from thesystem-redissecret. If the secret is not managed by external controller, update manually using the following commands:$ oc patch secret/system-redis --type=json -p "[{'op': 'remove', 'path': '/data/MESSAGE_BUS_URL'}]" $ oc patch secret/system-redis --type=json -p "[{'op': 'remove', 'path': '/data/MESSAGE_BUS_NAMESPACE'}]" $ oc patch secret/system-redis --type=json -p "[{'op': 'remove', 'path': '/data/MESSAGE_BUS_SENTINEL_HOSTS'}]" $ oc patch secret/system-redis --type=json -p "[{'op': 'remove', 'path': '/data/MESSAGE_BUS_SENTINEL_ROLE'}]"Verify
MESSAGE_BUS_*fields do not exist. The following command should return empty:$ oc get secret system-redis -o yaml | grep MESSAGE_BUS
3.2.3. Upgrading with external system-database using PostgreSQL 10 and PostgreSQL 13
This upgrade supports external system-database using PostgreSQL 10. You should complete your 3scale upgrade first, then upgrade to PostgreSQL 13.
