CP4D 4.7 Upgrade with a Short Window and a Full Db2 Volume
An enterprise runs Cloud Pak for Data 4.6.4 with Watson Studio, Watson Knowledge Catalog, DataStage, and Db2 on OpenShift 4.12. The platform team must upgrade to CP4D 4.7.x and OpenShift 4.14 within a six-hour maintenance window. The cluster has five worker nodes at 16 vCPU/64 GB; current CPU requests are 68% and memory requests 74%. A prior component upgrade failed with 'quota exceeded' in the cpd-operators namespace, leaving one Watson Studio pod Pending. Db2 uses a 100 GiB PVC that is 91% full. The team has a Velero backup of namespaces but has never restored a CP4D instance. They plan to upgrade OpenShift first, then run the CP4D upgrade in place, and roll back by restoring Velero if anything fails. Security requires no public internet access; images come from a private registry. Identify the flaws and produce a safe upgrade plan.
1. Evaluate the proposed sequence and rollback strategy. What must change?
Read the worked answer
The sequence is directionally right only if the support matrix confirms CP4D 4.7.x supports OpenShift 4.14. Check that first; if not, choose a supported OCP level. Velero is not a CP4D rollback strategy: it can restore namespaces, but CP4D upgrades change CRDs, operators, and Db2 metadata, and there is no downgrade. A failed restore may leave a half-upgraded platform. Instead, take a Db2 backup plus a full export of platform configuration, catalog metadata, and connection secrets, and prove a restore in a non-production namespace.
The six-hour window is too short for OCP, operators, and four operands. Split it into an OCP window and a CP4D window, with a go/no-go after pre-upgrade checks. Mirror all 4.7 images to the private registry and update the image content source policy and catalog sources before the window. Upgrade operators first, then operands in dependency order, validating login, catalog, DataStage, and Db2 after each stage.
2. What capacity and storage actions are required before starting?
Read the worked answer
Before the window, fix storage and quota. Db2 at 91% is a stop-ship: expand the PVC if the storage class supports online expansion; otherwise add a tablespace on a new PVC and rebalance, or archive/purge with a Db2 backup in place. Resolve the Pending Watson Studio pod by checking the ResourceQuota in its namespace and the cluster's CPU and memory requests. At 68% CPU and 74% memory requested, a rolling upgrade that surges pods will not schedule. Add a worker or raise node size, or lower non-critical requests, targeting at least 25-30% free allocatable memory.
Check quotas in cpd-operators and every operand namespace, not just the failed one. Pre-pull images and verify the private registry pull secret in all namespaces. Validate that the storage class supports the access modes CP4D needs. Do not start until the pre-upgrade check passes and the Db2 backup is verified.
3. Lay out the upgrade runbook in order, including validation and go/no-go checkpoints.
Read the worked answer
Runbook: freeze changes and notify users; take Db2 and metadata backups; verify restore; mirror and pre-pull images; confirm the support matrix; run CP4D pre-upgrade checks. Upgrade OCP, then validate nodes, ingress, and storage. Upgrade the CP4D operator and foundational services, then Watson Studio, WKC, DataStage, and Db2 according to the documented order.
After each operand, check pods, routes, operator status, and a smoke test: SAML login, catalog search and preview, a small DataStage job, and a Db2 query. Record go/no-go at each checkpoint; if a checkpoint fails, stop and fix rather than continuing. Do not attempt a Velero rollback of a partially upgraded platform. If the CP4D control plane fails irrecoverably, rebuild and restore data and metadata from backups. Keep the maintenance window open for validation, and have a communication plan for extending it.