Calabi Documentation

Calabi

Single-host disconnected OpenShift on nested KVM, with intent-first docs for architecture, orchestration, auth, and recovery.

Docs MapGitHub
Experimental On-Prem Path. Use these pages only for the divergent early host and bastion-staging steps, then return to the main Calabi docs once the normal flow resumes.
Experimental

Navigation

Experimental alternate entry path for on-prem host preparation before rejoining the main flow.

Experimental. The on-prem path is an unvalidated developer sandbox. For the supported deployment, use the AWS docs map and follow the golden path from there.

On-Prem Documentation

Warning

This on-prem target is experimental. Treat the docs and playbooks in this subtree as an emerging alternate installation path, not yet the same confidence level as the validated AWS-target flow.

Use these pages when you are building Calabi on an on-prem virt-01-like host.

What you provide:

  • you provide a RHEL hypervisor host
  • you provide an LVM2 volume group for guest storage
  • the on-prem subtree creates the guest logical volumes and publishes the same /dev/ebs/* compatibility paths the stock guest and cluster roles already expect
  • you define both:
    • how the operator workstation reaches the hypervisor
    • how bastion reaches that same hypervisor on the lab network
  • once that host contract is satisfied, the stock support-service, cluster, and day-2 orchestration is reused

These pages only cover the on-prem differences. After host bootstrap and bastion staging, return to AWS DOCS MAP.

Start Here

If you need to... Start here Then read
verify the host contract Prerequisites Host Sizing And Resource Policy
run the alternate automation path Automation Flow ./scripts/run_local_playbook.sh playbooks/site-bootstrap.yml, ./scripts/run_remote_bastion_playbook.sh playbooks/site-lab.yml
choose or edit an override profile Override Mechanism inventory/overrides/, Automation Flow
run only the pre-cluster support path on a smaller host Prerequisites inventory/overrides/precluster-64g.yml.example, ./scripts/run_remote_bastion_playbook.sh playbooks/site-precluster.yml
run the current 3-control-plane / 3-worker external Ceph profile Automation Flow inventory/overrides/core-services-ad-plus-openshift-3node-external-ceph.yml.example, AWS AUTOMATION FLOW
run the current ~128 GiB host profile with AD and managed zram writeback Host Sizing And Resource Policy inventory/overrides/core-services-ad-128g.yml.example, Manual Process
compare automation with the manual path Manual Process Portability And Gap Analysis
return to the main validated flow AWS Docs Map AWS Manual Process Step 12

What Is Different On-Prem

  • there is no AWS tenant or host stack
  • there is no live AWS volume discovery
  • the guest storage contract comes from the LVM volume group you provide
  • you must validate CPU, RAM, NUMA, and storage headroom against the current guest footprint before bootstrap

Where The Normal Docs Take Over Again

For the manual path, the on-prem-specific work ends once the host is prepared, guest storage exists, and bastion staging is complete. Then continue in the stock runbook at:

For automation, the on-prem operator entrypoints are:

The current cluster-capable external Ceph example override embeds the external cluster-details payload inline as base64, so it is portable across workstation to bastion handoff and does not depend on an operator-local cluster-details file path at runtime.

For the detailed override contract, including enable_* versus force_* phase toggles, external ODF inputs, effective storage classes, resource sizing, and mirror-registry parallelism, read:

Primary Pages In This Branch

Continue