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
  • 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-user assumption
  • 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
  • Phase 5, resume stock Calabi flow:
    • optional AD
    • IdM
    • bastion join
    • mirror registry
    • OpenShift cluster build
    • day-2

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-prem virt-01-like host only when the step explicitly says so
  • RUN ON BASTION — from bastion-01 after staging has completed
  1. 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
      
  2. 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_host
      • on_prem_bastion_hypervisor_user
    • RUN LOCALLY
      ssh <hypervisor-admin-user>@<hypervisor-management-ip> \
      'hostnamectl --static && sudo virt-host-validate && sudo vgs'
      
  3. Review sizing before bootstrap if the host is not m5.metal-like.
  4. Bootstrap the on-prem host and provision guest LVs.
    • RUN LOCALLY
      ansible-playbook playbooks/bootstrap/site.yml
      
  5. 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
  6. Resume the stock lab flow.

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:

Continue