How do upgrades and interim fixes work for BAW on CP4BA compared to fix packs on WebSphere?

Question

On traditional BAW we plan fix pack weekends with Installation Manager and BPMUpdateSystem. How is a new version or an interim fix applied on the Cloud Pak, and how do we roll back?

Answer 1

Upgrades are driven by the operator: you move the operator to a newer channel / version (OLM subscription), then the operator upgrades every component's images and runs the database schema updates itself. Interim fixes are new images of the same version.

1. Read the upgrade path in the CP4BA documentation of the target version (some versions require an intermediate step, e.g. 21.0.3 → 22.0.2 → 23.0.x).
2. Back up: databases, PVCs (PFS / OpenSearch indexes, file stores), the CR and secrets (oc get icp4acluster -o yaml > cr-backup.yaml), and take a Velero / storage snapshot when available.
3. Upgrade the operator: change the subscription channel (oc patch subscription ibm-cp4a-operator ... --channel v24.0) or use the case bundle / cp4a-deployment.sh scripts of the release; the operator pod restarts with the new version.
4. Update the CR to the new appVersion (and any renamed fields the migration notes list); the operator reconciles: pulls new images, runs upgrade jobs for the databases (the container equivalent of BPMUpdateSystem), rolls the StatefulSets one pod at a time.
5. Verify with the CR status conditions (oc get icp4acluster -o jsonpath='{.status.conditions}'), the component versions in the dashboard, and a smoke test.

# interim fix = image tag change, applied by the operator when the CR references the new version / fix
oc get csv -n cp4ba | grep cp4a                        # operator version installed
oc patch icp4acluster icp4adeploy -n cp4ba --type merge -p '{"spec":{"appVersion":"24.0.1"}}'
oc get pods -n cp4ba -w                                # rolling restart
oc logs deploy/ibm-cp4a-operator -n cp4ba -f | grep -i -E "error|failed|upgrade" 

Rollback: there is no "uninstall the fix" - you restore the databases and PVCs from the backup and re-apply the previous CR / operator version; that is why the backup step is mandatory and why upgrades are rehearsed in a non-production namespace with a database copy. Zero-downtime is not offered for workflow upgrades that change schemas; plan a window, but it is minutes of pod rolling instead of a weekend of Installation Manager.

References

• CP4BA documentation - upgrading (operator, custom resource, components)