Red Hat’s lakeFS quickstart puts dataset versions into the OpenShift AI deployment path

Red Hat has published a hands-on OpenShift AI quickstart that treats training data as a versioned input rather than a mutable bucket. The reference workflow places lakeFS between OpenShift AI and S3-compatible object storage, so datasets and model artifacts can be branched, committed, compared and rolled back alongside the code that uses them.

What the workflow actually connects

The quickstart uses a fraud-detection example to walk from data preparation to a served model. According to the technical guide, it deploys MinIO for object storage and lakeFS as the versioning control plane, configures an OpenShift AI data connection against lakeFS’s S3-compatible endpoint, trains a model, writes the artifact back to lakeFS, registers it in the OpenShift AI Model Registry and creates a KServe inference endpoint.

The useful design choice is the separation between bytes and lineage. Object storage remains the data plane, while lakeFS records branch, commit, merge and revert operations. That lets a team associate a served model with the exact dataset snapshot used to train it, then compare a later branch before promoting or discarding the change. Red Hat’s announcement also describes pipeline integration that snapshots data as the workflow advances.

This is a reference architecture, not a product feature that automatically makes every OpenShift AI workload reproducible. Teams still need to preserve links among code revisions, container images, parameters, model artifacts and lakeFS commits. The quickstart demonstrates the data side of that chain and provides a concrete place to add validation before a merge.

Check the prerequisites before copying it

The tested configuration is specific: OpenShift 4.20.5, OpenShift AI 2.25, Service Mesh 2.5.11-0, Serverless 1.37.0, lakeFS 1.73.0 and Helm 3.17.1. Red Hat also says the expert-authored content has not been tested on every supported configuration.

Permissions split along the architecture. The full deployment’s administrative chart requires cluster-admin access to install the model registry, PostgreSQL, RBAC and DataScienceCluster changes; the lakeFS, MinIO, workflow UI and pipeline components can be deployed with namespace-level admin rights after that preparation. The guide says teams that skip the model registry can run the core demonstration without the administrative chart.

What platform teams should test

Start with the failure paths, not the happy-path notebook. Branch a dataset, introduce a schema or label error, and verify that a pre-merge check blocks promotion. Then confirm that the model registry entry and KServe deployment can be traced back to the lakeFS commit and that reverting the data produces the expected retraining result. The quickstart’s own architecture notes recommend protecting the main branch and using hooks for schema, format and sensitive-data checks.

That exercise will show whether the pattern closes an audit gap or merely adds another metadata system. The value is not Git-like commands by themselves; it is whether operators can answer which dataset trained the model now serving traffic, reproduce its metrics and safely reject a bad data change.