Red Hat field workshop maps the full OpenShift AI 3.4 installation path

Red Hat AI Americas has published a field workshop that treats an OpenShift AI 3.4 deployment as a platform path rather than a single Operator installation. The repository starts with cluster preparation and GPU capacity, then layers in the OpenShift AI control plane, model serving, Models as a Service (MaaS), object storage, data science pipelines and shared GPU scheduling.

Follow the dependency chain

The workshop is intentionally ordered. Cluster setup establishes authentication, RBAC, user-workload monitoring and AWS GPU workers. The next stages install Node Feature Discovery and the NVIDIA GPU Operator, then validate the accelerator stack with sample CUDA pods before OpenShift AI is introduced.

That sequencing matters: the workshop explicitly notes that the OpenShift AI Operator does not provision GPUs. It also scales GPU and non-GPU worker pools because databases, object storage and other platform services need capacity even when inference workloads consume the accelerators.

The dependency section then installs LeaderWorkerSet, JobSet, Kueue, OpenTelemetry, Tempo, Cluster Observability and Connectivity Link components. Only after those pieces are present does the workshop create the OpenShift AI DataScienceCluster, inference and MaaS gateways, PostgreSQL, MLflow, hardware profiles and dashboard configuration.

Know the prerequisites

The authors say the workshop was built and tested on OpenShift 4.20.31 or later, while its product references target OpenShift AI Self-Managed 3.4 and OpenShift Container Platform 4.20. For the Red Hat Demo Platform, the provisioning guide recommends an AWS OpenShift environment with m6a.4xlarge control-plane instances; it warns that smaller control-plane shapes may run out of memory. The guide also says that catalog item is scheduled for retirement and points future workshop versions toward the multi-cloud cluster offering.

Administrators should verify GPU nodes before proceeding, provide enough non-GPU capacity, and ensure the cert-manager-ingress-cert secret exists before configuring the MaaS gateway. OpenShift AI 3.x hardware profiles are another hard dependency for assigning GPU resources; profiles need matching tolerations when accelerator nodes are tainted.

Treat it as a lab, not a production installer

This is a field reference build, not an official product installation contract. Several choices are deliberately workshop-shaped: local HTPasswd users, broad cluster-admin grants, an AWS-specific GPU MachineSet and scripted restarts of Kuadrant components. The cluster-setup guide itself says kubeadmin should not be used in production.

Platform teams should therefore use the repository as an integration map and validation checklist, then replace its lab identity, privilege, sizing and infrastructure assumptions with their own supported designs. Each section links back to official Red Hat and NVIDIA documentation, which should remain the authority for production deployment and support decisions.

What the completed path proves

The final stages deploy a Llama 3.2 1B inference service behind authenticated MaaS access, add NooBaa-backed object storage, run an Iris Kubeflow pipeline, and demonstrate teams borrowing GPU quota through Kueue cohorts. That makes the workshop useful as an end-to-end acceptance path: it verifies not merely that an Operator installed, but that identity, accelerators, serving, storage, pipelines, observability and resource governance work together.