Upgrading OpenShift AI Self-Managed
Upgrade OpenShift AI on OpenShift
Abstract
Preface
As a cluster administrator, you can configure either automatic or manual upgrade of the OpenShift AI Operator.
Chapter 1. Overview of upgrading OpenShift AI Self-Managed
As a cluster administrator, you can configure either automatic or manual upgrades for the Red Hat OpenShift AI Operator.
For information about upgrading OpenShift AI as self-managed software on your OpenShift cluster in a disconnected environment, see Upgrading OpenShift AI Self-Managed in a disconnected environment.
- 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.
To view information regarding the supported and tested upgrade paths for Red Hat OpenShift AI, see Red Hat OpenShift AI Upgrade Path Information.
For information about OpenShift AI Self-Managed release types and supported versions, see the Red Hat OpenShift AI Self-Managed Life Cycle Knowledgebase article.
- Before you upgrade OpenShift AI, you should complete the Requirements for upgrading OpenShift AI.
Before you can use an accelerator in OpenShift AI, your instance must have the associated accelerator profile or hardware profile. If your OpenShift instance has an accelerator, its accelerator profile or hardware profile is preserved after an upgrade. For more information about accelerators, see Working with accelerators.
ImportantBy default, hardware profiles are hidden in the dashboard navigation menu and user interface, while accelerator profiles remain visible. In addition, user interface components associated with the deprecated accelerator profiles functionality are still displayed. To show the Settings → Hardware profiles option in the dashboard navigation menu, and the user interface components associated with hardware profiles, set the
disableHardwareProfilesvalue tofalsein theOdhDashboardConfigcustom resource (CR) in OpenShift. For more information about setting dashboard configuration options, see Customizing the dashboard.Workbench images are integrated into the image stream during the upgrade and subsequently appear in the OpenShift AI dashboard.
NoteWorkbench images are constructed externally; they are prebuilt images that undergo quarterly changes and they do not change with every OpenShift AI upgrade.
Additional resources
Chapter 2. Configuring the upgrade strategy for OpenShift AI
As a cluster administrator, you can configure either an automatic or manual upgrade strategy for the Red Hat OpenShift AI Operator.
By default, the Red Hat OpenShift AI Operator follows a sequential update process. This means that if there are several versions between the current version and the version that you intend to upgrade to, Operator Lifecycle Manager (OLM) upgrades the Operator to each of the intermediate 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.
For information about supported versions, see the Red Hat OpenShift AI Self-Managed Life Cycle Knowledgebase article.
Prerequisites
- You have cluster administrator privileges for your OpenShift cluster.
- The Red Hat OpenShift AI Operator is installed.
Procedure
- Log in to the OpenShift cluster web console as a cluster administrator.
- In the Administrator perspective, in the left menu, select Operators → Installed Operators.
- Click the Red Hat OpenShift AI Operator.
- Click the Subscription tab.
Under Update approval, click the pencil icon and select one of the following update strategies:
-
Automatic: New updates are installed as soon as they become available. -
Manual: A cluster administrator must approve any new update before installation begins.
-
- Click Save.
Additional resources
- For more information about the subscription channels that are available in version 2 of the Red Hat OpenShift AI Operator, see Installing the Red Hat OpenShift AI Operator.
- For more information about upgrading Operators that have been installed by using OLM, see Updating installed Operators in the OpenShift documentation.
Chapter 3. Requirements for upgrading OpenShift AI
When upgrading OpenShift AI, you must complete the following tasks.
Check the components in the DataScienceCluster object
When you upgrade Red Hat OpenShift AI, the upgrade process automatically uses the values from the previous DataScienceCluster object.
After the upgrade, you should inspect the DataScienceCluster object and optionally update the status of any components as described in Updating the installation status of Red Hat OpenShift AI components by using the web console.
New components are not automatically added to the DataScienceCluster object during upgrade. If you want to use a new component, you must manually edit the DataScienceCluster object to add the component entry.
If you are upgrading OpenShift AI on a cluster running in FIPS mode, any custom container images for data science pipelines must be based on UBI 9 or RHEL 9. This ensures compatibility with FIPS-approved pipeline components and prevents errors related to mismatched OpenSSL or GNU C Library (glibc) versions.
Migrate from embedded Kueue to Red Hat build of Kueue
The embedded Kueue component for managing distributed workloads is deprecated. OpenShift AI now uses the Red Hat build of Kueue Operator to provide enhanced workload scheduling for distributed training, workbench, and model serving workloads.
Before upgrading OpenShift AI, check if your environment is using the embedded Kueue component by verifying the spec.components.kueue.managementState field in the DataScienceCluster custom resource. If the field is set to Managed, you must complete the migration to the Red Hat build of Kueue Operator to avoid controller conflicts and ensure continued support for queue-based workloads.
As part of the migration to Red Hat build of Kueue, you must manually delete the following legacy Kueue CRDs:
-
cohorts.kueue.x-k8s.io/v1alpha1 -
topologies.kueue.x-k8s.io/v1alpha1
If you have existing instances of these CRDs, you must manually back up their data, delete the instances, and recreate them using the v1beta1 API after the upgrade. If you do not complete these steps, the Kueue Operator enters a failed reconciliation loop, resulting in a Not Ready status for the DataScienceCluster. To avoid this conflict, ensure no active workloads depend on the legacy Kueue resources.
For more information, see Red Hat Build of Kueue 1.2 installation or upgrade fails with Kueue CRD reconciliation error.
This migration requires OpenShift 4.18 or later. For more information, see Migrating to the Red Hat build of Kueue Operator.
Address KServe requirements
For the KServe component, which is used by the single-model serving platform to serve large models, you must meet the following requirements:
- To fully install and use KServe, you must also install Operators for Red Hat OpenShift Serverless and Red Hat OpenShift Service Mesh and perform additional configuration. For more information, see Serving large models.
-
If you want to add an authorization provider for the single-model serving platform, you must install the
Red Hat - AuthorinoOperator. For more information, see Adding an authorization provider for the single-model serving platform. -
If you have not enabled the KServe component (that is, you set the value of the
managementStatefield toRemovedin theDataScienceClusterobject), you must also disable the dependent Service Mesh component to avoid errors. See Disabling KServe dependencies.
Address RAG dependencies
If you plan to deploy Retrieval-Augmented Generation (RAG) workloads by using Llama Stack, you must meet the following requirements:
- You have GPU-enabled nodes available on your cluster and you have installed the Node Feature Discovery Operator and NVIDIA GPU Operator. For more information, see Installing the Node Feature Discovery Operator and Enabling NVIDIA GPUs.
- You have access to storage for your model artifacts.
- You have met the KServe installation prerequisites.
Verify Argo Workflows compatibility
If you use your own Argo Workflows instance for pipelines, verify that the installed version is compatible with this release of OpenShift AI. For details, see Supported Configurations.
Update workflows interacting with OdhDashboardConfig resource
Previously, cluster administrators used the groupsConfig option in the OdhDashboardConfig resource to manage the OpenShift groups (both administrators and non-administrators) that can access the OpenShift AI dashboard. Starting with OpenShift AI 2.17, this functionality has moved to the Auth resource. If you have workflows (such as GitOps workflows) that interact with OdhDashboardConfig, you must update them to reference the Auth resource instead.
Table 3.1. User management resource update
| OpenShift AI 2.16 and earlier | OpenShift AI 2.17 and later | |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
| Admin groups |
|
|
| User groups |
|
|
Check the status of certificate management
You can use self-signed certificates in OpenShift AI.
After you upgrade, check the management status for Certificate Authority (CA) bundles as described in Working with certificates.
Additional resources
Chapter 4. Updating the installation status of Red Hat OpenShift AI components by using the web console
You can use the OpenShift web console to update the installation status of components of Red Hat OpenShift AI on your OpenShift cluster.
If you upgraded OpenShift AI, the upgrade process automatically used the values of the previous version’s DataScienceCluster object. New components are not automatically added to the DataScienceCluster object.
After upgrading OpenShift AI:
-
Inspect the default
DataScienceClusterobject to check and optionally update themanagementStatestatus of the existing components. -
Add any new components to the
DataScienceClusterobject.
Prerequisites
- The Red Hat OpenShift AI Operator is installed on your OpenShift cluster.
- You have cluster administrator privileges for your OpenShift cluster.
Procedure
- Log in to the OpenShift web console as a cluster administrator.
- In the web console, click Operators → Installed Operators and then click the Red Hat OpenShift AI Operator.
- Click the Data Science Cluster tab.
-
On the DataScienceClusters page, click the
default-dscobject. Click the YAML tab.
An embedded YAML editor opens showing the default custom resource (CR) for the
DataScienceClusterobject, similar to the following example:apiVersion: datasciencecluster.opendatahub.io/v1 kind: DataScienceCluster metadata: name: default-dsc spec: components: codeflare: managementState: Removed dashboard: managementState: Removed datasciencepipelines: managementState: Removed kserve: managementState: Removed kueue: managementState: Removed llamastackoperator: managementState: Removed modelmeshserving: managementState: Removed ray: managementState: Removed trainingoperator: managementState: Removed trustyai: managementState: Removed workbenches: managementState: Removed workbenchNamespace: rhods-notebooksIn the
spec.componentssection of the CR, for each OpenShift AI component shown, set the value of themanagementStatefield to eitherManagedorRemoved. These values are defined as follows:- Managed
- The Operator actively manages the component, installs it, and tries to keep it active. The Operator will upgrade the component only if it is safe to do so.
- Removed
- The Operator actively manages the component but does not install it. If the component is already installed, the Operator will try to remove it.
Important- To learn how to install the KServe component, which is used by the single-model serving platform to serve large models, see Installing the single-model serving platform.
-
If you have not enabled the KServe component (that is, you set the value of the
managementStatefield toRemoved), you must also disable the dependent Service Mesh component to avoid errors. See Disabling KServe dependencies. - To learn how to install the distributed workloads feature, see Installing the distributed workloads components.
Click Save.
For any components that you updated, OpenShift AI initiates a rollout that affects all pods to use the updated image.
If you are upgrading from OpenShift AI 2.19 or earlier, upgrade the Authorino Operator to the
stableupdate channel, version 1.2.1 or later.-
Update Authorino to the latest available release in the
tech-preview-v1channel (1.1.2), if you have not done so already. Switch to the
stablechannel:- Navigate to the Subscription settings of the Authorino Operator.
- Under Update channel, click on the highlighted tech-preview-v1.
-
Change the channel to
stable.
- Select the update option for Authorino 1.2.1.
-
Update Authorino to the latest available release in the
Verification
Confirm that there is at least one running pod for each component:
- In the OpenShift web console, click Workloads → Pods.
-
In the Project list at the top of the page, select
redhat-ods-applicationsor your custom applications namespace. - In the applications namespace, confirm that there are one or more running pods for each of the OpenShift AI components that you installed.
Confirm the status of all installed components:
- In the OpenShift web console, click Operators → Installed Operators.
- Click the Red Hat OpenShift AI Operator.
-
Click the Data Science Cluster tab and select the
DataScienceClusterobject calleddefault-dsc. - Select the YAML tab.
In the
status.installedComponentssection, confirm that the components you installed have a status value oftrue.NoteIf a component shows with the
component-name: {}format in thespec.componentssection of the CR, the component is not installed.
- In the OpenShift AI dashboard, users can view the list of the installed OpenShift AI components, their corresponding source (upstream) components, and the versions of the installed components, as described in Viewing installed OpenShift AI components.