Automating Red Hat OpenShift AI installations with Helm and GitOps

Summary

Deploying Red Hat OpenShift AI manually across multiple environments is error-prone due to the numerous required dependencies, including certificate managers, job queuing systems, and GPU operators. To streamline this lifecycle, the odh-gitops repository introduces the rhai-on-openshift-chart Helm chart. The chart automates operator provisioning through Operator Lifecycle Manager and configures custom resources such as DataScienceCluster. Dependency resolution is controlled via a tri-state model that automatically installs prerequisites like cert-manager and Red Hat Connectivity Link when dependent components are enabled. Using this chart, teams can deploy full platform installations or minimal inference stacks through standard Helm CLI commands or Argo CD GitOps pipelines.

Context

Installing Red Hat OpenShift AI manually requires deploying and synchronizing multiple dependent operators such as certificate management, job queuing, and GPU operators across environments, making manual multi-operator installations tedious and prone to errors.

Approach / What changed

Using the rhai-on-openshift-chart Helm chart from the odh-gitops repository to automate Operator Lifecycle Manager resources, Custom Resource configurations, and tri-state dependency resolution across full or inference-only deployments.

Takeaways

• The rhai-on-openshift-chart uses a tri-state dependency model accepting auto, true, or false to manage dependency operators like cert-manager and Kuadrant.
• Most components are enabled by setting DataScienceCluster managementState to Managed, whereas Kueue requires setting the state to Unmanaged to enable it.
• Production deployments can lock operators to specific versions using the olm.version field to prevent unexpected automated upgrades.

Related reading

• Red Hat · Aug 24, 2026

  Run LoRA fine-tuning on Red Hat OpenShift AI with Ray

  Red Hat OpenShift AI 3.5 integrates Ray cluster runtime images with preinstalled Training Hub packages to support distributed fine-tuning algorithms including LoRA, SFT, OSFT, and GRPO. Using the CodeFlare software development kit within a Jupyter workbench, developers can provision an elastic single-GPU Ray cluster attached to shared ReadWriteMany persistent storage containing model weights and training datasets. The tutorial demonstrates fine-tuning the Qwen2.5-1.5B-Instruct model on the public sql-create-context dataset to produce direct, bare SQL output without explanatory conversational text. After training completes, the workbench loads and merges the resulting LoRA adapter checkpoints with the base model to evaluate output format correctness against sample database schema questions. The RayCluster automatically tears down resources once the job concludes, while the shared pipeline architecture allows switching between supported fine-tuning algorithms by modifying dataset inputs and configuration parameters.

  Fiona Waters

• Red Hat ·