One RHEL AI server carried the support assistant for three months. It stopped being enough the week a second team asked for their own model and a nightly job wanted the same GPU that was already serving live traffic. That is the moment a single box turns into a platform problem, and Red Hat OpenShift AI is the platform Red Hat points you at. Before you install anything, it pays to know what the install actually gives you, because turning on the whole thing is a mistake I have already made for you.

Where the assistant outgrew one server

Last part sized a single L40S to serve the tuned Granite 3.1 8B at about 43 concurrent sessions, and that box still works. What it cannot do is hold a second team’s model, run a scheduled retrain without stealing the serving GPU, version the checkpoints three people now depend on, or give anyone a project boundary. OpenShift AI adds those as platform features rather than as scripts you maintain by hand. This part maps the platform so the next few parts can build on it, pipelines in Part 14, distributed training in Part 15, the model registry in Part 16, and serving runtimes in Part 17. Read this one as the floor plan, not the furniture.

One naming point clears up half the confusion. OpenShift AI is the supported, hardened product; Open Data Hub is the upstream community project it is built from, which is why nearly every resource you create carries an opendatahub.io API group even though the product says Red Hat on the tin. Red Hat’s contribution is the integration, the testing, the security backports and the support contract, not the invention of KServe, Kubeflow or Ray, all of which are upstream projects wrapped here into one operator.

Two layers, control plane and applications

OpenShift AI splits cleanly into a management layer and an application layer. At the management layer sits the Red Hat OpenShift AI Operator, a meta operator whose only job is to install and reconcile everything else. It reads two custom resources. A DSCInitialization, usually named default-dsci, sets cluster wide facts like which namespace the applications land in and whether monitoring is on. A DataScienceCluster, usually named default, is the menu, one entry per component with a management state you set to Managed or Removed. Change a single field in that one resource and the operator adds or tears down a whole sub system.

At the application layer are the pieces your data scientists actually touch, the dashboard, notebook workbenches, pipelines, model serving, the registry and the rest. A meta operator, for anyone new to the term, is an operator that manages other operators, so installing one thing installs a dozen controllers underneath it. That convenience is also the trap this part keeps returning to, because Managed is easy to type and each one costs pods.

flowchart TD
  U[Platform admin] --> OP[OpenShift AI Operator]
  OP --> DSCI[DSCInitialization sets namespace and monitoring]
  OP --> DSC[DataScienceCluster picks components]
  DSC --> DASH[Dashboard]
  DSC --> WB[Workbenches]
  DSC --> DSP[Data Science Pipelines]
  DSC --> KS[KServe model serving]
  DSC --> MR[Model Registry]
  DSC --> DW[Ray and Kueue]
  DSC --> TAI[TrustyAI monitoring]

Components in the DataScienceCluster

Here is the reference worth bookmarking, the components you can set Managed, what each one is, the upstream project behind it, and the honest test for whether to turn it on. Keep it next to your DataScienceCluster and default everything to Removed until a project earns the row.

Two rows you may remember from older guides are missing on purpose. The multi model serving platform, modelmeshserving, and the CodeFlare operator are both retired in the 3.x stream, along with the embedded Kueue that used to ship inside the operator. If a tutorial tells you to set modelmeshserving to Managed, it was written for an OpenShift AI that no longer exists. Model versioning here overlaps with the MLflow registry from the Data Science series, covered under experiment tracking and the model registry, and the built in registry is the on cluster equivalent.

Installing the operator and enabling only what you use

Installation is two moves. Install the operator from OperatorHub, then hand it a DataScienceCluster. Start by confirming the operator landed and is healthy, because a DataScienceCluster applied one second too early fails in a way that looks alarming and is not.

# Tested on Red Hat OpenShift AI 3.4 self managed, OpenShift 4 cluster
# 2.25.7 (June 2026) is the last 2.x stream, called out inline where it differs
# 1. confirm the meta operator installed and healthy
$ oc get csv -n redhat-ods-operator
NAME                  DISPLAY                VERSION   PHASE
rhods-operator.3.4.0  Red Hat OpenShift AI   3.4.0     Succeeded

$ oc get dscinitialization,datasciencecluster
NAME                                            AGE
dscinitialization.../default-dsci               4m
NAME                                            AGE
datasciencecluster.../default                   3m

The DSCInitialization is created for you and rarely needs editing, but it is worth reading once so you know where things go. It names the applications namespace and turns monitoring on.

# dsci.yaml, cluster wide setup, usually left as the operator wrote it
apiVersion: dscinitialization.opendatahub.io/v1
kind: DSCInitialization
metadata:
  name: default-dsci
spec:
  applicationsNamespace: redhat-ods-applications
  monitoring:
    managementState: Managed
    namespace: redhat-ods-monitoring

Now the menu. This is the DataScienceCluster for the assistant, and the discipline is in what stays Removed. It serves a model, lets a data scientist work in a notebook, runs a nightly pipeline, versions checkpoints and monitors the endpoint. It does not yet need Ray, Kueue, distributed training, a feature store or Llama Stack, so those stay off until a later part switches them on.

# dsc.yaml, enable only what this assistant uses, leave the rest Removed
apiVersion: datasciencecluster.opendatahub.io/v1
kind: DataScienceCluster
metadata:
  name: default
spec:
  components:
    dashboard:
      managementState: Managed
    workbenches:
      managementState: Managed
    datasciencepipelines:
      managementState: Managed
    kserve:
      managementState: Managed
      defaultDeploymentMode: RawDeployment   # Serverless is retired in 3.x
      serving:
        managementState: Removed             # no service mesh, no knative
    modelregistry:
      managementState: Managed
      registriesNamespace: rhoai-model-registries
    trustyai:
      managementState: Managed
    ray:
      managementState: Removed
    kueue:
      managementState: Removed
    trainingoperator:
      managementState: Removed
    feastoperator:
      managementState: Removed
    llamastackoperator:
      managementState: Removed

Apply that before the operator has finished registering its custom resource definitions and you meet the first honest error of the platform. It reads worse than it is, and the fix is simply to wait.

# applied a beat too early, before the CRDs exist
$ oc apply -f dsc.yaml
error: resource mapping not found for name: "default" namespace: ""
from "dsc.yaml": no matches for kind "DataScienceCluster" in version
"datasciencecluster.opendatahub.io/v1"
ensure CRDs are installed first

# wait for the operator, then apply again
$ oc wait --for=condition=Available deploy/rhods-operator -n redhat-ods-operator
deployment.apps/rhods-operator condition met
$ oc apply -f dsc.yaml
datasciencecluster.../default created

$ oc get datasciencecluster default -o jsonpath='{.status.phase}'
Ready
$ oc get pods -n redhat-ods-applications --no-headers | wc -l
11

Eleven pods for this profile, all controllers, before a single notebook opens or a model serves. That number is the reason the next section exists.

Serving after ModelMesh and Serverless retired

Model serving is where the biggest gap sits between what older material says and what a 2026 cluster does. For years OpenShift AI shipped two serving stacks, ModelMesh for packing many small models onto shared servers, and KServe for one model per deployment. KServe itself ran in a Serverless mode built on Knative and OpenShift Service Mesh, which gave you scale to zero at the price of two extra operators and a cold start on the first request after idle. Both of those are now history. ModelMesh is retired in the 3.x stream, and the KServe Serverless mode was deprecated in 2.25 and removed in 3.0. What remains is KServe RawDeployment, a plain Kubernetes Deployment behind a Gateway, no service mesh required.

There is a real cost to the old path measured in platform surface, not model quality. The chart below counts idle controller pods in the applications namespace for three install profiles, from a bare serving setup to the assistant profile above to a cluster with every component set Managed. Numbers are approximate and move between releases, but the shape is the point.

Where the platform bites

On my first OpenShift AI cluster I set every component to Managed, reasoning that I would rather have things ready than discover a gap mid demo. On a three node cluster that decision pulled the applications namespace past forty pods once workloads and retries were counted, the data science pipelines server sat in CrashLoopBackOff because it wanted object storage I had not created, and the DataScienceCluster reported Progressing for roughly twenty five minutes while KServe, Ray and the training operator all raced to reconcile. Nothing was broken, exactly, but nothing was usable either, and I could not tell healthy from stuck. I set eight of the twelve components back to Removed, reapplied, and the cluster went Ready in under three minutes with a namespace I could actually read. Managed is not free, and a platform you cannot reason about is worse than a missing feature.

Most of what goes wrong at install traces to one of a handful of causes. Keep this lookup near the terminal and a red status becomes a one line change rather than an afternoon.

Mapping the assistant onto OpenShift AI

For the support assistant the platform picture is now concrete. A DataScienceCluster with five components Managed, dashboard, workbenches, pipelines, KServe on RawDeployment and the model registry, plus TrustyAI to watch the endpoint, gives every capability the next five parts need and nothing they do not. Distributed training and GPU sharing arrive when a retrain outgrows one node, and Llama Stack arrives when the assistant gets grounded with retrieval later in the series. Start small, add a row when a project asks for it, and the cluster stays a thing you can hold in your head. That habit matters more here than on a single RHEL AI box, because on a platform every idle controller is a thing someone has to patch and page on.

References

• Red Hat OpenShift AI 2.25, support removals, ModelMesh and Serverless deprecations
• Architecture of OpenShift AI, service and management layers
• Red Hat OpenShift AI 3.4, new features and enhancements

About The Author

Dr. Pranay Jha

Dr. Pranay Jha is a Cloud and AI Consultant with 18+ years of experience in hybrid cloud, virtualization, and enterprise infrastructure transformation. He specializes in VMware technologies, multi-cloud strategy, and Generative AI solutions. He holds a PhD in Computer Applications with research focused on Cloud and AI, has published multiple research papers, and has been a VMware vExpert since 2016 and a VMUG Community Leader.

See author's posts