Upgrade with 60 notebooks and deprecated custom runtimes
A retailer runs IBM Cloud Pak for Data 4.0.1 on OpenShift 4.6 with Watson Studio, Watson Machine Learning, Db2 Warehouse, and 60 Jupyter notebooks. It wants to move to CP4D 4.8. The notebooks use custom Python 3.6 images, and 14 WML models support nightly scoring. Db2 Warehouse holds 2 TB. Eight projects are active, and downstream finance teams depend on the nightly outputs. The change freeze allows a 6-hour maintenance window once per month. The platform team proposes an in-place upgrade of the existing cluster. The data science team says the notebooks will run unchanged. Security requires a supported runtime and CVE scanning. The business cannot accept a missed nightly scoring cycle.
1. Evaluate the in-place upgrade proposal and lay out a safer migration path.
Read the worked answer
An in-place jump from 4.0.1 to 4.8 on OpenShift 4.6 should not be assumed to be a supported single hop. First verify the published upgrade path and OpenShift compatibility; if intermediate CP4D or OpenShift versions are required, an in-place chain multiplies risk and cannot fit a 6-hour window with 2 TB of Db2 and 60 notebooks. A side-by-side migration is safer: build a new 4.8 cluster, back up the old environment, export projects and notebooks, restore Db2 through a supported backup and restore, redeploy WML models, and run both environments in parallel. Pre-stage data copies and test restores before the freeze. Use the maintenance window only for final delta sync and cutover, not for the entire migration. Keep the old cluster intact for rollback. The plan must include validation of catalog metadata, project permissions, connections, and scheduled jobs.
2. What do you do with the custom Python 3.6 images and notebooks that supposedly run unchanged?
Read the worked answer
Do not accept 'unchanged' without evidence. Python 3.6 is end-of-life and the custom images likely contain unsupported or vulnerable packages. Inventory the notebooks for dependencies, rebuild the images on a supported Python runtime available in CP4D 4.8, pin package versions, and run CVE scanning. Execute each notebook in a test project against copied data and compare outputs. Some notebooks may depend on removed APIs, old Spark versions, or filesystem paths; fix those before cutover. If a custom image cannot be rebuilt, use a supported runtime definition and move only the required libraries. Record the validated runtime per notebook. This work belongs before the freeze, because debugging notebook dependencies during a 6-hour cutover is how nightly scoring gets missed.
3. How do you protect the nightly scoring cycle during cutover?
Read the worked answer
Run the old and new scoring paths in parallel before cutover. Deploy the 14 models to the new WML instance, schedule them against the same input snapshot, and compare outputs with tolerances for floating-point differences. Keep the old schedule active until the new outputs are accepted by finance. During the cutover window, pause upstream loads or use a delta file so both environments can be reconciled. Cut over the scheduler only after model deployment, data connections, and credentials are validated. Define a rollback trigger: if the new cycle misses its deadline or output reconciliation fails, re-enable the old schedule and investigate. After cutover, monitor the first two cycles closely and retain the old cluster read-only until sign-off. The 6-hour window is for switching, not for discovering missing model artifacts.