Upgrade the Cloud Pak for Business Automation operators based on
your deployment setup. You can upgrade the Cloud Pak for Business Automation operators in both
online and air-gap environments.
Before you begin
It is important to check the following before you start the upgrade.
- Your current Cloud Pak for Business Automation deployment version
must be 21.0.3-IF031 or later to upgrade directly to 24.0.0-IF004 or later. If
you are on an earlier version, you must upgrade to 21.0.3-IF031 or a later version.
- Your current Cloud Pak for Business Automation deployment version
must be 22.0.2-IF006 to upgrade directly to 24.0.0-IF004 or later. If
you are on an earlier version, you must upgrade to 22.0.2-IF006.
- Download
cert-kubernetes
to a Linux®
based machine (RHEL or macOS) to update the catalog sources for the new release. All the
installation and upgrade artifacts are contained in the cert-kubernetes
repository.
It is recommended to use the latest interim fix of the release, but if you do need a previous
version then you can find them all in the Cloud Pak for Business Automation download document.
Tip: Use the move right arrow

in the
24.0.0 release to find all
the available interim fixes.
To download the cert-kubernetes
repository.
- Open the Cloud Pak for Business Automation
download
document, find the card for the latest 24.0.0 interim fix, click
Cert Kubernetes, and then select and copy the displayed command.
Note: It is
recommended to upgrade to the latest 24.0.0 interim fix. If you
want to deploy 24.0.0 GA or 24.0.0-IF001, make sure
that you clone the latest version of the respective branches from the
cert-kubernetes
repository to get all the latest fixes.
- Run the copied
git clone
command to download the files.
If your Cloud Pak for Business Automation
includes Business Automation Insights,
choose a migration strategy before you start your migration. For more information, see Installing OpenSearch and migrating Elasticsearch data.
About this task
Use the script -h
parameter for more information about the script in
the cert-kubernetes/scripts folder.
./cp4a-deployment.sh -h
Note: If you plan to use a non-administrator user to upgrade the operator, you must add the user to
the
ibm-cp4a-operator
role.
oc adm policy add-role-to-user ibm-cp4a-operator <user_name>
The following scenarios to upgrade
Cloud Pak foundational services are supported:
- Cluster-scoped Cloud Pak foundational services
instance in
All Namespaces
to cluster-scoped instance of Cloud Pak foundational services in All
Namespaces
.
- Cluster-scoped Cloud Pak foundational services
instance to namespace-scoped instance of Cloud Pak foundational services.
- Namespace-scoped Cloud Pak foundational services
instance to namespace-scoped instance of Cloud Pak foundational services.
Note: You can configure Cloud Pak foundational services for different environments
like development, test, QA, and production. Your company might have different organizations within
it and they need to configure a different identity provider for each department. However, it is
recommended to upgrade the Cloud Pak foundational services instance to namespace-scoped
with your Cloud Pak deployments. Namespace-scoped instances provide more flexibility.
Procedure
-
Log in to the target cluster from a client.
oc login https://<CLUSTERIP>:<port> -u <ADMINISTRATOR>
- Change the directory to the scripts folder
under cert-kubernetes/scripts.
- Run the
cp4a-deployment.sh
script
from cert-kubernetes in the upgradeOperator
mode.
./cp4a-deployment.sh -m upgradeOperator -n <project_name>
Where
<project_name> is the target namespace.
Note: When you run the script, the script output displays some details. Steps that are tagged as:
- [INFO]: Provides details of the actions that the script takes.
- [ATTENTION]: Provides important details that you need to know or do during the
upgrade.
- [NEXT ACTION]: Provides the commands or script that you need to run to proceed
with upgrade.
- If the script detects Elasticsearch and Business Automation Insights, the script then asks
if you completed the migration from Elasticsearch to OpenSearch. Select
No if you did not complete the migration and then go to Installing OpenSearch and migrating Elasticsearch data. Select Yes if you
completed migration from Elasticsearch to OpenSearch.
Remember: Business Automation Insights uses
Elasticsearch, and so does
Process Federation Server. If you have either of
these components in the cluster and you want to upgrade them, then you must migrate from Elasticsearch to OpenSearch.
Note: If your
Cloud Pak for Business Automation includes
IBM Business Automation Workflow without Business Automation Insights, you do not need to
migrate Elasticsearch to
OpenSearch because
Process Federation Server is removed in the
upgrade. If you want to continue to use Process Federation Server after the upgrade, then you do
need to migrate your Elasticsearch data.
- If the script detects Elasticsearch and no Business Automation Insights component, then the
script asks if you are planning to use Process Federation Server after the upgrade and if you
want to do the migration of Elasticsearch to OpenSearch?
(
Yes/No
).
- If you select
Yes
, the script asks if you completed the migration from Elasticsearch to OpenSearch. If you did not complete
the migration select No
, and then go to Installing OpenSearch and migrating Elasticsearch data. If you completed the migration from Elasticsearch to OpenSearch, select
Yes.
- If you select
No
, continue to upgrade the CP4BA operators without migrating
Elasticsearch.
After you run the ./cp4a-deployment.sh -m upgradeOperator -n
<project_name>
command, the script detects where you installed the
Cloud Pak foundational services and informs you if
the Cloud Pak foundational services instance is in
cluster-scoped or namespace-scoped.
The script then checks whether your Cloud Pak for Business Automation deployment includes
components from IBM FileNet® Content
Manager.
The following table shows the scenarios when you need to run the pre-upgrade script.
Table 1. Scenarios to run the pre-upgrade
script
Migration mode |
Do you need to run the pre-upgrade script? |
Namespace-scoped to namespace-scoped |
Yes |
Cluster-scoped to namespace-scoped |
No |
The script shows the following message if your
Cloud Pak foundational services and if the
Cloud Pak for Business Automation is installed in
All
Namespaces
.
Not found cp-console-iam-provider/cp-console-iam-idmgmt routes in the project "ibm-common-services", you need to run ./cp4a-pre-upgrade-and-post-upgrade-optional.sh pre-upgrade first,
and then rerun ./cp4a-deployment.sh -m upgradeOperator -n <project_name>.
If the script detects components from
IBM FileNet Content
Manager, the script informs you to run
the pre-upgrade script. For more information, see
Running the pre-upgrade script for updating the directory provider in ACCE.
Note: After
you complete running the pre-upgrade script to update the directory provider in ACCE, you need to
run the
./cp4a-deployment.sh -m upgradeOperator -n
<project_name>
script again to continue with upgrading the operators.
The script then checks whether you completed the pre-upgrade task and shows the following
message.
Found cp-console-iam-provider/cp-console-iam-idmgmt routes in the project
"<cp4ba_ns>".
If your Cloud Pak foundational services is
installed in a cluster-scoped instance (and it is not an All Namespaces
deployment), then the script shows the message that it is migrating the Cloud Pak foundational services to a namespace-scoped
instance. If your Cloud Pak foundational services is
already installed in a namespace-scoped instance, then your Cloud Pak foundational services remains in the
namespace-scoped instance. If your deployment is already in All Namespaces
, then it
remains in the All Namespaces
(cluster-scoped) instance.
- Switching global catalog namespace to private catalog namespace (recommended)
If your instance is using a global catalog namespace (and it is not an All
Namespaces
deployment), then the script asks whether to switch from global catalog
namespace to private catalog namespace. It is recommended to switch to a private catalog namespace.
A private catalog namespace uses the same target namespace as the Cloud Pak for Business Automation instance, which
means a private catalog namespace can be updated without impacting other Cloud Pak for Business Automation instances on the
same cluster. A global catalog namespace uses the openshift-marketplace
namespace
and is shared by the Cloud Pak for Business Automation instances on the
same cluster.
When you answer Yes to the script prompt Do you want to deploy
CP4BA using private catalog? (recommended), then the upgrade script automatically
includes the --enable-private-catalog
parameter to switch your global catalog
namespace to a private catalog namespace.
Note: If you have All Namespaces
deployment, you cannot switch to a private
catalog.
- Stop the IBM Content
Search Services index
dispatcher.
If your Cloud Pak for Business Automation
includes IBM Content
Search Services,
you must disable CBRdispatcher
for IBM FileNet Content
Manager and IBM Business Automation Workflow.
- Log in to the Administration Console for Content Platform Engine.
- In the navigation pane, select the domain icon.
- In the edit pane, click the Text Search Subsystem tab and clear the
Enable indexing checkbox.
- Click Save to save your changes.
For more information, see Stopping the IBM Content Search Services index
dispatcher.
- Optional: Run the following script to check the status of the Cloud Pak for Business Automation operators. Use the
cp4a-deployment.sh script in
upgradeOperatorStatus
mode to
check the status of the operators and dependencies.
./cp4a-deployment.sh -m upgradeOperatorStatus -n <project_name>
Where <project_name> is the target namespace.
The script output shows that each of the operators is in the phase of Succeeded
and then shows CP4BA operators upgraded successfully
.
What to do next
Go to and complete the steps in Upgrading your IBM Cloud Pak deployment.