Problem
The current bootstrap process requires users to either:
- Manually edit kustomization files and patch YAMLs before running
bootstrap.sh
- Create custom overlay directories by copying and modifying existing ones
- Select from a fixed set of pre-built overlays via an interactive menu
This makes it difficult for users to quickly customize their install without deep knowledge of the repository structure. Feedback from users indicates that the most common configuration options should be selectable via command-line flags or an interactive configuration step during bootstrap.
Proposal
Add a configuration mechanism to bootstrap.sh (or a companion configure.sh script) that allows users to set the most important options via CLI flags or an interactive wizard, then generates the appropriate overlay configuration.
Proposed configurable options
1. RHOAI version / channel
--rhoai-version=<eus-2.16|stable-2.19|stable-2.22|stable-2.25|fast|fast-3.x>
Currently determined by overlay selection. This is the most fundamental choice.
2. Infrastructure type
--platform=<aws|baremetal|generic>
Determines whether GPU-specific operators (NVIDIA GPU operator, NFD) are included and which variants are used (e.g., aws-v25.3 vs default GPU operator overlay).
3. GPU support
Toggle NVIDIA GPU operator and Node Feature Discovery.
4. RHOAI components (enable/disable individual DataScienceCluster components)
--enable=<component> (repeatable)
--disable=<component> (repeatable)
Where components include: kserve, ray, modelregistry, trustyai, training, kueue, workbenches, modelmesh, pipelines, llamastack, codeflare, feast (3.x only)
Default component sets would vary by version (matching the current overlay defaults).
5. KServe deployment mode
--kserve-mode=<serverless|raw>
Selects between Serverless (Knative) and RawDeployment modes for KServe.
6. Optional operators
--with-logging # OpenShift Logging (currently commented out in overlays)
--with-web-terminal # Web Terminal operator (currently commented out)
--with-servicemesh3 # Service Mesh 3 (3.x overlays)
--with-kiali # Kiali operator
7. Sync policy
Disable ArgoCD auto-sync (require manual sync for all applications). Currently available as commented-out patches in cluster overlays.
8. Git configuration
--repo-url=<url> # Override git repo URL
--branch=<branch> # Override target branch
These exist today via -f and interactive prompts but could be more explicit.
Implementation approaches
Option A: CLI flags that generate an overlay
The script accepts flags, generates a custom overlay directory (e.g., clusters/overlays/custom-<timestamp>/), and bootstraps from it. Pros: works within existing kustomize structure. Cons: generates files that need to be committed.
Option B: Interactive wizard
A ./configure.sh script walks the user through choices interactively, then generates the overlay. Could also accept flags for non-interactive use. Similar to how openshift-install works.
Option C: Template-based overlay with variable substitution
A single parameterized overlay template where the configure script substitutes values. Simpler to maintain than generating full overlay directories.
Example usage
# Non-interactive: specify everything via flags
./bootstrap.sh \
--rhoai-version=fast-3.x \
--platform=baremetal \
--gpu \
--enable=kserve,ray,modelregistry,workbenches \
--disable=trustyai,llamastack \
--kserve-mode=serverless
# Interactive: wizard walks through options
./configure.sh
# ... answers questions ...
# Generates overlay, then runs bootstrap
# Quick start: use a preset overlay (current behavior preserved)
./bootstrap.sh --bootstrap_dir=rhoai-fast-3.x-baremetal-gpu
Additional context
The current command_flags.sh already supports --bootstrap_dir, --ocp_version, -f, and --timeout. This proposal extends that pattern with domain-specific options. Backward compatibility with the existing interactive menu selection should be preserved when no flags are provided.
Problem
The current bootstrap process requires users to either:
bootstrap.shThis makes it difficult for users to quickly customize their install without deep knowledge of the repository structure. Feedback from users indicates that the most common configuration options should be selectable via command-line flags or an interactive configuration step during bootstrap.
Proposal
Add a configuration mechanism to
bootstrap.sh(or a companionconfigure.shscript) that allows users to set the most important options via CLI flags or an interactive wizard, then generates the appropriate overlay configuration.Proposed configurable options
1. RHOAI version / channel
Currently determined by overlay selection. This is the most fundamental choice.
2. Infrastructure type
Determines whether GPU-specific operators (NVIDIA GPU operator, NFD) are included and which variants are used (e.g.,
aws-v25.3vs default GPU operator overlay).3. GPU support
Toggle NVIDIA GPU operator and Node Feature Discovery.
4. RHOAI components (enable/disable individual DataScienceCluster components)
Where components include:
kserve,ray,modelregistry,trustyai,training,kueue,workbenches,modelmesh,pipelines,llamastack,codeflare,feast(3.x only)Default component sets would vary by version (matching the current overlay defaults).
5. KServe deployment mode
Selects between Serverless (Knative) and RawDeployment modes for KServe.
6. Optional operators
7. Sync policy
Disable ArgoCD auto-sync (require manual sync for all applications). Currently available as commented-out patches in cluster overlays.
8. Git configuration
These exist today via
-fand interactive prompts but could be more explicit.Implementation approaches
Option A: CLI flags that generate an overlay
The script accepts flags, generates a custom overlay directory (e.g.,
clusters/overlays/custom-<timestamp>/), and bootstraps from it. Pros: works within existing kustomize structure. Cons: generates files that need to be committed.Option B: Interactive wizard
A
./configure.shscript walks the user through choices interactively, then generates the overlay. Could also accept flags for non-interactive use. Similar to howopenshift-installworks.Option C: Template-based overlay with variable substitution
A single parameterized overlay template where the configure script substitutes values. Simpler to maintain than generating full overlay directories.
Example usage
Additional context
The current
command_flags.shalready supports--bootstrap_dir,--ocp_version,-f, and--timeout. This proposal extends that pattern with domain-specific options. Backward compatibility with the existing interactive menu selection should be preserved when no flags are provided.