Skip to content

HCIDOCS-75: Add IPI installation workflow information to our document… #94545

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -60,3 +60,5 @@ include::modules/ipi-install-out-of-band-management.adoc[leveloffset=+1]
include::modules/ipi-install-required-data-for-installation.adoc[leveloffset=+1]

include::modules/ipi-install-validation-checklist-for-nodes.adoc[leveloffset=+1]

include::modules/ref_ipi-installation-overview.adoc[leveloffset=+1]
48 changes: 48 additions & 0 deletions modules/ref_ipi-installation-overview.adoc
Original file line number Diff line number Diff line change
@@ -0,0 +1,48 @@
// Module included in the following assemblies:
//
// * installing/installing_bare_metal/ipi/ipi-install-prerequisites.adoc

:_mod-docs-content-type: REFERENCE

[id="installation-overview_{context}"]
= Installation overview

The installation program supports interactive mode, but Red{nbsp}Hat recommends preparing an `install-config.yaml` file in advance, containing the provisioning details for all of the bare-metal hosts, and the relevant cluster details.

The installation program loads the `install-config.yaml` file, while the administrator generates the manifests and verifies all prerequisites.

The installation program enrolls all nodes in the cluster and starts the bootstrap VM. The installation program starts the metal platform components as `systemd` services, which have the following containers:

* Ironic-dnsmasq: The DHCP server responsible for handing over the IP addresses to the provisioning interface of various nodes on the provisioning network. Ironic-dnsmasq is only enabled when you deploy an {product-title} cluster with a provisioning network.
* Ironic-httpd: The HTTP server used to ship the images to the nodes.
* Image-customization
* Ironic
* Ironic-inspector (available in {product-title} 4.16 and earlier)
* Ironic-ramdisk-logs
* Extract-machine-os
* Provisioning-interface: The service that configures networking when the provisioning interface is enabled.
* Metal3-baremetal-operator: The operator that provides a higher-level API for Ironic and replaces `terraform-provider-ironic` (available in {product-title} 4.16 and later)

The nodes enter the validation phase, where each node moves to a “manageable” state after Ironic validates the credentials to access the Baseboard Management Controller (BMC).

Once in the “manageable” state, the “inspection” phase starts. The "inspection" phase ensures that the hardware meets the minimum requirements needed for a successful deployment of {product-title}.

The `install-config.yaml` file details the provisioning network. The installation program on the bootstrap VM will try to push a live image by using PXE to every node with the Ironic Python Agent (IPA) loaded. When using virtual media, it connects directly to each node's BMC to virtually attach the image.

When using PXE boot, all nodes reboot to start the process:

* The `ironic-dnsmasq` service running on the bootstrap VM provides the IP address of the node and the TFTP boot server.
* The first-boot software loads the root file system over HTTP.
* The `ironic` service on the bootstrap VM receives the hardware information from each node.

The nodes then enter the “cleaning” state, where each node must clean all the disks before continuing with the configuration.

Once the “cleaning” state finishes, the nodes enter the “available” state and the installation program moves the nodes to the “deploying” state.

IPA runs the `coreos-installer` to install the {op-system-first} image on the disk defined by `rootDeviceHints` in the `install-config.yaml` file. The node boots by using {op-system}.

Once the installation program configures the control plane nodes, it moves control from the bootstrap VM to the control plane nodes and deletes the bootstrap VM.

The baremetal-operator continues the deployment of the workers, storage, and infra nodes. Once the installation completes, the nodes move to the "active" state.

Once the installation program finishes installation, you can proceed with postinstallation configuration and other Day 2 tasks.