Chapter 8. Upgrading self-service automation portal
To ensure that your self-service automation portal deployment has the latest features and fixes, you must upgrade the plug-in registry and Helm chart to the latest versions.
8.1. self-service automation portal version compatibility Copy linkLink copied to clipboard!
When upgrading self-service automation portal, ensure version compatibility between the Helm chart, plug-in bundle, and Ansible Automation Platform version to avoid installation or upgrade failures.
8.1.1. Version components Copy linkLink copied to clipboard!
A self-service automation portal deployment consists of three version-dependent components:
- Helm chart version
-
The version of the self-service automation portal Helm chart deployed in OpenShift Container Platform. Example:
2.1.0 - Plug-in bundle version
-
The version of the Ansible plug-ins setup bundle downloaded from the Red Hat Customer Portal. Example:
self-service-automation-portal-plugins-2.1.0.tar.gz - Ansible Automation Platform version
-
The version of Ansible Automation Platform that self-service automation portal connects to. Example:
2.6
8.1.2. Version alignment requirements Copy linkLink copied to clipboard!
For a successful self-service automation portal upgrade:
The Helm chart version and plug-in bundle version must have matching major and minor versions. The patch version can differ, but the plug-in bundle patch version must be equal to or greater than the Helm chart patch version.
Example: Plug-in bundle version
2.1.1is compatible with Helm chart version2.1.0, but plug-in bundle version2.0.0is not compatible with Helm chart version2.1.0.The self-service automation portal version must be compatible with your Ansible Automation Platform version.
See the Ansible Automation Platform Life Cycle for version compatibility information.
8.1.3. Common version mismatch scenarios Copy linkLink copied to clipboard!
The following scenarios can cause upgrade failures:
- Plug-in bundle and Helm chart mismatch
-
If you download plug-in bundle version
2.0.0but upgrade to Helm chart version2.1.0, the installation fails because the major.minor versions do not match. Similarly, if the plug-in bundle patch version is lower than the Helm chart patch version, you might encounter compatibility issues. - Stale plug-in bundle
- If you download a plug-in bundle, and a new version is released before you complete the installation, you might install an outdated bundle with a newer Helm chart. This causes version mismatch errors during deployment.
8.1.4. Best practices for version management Copy linkLink copied to clipboard!
To avoid version mismatch issues during upgrades:
- Identify your target version before starting the upgrade process. Check the Red Hat Ansible Automation Platform Product Software downloads page for the latest available versions.
- Download the plug-in bundle and upgrade the Helm chart in the same maintenance window to minimize the risk of version drift between download and installation.
-
Verify the plug-in bundle version before extracting it. Check that the filename major.minor version (for example,
2.1inself-service-automation-portal-plugins-2.1.1.tar.gz) matches your target Helm chart major.minor version. Ensure that the plug-in bundle patch version is equal to or greater than the Helm chart patch version. - Keep a record of your current self-service automation portal version. Document the versions of all three components (Helm chart, plug-ins, Ansible Automation Platform) to simplify future upgrades and troubleshooting.
8.2. Download plug-ins and push to the registry Copy linkLink copied to clipboard!
To provide Ansible plug-ins to Red Hat Developer Hub, download the setup bundle and push the extracted files to a local Red Hat OpenShift registry.
By setting up a centralized httpd service, you can access these plug-in files through Helm chart configuration.
Procedure
Create a directory on your local machine to store the plug-in files.
mkdir /path/to/<ansible-backstage-plugins-local-dir>Set an environment variable
$DYNAMIC_PLUGIN_ROOT_DIRto represent the directory path.export DYNAMIC_PLUGIN_ROOT_DIR=/path/to/<ansible-backstage-plugins-local-dir>- Download the setup bundle. In a browser, navigate to the Red Hat Ansible Automation Platform Product Software downloads page. and select the Product Software tab.
Click Download now next to Ansible self-service automation portal Setup Bundle to download the latest version of the plug-ins.
The format of the filename is
self-service-automation-portal-plugins-x.y.z.tar.gz.Substitute the Ansible plug-ins release version, for example
2.0.0, forx.y.z.Extract the contents to
$DYNAMIC_PLUGIN_ROOT_DIR:$ tar --exclude='*code*' -xzf self-service-automation-portal-plugins-x.y.z.tar.gz -C $DYNAMIC_PLUGIN_ROOT_DIRVerify that the extracted files are in the
$DYNAMIC_PLUGIN_ROOT_DIRdirectory:ls $DYNAMIC_PLUGIN_ROOT_DIRYou should see the following files:
ansible-plugin-backstage-rhaap-dynamic-x.y.z.tgz ansible-plugin-backstage-rhaap-dynamic-x.y.z.tgz.integrity ansible-plugin-scaffolder-backend-module-backstage-rhaap-dynamic-x.y.z.tgz ansible-plugin-scaffolder-backend-module-backstage-rhaap-dynamic-x.y.z.tgz.integrityThe files with the .integrity file type contain the plug-in SHA value.
- Create an httpd service as part of your OpenShift project:
oc new-build httpd --name=plugin-registry --binary
oc start-build plugin-registry --from-dir=$DYNAMIC_PLUGIN_ROOT_DIR --wait
oc new-app --image-stream=plugin-registry
Verification
Run the following command to verify that the plug-in registry deployed correctly:
oc exec $(oc get pods -l deployment=plugin-registry -o jsonpath='{.items[0].metadata.name}') -- ls -l /opt/app-root/src- Confirm that the required tarball files are in the plug-in registry.
Helm chart configuration When you configure the Helm chart, set redhat-developer-hub.global.pluginMode to tarball:
redhat-developer-hub:
global:
pluginMode: tarball
8.3. Updating the plug-in registry Copy linkLink copied to clipboard!
To update the plug-in registry, you must upload your plug-in files to OpenShift, and start a new build of the registry.
Prerequisites
- You have downloaded the plug-in TAR files for self-service automation portal.
-
You have set an environment variable, for example
$DYNAMIC_PLUGIN_ROOT_DIR, to represent the path to the local directory where you have stored the TAR files.
Procedure
- In a terminal, log in to your OpenShift Container Platform instance.
Open your OpenShift project for self-service automation portal.
$ oc project <YOUR_SELF_SERVICE_AUTOMATION_PORTAL_PROJECT>Find the name of your current plug-in registry build configuration:
$ oc get buildconfig-
From the output, identify the correct build configuration name, for example
aap-self-service-plugins. Run the following command to start a new build in in your OpenShift project.
$ oc start-build <build_config_name> --from-dir=$DYNAMIC_PLUGIN_ROOT_DIR --wait-
The command assumes that
$DYNAMIC_PLUGIN_ROOT_DIRrepresents the directory for your TAR files. Replace this in the command if you have chosen a different environment variable name. -
Replace
<build_config_name>with the build configuration name you identified.
When the build starts, the following message is displayed:
Uploading directory "/path/to/dynamic_plugin_root" as binary input for the build ... Uploading finished-
The command assumes that
Verification
- Open the Topology view in the Developer perspective for your project in the OpenShift web console.
- Select the plugin registry icon to open the plugin-registry details pane.
-
In the Pods section of the plugin-registry details pane, select View logs for the new build pod. The format for the pod name is
<build_config_name>-<build_number>-build. - Click the terminal tab and log in to the container.
-
In the terminal, run
lsto view the TAR files in the plugin registry. - Verify that the new TAR files have been uploaded.
8.4. Updating the self-service automation portal version numbers for a Helm installation Copy linkLink copied to clipboard!
After you have updated your plug-in registry for your self-service automation portal project on your OpenShift Container Platform instance, you must update the Helm chart with the new versions of your plug-ins files.
You can update the Helm chart from the command line using helm commands, or from the OpenShift web console.
For upgrades in air-gapped or disconnected environments, the standard procedure cannot be used directly. You must first mirror the necessary container images to your local registry and prepare the Helm chart for offline use.
For detailed instructions on this process, see the Installing the self-service automation portal in an air-gapped environment section of Installing self-service automation portal.
Procedure
Update the Helm chart from the command line:
- In a terminal, log in to your OpenShift instance.
- Open your OpenShift Project that has your self-service automation portal installation.
Run the following command to ensure your Helm repository is up to date:
$ helm repo updateFind the latest version of the Helm chart:
$ helm search repo openshift-helm-charts/redhat-rhaap-portalUpgrade the Helm release:
$ helm upgrade <release_name> openshift-helm-charts/redhat-rhaap-portal --version <chart_version>Replace
<release_name>with the name of your Helm release and<chart_version>with the new Helm chart version number you identified in the previous step.
Update the Helm chart using the OpenShift web console:
- In a browser, log in to your OpenShift Container Platform web console.
- Switch to the Developer perspective.
- Ensure you are in the OpenShift Project that has your self-service automation portal Helm deployment.
- From the navigation menu, Select Helm.
- Find your existing self-service automation portal deployment in the list of Helm releases and click its name.
-
Select
. - In the Upgrade pane, select the version that you want to upgrade to from the Chart Version dropdown list.
- Review the YAML configuration to ensure your custom values are preserved.
- Click to begin the upgrade.
Verification
After the upgrade completes, verify that the updated self-service automation portal instance is running: . In the OpenShift Container Platform web console, navigate to the Topology view for your project. . Check that the self-service automation portal instance is available and that all associated pods are in a Running state.
8.5. Troubleshooting self-service automation portal upgrades Copy linkLink copied to clipboard!
You might encounter issues during self-service automation portal upgrades. The following sections describe common problems and their solutions.
8.5.1. Plug-in version mismatch errors Copy linkLink copied to clipboard!
Symptom: After you upgrade the Helm chart, self-service automation portal pods fail to start with errors indicating that plug-in files cannot be loaded or have incorrect versions.
Cause: The plug-in bundle major.minor version does not match the Helm chart major.minor version, or the plug-in bundle patch version is lower than the Helm chart patch version.
Solution:
Check your current plug-in bundle version:
oc exec $(oc get pods -l deployment=plugin-registry -o jsonpath='{.items[0].metadata.name}') -- \ ls -l /opt/app-root/src | grep ansible-pluginThe version number appears in the plug-in file names.
Identify your Helm chart version:
helm list -n <namespace>Look for your self-service automation portal release and note the chart version.
If the versions do not match:
- Download the correct plug-in bundle version from the Red Hat Ansible Automation Platform Product Software downloads page.
- Update your plug-in registry following the procedure in Section 8.2, “Download plug-ins and push to the registry”.
- Wait for the self-service automation portal pods to restart automatically.
8.5.2. Pods stuck in CrashLoopBackOff after upgrade Copy linkLink copied to clipboard!
Symptom: After you upgrade, self-service automation portal pods repeatedly restart and show a status of CrashLoopBackOff.
Cause: Database schema migration failed, or the upgrade introduced configuration errors.
Solution:
Check the pod logs for specific error messages:
oc logs -n <namespace> <pod_name> --previousIf you see database migration errors:
Verify that your database is accessible:
oc exec -it -n <namespace> <pod_name> -- pg_isready -h <database_host>Check database connection secrets:
oc get secret -n <namespace> | grep -i database- If you use an external database, verify that the database user has the required permissions.
If you see configuration errors:
Review your Helm values for syntax errors:
helm get values <release_name> -n <namespace>- Compare with your previous working configuration to identify changes.
- Revert problematic configuration changes and upgrade again.
8.5.3. self-service automation portal upgrade considerations for Ansible Automation Platform 2.4 to 2.6 Copy linkLink copied to clipboard!
Consider the following when you upgrade self-service automation portal from Ansible Automation Platform 2.4 to Ansible Automation Platform 2.6:
Upgrade your Ansible Automation Platform instance to version 2.6 before you upgrade self-service automation portal.
The self-service automation portal version that is compatible with Ansible Automation Platform 2.6 requires Ansible Automation Platform 2.6 features for full functionality.
- Review the Ansible Automation Platform 2.6 release notes for breaking changes that affect self-service automation portal.
Back up your existing self-service automation portal configuration before you upgrade:
helm get values <release_name> -n <namespace> > backup-values.yamlAfter you upgrade, verify that OAuth authentication still functions:
- Check that your OAuth application in Ansible Automation Platform is configured correctly.
- Test the sign-in functionality.
- If authentication fails, verify that the OAuth redirect URL matches your upgraded deployment URL.
- Update any custom templates or configurations to use syntax that is compatible with the new self-service automation portal version.
8.5.4. Helm upgrade fails with a release not found error Copy linkLink copied to clipboard!
Symptom: Running helm upgrade returns an error stating that the release cannot be found.
Cause: The Helm release name or namespace is incorrect.
Solution:
List all Helm releases in your cluster:
helm list --all-namespaces- Identify the correct release name and namespace for your self-service automation portal deployment.
Run the upgrade command with the correct parameters:
helm upgrade <correct_release_name> openshift-helm-charts/redhat-rhaap-portal \ --version <target_version> \ -n <correct_namespace>
8.5.5. Custom values lost after upgrade Copy linkLink copied to clipboard!
Symptom: After you upgrade, your custom configurations (such as custom CA certificates, OAuth settings, or RBAC configurations) are no longer applied.
Cause: The upgrade command did not include your custom values file, or the values were overwritten.
Solution:
Before you upgrade, export your current values:
helm get values <release_name> -n <namespace> > current-values.yamlWhen you upgrade, specify your values file:
helm upgrade <release_name> openshift-helm-charts/redhat-rhaap-portal \ --version <target_version> \ -f current-values.yaml \ -n <namespace>After you upgrade, verify that your custom values are still applied:
helm get values <release_name> -n <namespace>
Additional resources