Treat the OpenShift AI 3.4 installation workshop as a cluster-wide evaluation, not a quickstart

Red Hat AI Americas’ OpenShift AI 3.4 installation workshop is a useful runnable map of the platform. It is not a minimal product install. The repository deliberately carries a cluster from base preparation through NVIDIA enablement, distributed-workload operators, observability, Models as a Service, object storage, pipelines and Kueue demonstrations.

That breadth makes the workshop valuable for evaluation, but it also makes the boundary important: run it on a dedicated lab cluster, not by pointing oc apply -k at a shared environment.

Check the assumptions first

The top-level guide says the material was built and tested with OpenShift 4.20.31 or later and recommends the Red Hat Demo Platform’s AWS open environment with m6a.4xlarge control-plane instances. The cluster setup then creates an AWS GPU MachineSet and scales both GPU and ordinary workers to two nodes.

This is therefore an AWS-shaped capacity plan, not a portable sizing prescription. Teams evaluating on another infrastructure provider should replace the MachineSet step and confirm storage classes, GPU provisioning and non-GPU headroom before continuing.

The sequence also changes cluster-scoped services. It replaces OAuth configuration with an HTPasswd provider, creates a group bound to cluster-admin, enables user-workload monitoring and installs operators in cluster namespaces. Those are administrator operations with a larger blast radius than an application-namespace tutorial.

Bound the security exposure

The workshop’s credential generator creates admin/admin and dev/dev. Its MaaS database manifest also contains a fixed workshop password. Those choices make a classroom repeatable; they are not suitable for a reachable or persistent cluster.

Before running the manifests, substitute unique credentials, keep the cluster access-limited and plan to remove the HTPasswd provider and workshop role bindings afterward. Treat the repository as an evaluation asset rather than a production baseline.

Preserve the install sequence

The order is part of the design. Prepare capacity and authentication first; install Node Feature Discovery and the NVIDIA GPU Operator; verify that GPUs are advertised; then install the OpenShift AI dependencies, including LeaderWorkerSet, JobSet, Kueue, OpenTelemetry, Tempo, Cluster Observability and Connectivity Link.

Only after those dependencies are healthy should the OpenShift AI setup create the operator and DataScienceCluster. The supplied cluster enables KServe with Models as a Service, workbenches, pipelines, model registry, Ray, training, TrustyAI, Llama Stack and MLflow while leaving Kueue unmanaged because its operator was installed separately.

Use each section’s validation commands as gates. In particular, wait for GPU driver pods, the DataScienceCluster Ready phase and accepted MaaS AuthPolicies. The Cluster Observability subscription is pinned for manual approval, so an unattended run can pause there by design. A successful evaluation is not “all YAML applied”; it is every dependency healthy before the next layer is introduced.