On-Prem Automation Flow
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.
This page covers the on-prem-only build order. After host bootstrap and bastion staging, return to the stock AWS AUTOMATION FLOW for the remaining support-service, cluster, and day-2 sequencing.
Execution Contexts
You will work in three places:
- operator workstation
- on-prem
virt-01-like hypervisor - bastion-native execution from
bastion-01
Only the early phases differ from the AWS path:
- there is no AWS tenant or host-stack provisioning
- you start from a preinstalled host
- you provide an LVM volume group instead of AWS-attached guest EBS volumes
Phase Summary
- Phase 1, operator preflight:
- validate secrets, content inputs, and local tooling
- Phase 2, on-prem host contract:
- verify the host can act as
virt-01 - verify CPU / RAM / storage sizing
- verify the LVM volume group exists and has enough free space
- verify the host can act as
- Phase 3, on-prem bootstrap:
- prepare the host
- apply host CPU and memory policy
- configure OVS, libvirt, and firewalling
- create guest logical volumes
- publish
/dev/ebs/*compatibility symlinks - preserve a bastion-to-hypervisor handoff, but with explicit on-prem
runtime host and user settings instead of the stock
ec2-userassumption
- Phase 4, bastion bootstrap:
- build
bastion-01 - stage the on-prem project tree onto bastion
- then stage the stock AWS-target project tree through the local on-prem bastion-stage wrapper
- build
- Phase 5, resume stock Calabi flow:
- optional AD
- IdM
- bastion join
- mirror registry
- OpenShift cluster build
- day-2
Recommended Run Order
Where each step runs
| Steps | Where | What happens |
|---|---|---|
| 1-4 | Operator workstation / on-prem virt-01 |
preflight, host validation, VG validation, host bootstrap |
| 5 | Operator workstation | bastion build and staging |
| 6+ | bastion-01 |
resume the stock support-service, cluster, and day-2 flow |
Important
Keep the normal workstation-to-bastion boundary. Do the early host-facing work from the operator workstation, then stay on bastion once you cross that boundary.
Command shorthand
- RUN LOCALLY — from the operator workstation at
on-prem-openshift-demo RUN ON HYPERVISOR— on the on-premvirt-01-like host only when the step explicitly says so- RUN ON BASTION — from
bastion-01after staging has completed
- Validate the local inputs and the on-prem inventory.
- RUN LOCALLY
ansible-playbook --syntax-check playbooks/site-bootstrap.yml ansible-playbook --syntax-check playbooks/site-lab.yml
- RUN LOCALLY
- Verify the on-prem host contract.
- check SSH reachability
- check
virt-host-validate - check storage visibility and the intended volume group
- confirm the bastion-side hypervisor path you intend to publish through:
on_prem_bastion_hypervisor_hoston_prem_bastion_hypervisor_user
- RUN LOCALLY
ssh <hypervisor-admin-user>@<hypervisor-management-ip> \ 'hostnamectl --static && sudo virt-host-validate && sudo vgs'
- Review sizing before bootstrap if the host is not
m5.metal-like.- RUN LOCALLY
- read HOST SIZING
- RUN LOCALLY
- Bootstrap the on-prem host and provision guest LVs.
- RUN LOCALLY
ansible-playbook playbooks/bootstrap/site.yml
- RUN LOCALLY
- Build the bastion and stage the project.
- RUN LOCALLY
ansible-playbook playbooks/site-bootstrap.yml - this wrapper stages both:
- it also rewrites the bastion-side runtime inventory so bastion uses your
explicit on-prem hypervisor user instead of
ec2-user
- RUN LOCALLY
- Resume the stock lab flow.
- RUN ON BASTION
ansible-playbook -i inventory/hosts.yml playbooks/site-lab.yml - from this point, use the stock flow reference:
- RUN ON BASTION
Handoff Point
After playbooks/site-bootstrap.yml finishes successfully in the on-prem
subtree:
- the host has been prepared
- guest LVs exist
/dev/ebs/*compatibility paths exist- the bastion has been built
- the on-prem and stock project trees have been staged
At that point, use: