Cloud Pak for Business Automation

 View Only

Best practices and preparing to upgrade from CP4BA 21.0.3-IF031 or later to CP4BA 24.0.0

By SCOTT Nguyen posted Thu July 11, 2024 10:06 PM

  

Cloud Pak for Business Automation 24.0.0 recently GA as the new “long term service release” replacing version 21.0.3. This is the long awaited release for many 21.0.3 customers as it allows them to directly upgrade from 21.0.3 to 24.0.0. The 24.0.0 release not only provide the next long term support, but many new features and enhancements customers have been waiting for. Additionally, this new release have architectural changes that will bring the 21.0.3 customers to the current Cloud Pak 3.0 architecture and the support of private catalog. These changes will significantly improve stability, day-2 operations, and reduction in footprint are just some of benefits of upgrading to 24.0.0. As part of the upgrade process, the automation script help guide customers to the ideal architecture and deployment configuration for CP4BA 24.0.0. Here are some key best practices and recommendations as part of the upgrade:

  • Move to namespace scoped (dedicated instance) of Cloud Pak foundational service (CPfs)

  • Move to using namespace scoped (private catalog)

Note: Direct upgrade support for 22.0.2 will be supported in 24.0.0 IF001. More information can be found in the Knowledge Center documentation.

This blog post will walk through some of the most common upgrade paths that the customer might have. For complete list of upgrade path, please refer to the Knowledge Center documentation.

Definition:

  • All-namespaces scope: You have an all-namespace scope deployment when all the operators (CP4BA-related operators, and CPfs operators) are resided in “openshift-operators” namespace, and CPFS operands are typically resided in ibm-common-services namespace and CP4BA operands are resided in CP4BA namespace.

  • Namespace-scope: This term is used whenever operators and operands are resided in the custom, user-defined namespace.

  • Cluster-scope: CPfs operands are shared in the entire cluster. The CPfs operands are deployed in “ibm-common-services” namespace.

  • Global catalog: Catalog sources are resided in “openshift-marketplace” namespace.

  • Private catalog: Catalog sources are resided in user-defined namespace.

High-level main upgrade steps:

  1. cp4a-deployment.sh -m upgradeOperator -n <project_name>

  2. cp4a-deployment.sh -m upgradeOperatorStatus -n <project_name>

  3. cp4a-deployment.sh -m upgradeDeployment -n <project_name>

  4. cp4a-deployment.sh -m upgradeDeploymentStatus -n <project_name>

Overall detailed upgrade flow chart:

Some of the more common upgrade paths:

  1. Upgrade from cluster-scope, shared CPfs + global catalog to namespace-scope + private catalog: We HIGHLY recommended customers to move CPfs to namespace-scope and private catalog configuration. The reasons for that are it will offer the most flexibility when you are dealing with multiple CloudPaks, and multiple instances of CP4BA. In this configuration, each instance will host CPfs operators, operands, and catalog in its own namespace. This will allow each instance to upgrade independently without affecting other instances. The drawback for this configuration is that the increase of resources when there are multiple instances of CP4BA.

  2. Upgrade from cluster-scope, shared CPfs + global catalog to cluster-scope, shared CPfs + global catalog: This upgrade path is not currently support. We HIGHLY recommended the customers to use option 1.

  3. Upgrade from a namespace-scope, dedicate CPfs to namespace-scope, dedicate CPfs: There are two scenarios for this path

    • Global catalog to private catalog: We HIGHLY recommend the customers moving to private catalog if they are currently using global catalog. The reason is private catalog provides more flexibility to control the versions of the operator for a particular instance of CP4BA.

    • Private catalog to private catalog: We HIGHLY recommend the customers staying with private catalog if they are currently using private catalog.

Backup:

  1. CP4BA:

    1. https://www.ibm.com/docs/en/cloud-paks/cp-biz-automation/24.0.0?topic=2103-backing-up-your-environments

    2. https://www.ibm.com/docs/en/cloud-paks/cp-biz-automation/24.0.0?topic=2103-backing-up-your-custom-resources

Restore:

  1. CP4BA: https://www.ibm.com/docs/en/cloud-paks/cp-biz-automation/21.0.3?topic=recovery-restoring-your-environments

Important Tips:

  1. ALWAYS have a good back up before starting your upgrade. There will be no rollback supported for this upgrade. The customer needs to restore if they need to revert. Refer to the backup and restore sections above for detail information on backup and restore.

  2. Elasticsearch has been upgraded to Opensearch in CP4BA 24.0.0, therefore you must migrate Elasticsearch’s data to Opensearch if you want to keep existing data. Read the Elasticsearch migration guide, and plan the migration carefully.

  3. Use KC documentation AND the output from the upgrade scripts to help you during the upgrade process. There are several tags from the script’s output that need to be reviewed

    • [INFO]: Informational information generated during the upgrade.

    • [ATTENTION]: Important reminders during the upgrade process.

    • [NEXT ACTIONS]: These are the next step(s) that you must take.

  4. The upgrade script will exit if there is a ibm-operator-catalog CatalogSource exists in the openshift-marketplace namespace. This scenario only occurs if the customer starts installing CP4BA 21.0.3 between the GA version and IF006. We will support this scenario in future fix.

  5. ALWAYS start your upgrade process with

    ./cp4a-deployment.sh -m upgradeOperator -n <project_name>

    and let the prompt guide you through the upgrade process.  And refer back to the documentation when necessary.

We hope this information will help the customers upgrade their CP4BA environment successfully.

0 comments
30 views

Permalink