• If you configure automatic upgrades, when a new version of the Red Hat OpenShift AI Operator is available, Operator Lifecycle Manager (OLM) automatically upgrades the running instance of your Operator without human intervention.

• If you configure manual upgrades, when a new version of the Red Hat OpenShift AI Operator is available, OLM creates an update request.

  A cluster administrator must manually approve the update request to update the Operator to the new version. See Manually approving a pending Operator upgrade for more information about approving a pending Operator upgrade.

• By default, the Red Hat OpenShift AI Operator follows a sequential update process. This means that if there are several minor versions between the current version and the version that you plan to upgrade to, Operator Lifecycle Manager (OLM) upgrades the Operator to each of the minor versions before it upgrades it to the final, target version. If you configure automatic upgrades, OLM automatically upgrades the Operator to the latest available version, without human intervention. If you configure manual upgrades, a cluster administrator must manually approve each sequential update between the current version and the final, target version.

  Red Hat supports the current version and three previous minor versions of OpenShift AI Self-Managed. For more information, see the Red Hat OpenShift AI Self-Managed Life Cycle knowledgebase article.

• When you upgrade OpenShift AI, you should complete the Requirements for upgrading OpenShift AI.
• If you upgrade to OpenShift AI from version 1 (OpenShift Data Science), follow the guidelines in Cleaning up unused resources from version 1 of Red Hat OpenShift AI (OpenShift Data Science).
• Before you can use an accelerator in OpenShift AI, your instance must have the associated accelerator profile. If your OpenShift Container Platform instance has an accelerator, its accelerator profile is preserved after an upgrade. For more information about accelerators, see Working with accelerators.

• Notebook images are integrated into the image stream during the upgrade and subsequently appear in the OpenShift AI dashboard.

  Note

  Notebook images are constructed externally; they are prebuilt images that undergo quarterly changes and they do not change with every OpenShift AI upgrade.

Prerequisites

• You have cluster administrator privileges for your OpenShift Container Platform cluster.
• The Red Hat OpenShift AI Operator is installed.

• Install dependent Operators, including the Red Hat OpenShift Serverless and Red Hat OpenShift Service Mesh Operators. For more information, see Serving large models.
• After the upgrade, you must inspect the default DataScienceCluster object and verify that the value of the managementState field for the kserve component is Managed.

• In Red Hat OpenShift AI version 2.4, the KServe component is a Limited Availability feature. If you enabled the kserve component and created models in version 2.4, then after you upgrade to version 2.5, you must update some OpenShift AI resources as follows:

  1. Log in as an administrator to the OpenShift Container Platform cluster where OpenShift AI 2.5 is installed:

     $ oc login

  2. Update the DSC Initialization resource:

     $ oc patch $(oc get dsci -A -oname) --type='json' -p='[{"op": "replace", "path": "/spec/serviceMesh/managementState", "value":"Unmanaged"}]'

  3. Update the Data Science Cluster resource:

     $ oc patch $(oc get dsc -A -oname) --type='json' -p='[{"op": "replace", "path": "/spec/components/kserve/serving/managementState", "value":"Unmanaged"}]'

  4. Update the InferenceServices CRD:

     $ oc patch crd inferenceservices.serving.kserve.io --type=json -p='[{"op": "remove", "path": "/spec/conversion"}]'

  5. Optionally, restart the Operator pod.

     For more information about these configurations, see Installing KServe.

• If you deployed a model by using KServe in OpenShift AI version 2.4, when you upgrade to version 2.5 the model does not automatically appear in the OpenShift AI dashboard. To update the dashboard view, redeploy the model by using the OpenShift AI dashboard.

• For OpenShift Container Platform clusters that rely on self-signed certificates, you can add those self-signed certificates to a cluster-wide Certificate Authority (CA) bundle (ca-bundle.crt) and use the CA bundle in Red Hat OpenShift AI.
• You can use self-signed certificates in a custom CA bundle (odh-ca-bundle.crt) that is separate from the cluster-wide bundle.

Prerequisites

• You have admin access to the DSCInitialization resources in the OpenShift Container Platform cluster.
• You installed the OpenShift command line interface (oc) as described in Get Started with the CLI.
• You upgraded Red Hat OpenShift AI from version 2.7 or earlier. If you are working in a new installation of Red Hat OpenShift AI, see Adding a CA bundle.

Verification

• If you are using a cluster-wide CA bundle, run the following command to verify that all non-reserved namespaces contain the odh-trusted-ca-bundle ConfigMap:

  $ oc get configmaps --all-namespaces -l app.kubernetes.io/part-of=opendatahub-operator | grep odh-trusted-ca-bundle

• If you are using a custom CA bundle, run the following command to verify that a non-reserved namespace contains the odh-trusted-ca-bundle ConfigMap and that the ConfigMap contains your customCABundle value. In the following command, example-namespace is the non-reserved namespace and examplebundle123 is the customCABundle value.

  $ oc get configmap odh-trusted-ca-bundle -n example-namespace -o yaml | grep examplebundle123