Open Data Hub 3.6 preview expands training, experiment tracking and llm-d serving

Open Data Hub’s first 3.6 early-access build widens the platform in three places that usually span separate operational teams: distributed training, experiment tracking and large-model serving. The v3.6.0-ea.1 platform release bundles a Trainer module, MLflow Operator 1.1 and a larger llm-d component set alongside KServe, pipelines, model registry, Ray and TrustyAI.

This is an upstream early-access branch, not a Red Hat OpenShift AI general-availability announcement. Its value to OpenShift AI operators is as a preview of integration and upgrade boundaries worth testing before the branch matures.

What the new modules change

The Trainer release pulls upstream Kubeflow Trainer work into the Open Data Hub build and updates runtimes for Training Hub 0.9.2 and PyTorch 2.11.0. It also makes TrainJob immutable through admission handling to unblock Kueue unsuspension. At the platform layer, the older Training Operator v1 is deprecated and disabled while Trainer moves behind a module handler. That shifts validation from “does a training pod start?” to the full job lifecycle: admission, queue suspension, runtime selection, status progression and cleanup.

MLflow Operator 1.1 moves the managed service to MLflow 3.10.1 and adds namespace-specific artifact locations through MLflowConfig. Its release also includes custom CA bundle mounting, Prometheus metrics, status URLs, safer CORS defaults, revised RBAC, OpenShift-specific PostgreSQL and SeaweedFS manifests, and TLS support for database and S3-style test backends. Those are platform concerns, not merely a new tracking UI.

The llm-d side is a family rather than one router. The platform manifest now points to the llm-d router plus workload-variant autoscaling, a batch-gateway operator, asynchronous serving and a latency predictor. The router’s EA release is primarily a synchronization of upstream changes through late August, so operators should treat interoperability—not one headline router feature—as the test target.

What operators should validate

A useful 3.6 preview exercise should cover four seams:

1. Upgrade and ownership: confirm the DataScienceCluster reaches Ready while out-of-tree modules install, upgrade and uninstall; specifically check the handoff from Training Operator v1 to Trainer and the platform controller’s module status.
2. Disconnected deployment: mirror every related image by digest and verify Trainer, MLflow and the llm-d auxiliaries resolve without registry access. The platform changelog includes multiple fixes to image-digest synchronization and disconnected readiness.
3. Identity, storage and certificates: test MLflow UI and SDK routes, namespace-scoped artifact paths, custom certificate authorities, RBAC boundaries and TLS to backing PostgreSQL and object storage.
4. End-to-end AI flow: submit a queued training job, record artifacts and metrics in MLflow, register or serve the result, then exercise llm-d routing under mixed request sizes while watching autoscaling, latency and batch behavior.

The preview is most informative when those checks run together. The 3.6 branch is exposing where training, tracking and serving share certificates, storage, scheduling and lifecycle state—the integration work operators need to understand before any downstream release adopts the stack.