Purpose

This repository provides automation for deploying the following components:

• a hub cluster using Agent Based Install
• spokes using ZTP

Architecture

Kcli is leveraged to deploy a plan which creates an "installer vm" to drive deployment via the following steps:

• Virtual nodes for both the hub and spokes are created (or combined with baremetal nodes). Note this is optional
• Client packages such as openshift-install are downloaded with any specified version and tag.
• Stop the nodes to deploy through redfish.
• Launch hub install against them
• Install ZTP requirements such as assisted service, openshift-gitops, a git server, ...
• Launch spoke deployments

Parameters allow to customize the installation

The installer vm (and additional virtual nodes) can run on any platform supported by kcli with support for iso deployment. So far it was tested on:

• kvm
• vsphere and esx

Requirements

for kcli

• kcli installed (for rhel8/cento8/fedora, look here)
• An openshift pull secret (stored by default in openshift_pull.json)

on the provisioning node (KVM Only)

• a physical bridge typically named baremetal with a nic from the external network

Here's a script you can run on the provisioning node for that (adjust the NIC variable as per your environment)

export NIC=eno2
sudo nmcli connection add ifname baremetal type bridge con-name baremetal
sudo nmcli con add type bridge-slave ifname $NIC master baremetal
sudo nmcli con down $NIC; sudo pkill dhclient; sudo dhclient baremetal

Launch

Prepare a valid parameter file with the information needed. At least, you need to specify the following elements:

• api_ip
• ingress_ip
• bmc_user/bmc_password (for real baremetal)
• an array of your ctlplanes (if thet are not virtual). Each entry in this array needs at least the mac and redfish_address. Optionally you can indicate for each entry a specific bmc_user, bmc_password and disk (to be used as rootdevice hint) either as /dev/XXX or simply XXX
• an array of your workers (can be left empty if you only want to deploy ctlplanes). The format of those entries follow the one indicated for ctlplanes.

Here's a snippet what the workers variable might look like:

workers:
- redfish_address: 192.168.1.5
- redfish_address: 192.168.1.6

You can have a look at:

• parameters.yml for a parameter file targetting baremetal nodes only
• parameters_virtual.yml for one combining virtual ctlplanes and physical workers.

Call the resulting file kcli_parameters.yml to avoid having to specify it in the creation command.

Then you can launch deployment with:

kcli create plan

Interacting in the vm

kcli ssh

Parameters

Note that you can use the baseplan kcli_plan_infra.yml to deploy the infrastructure only

Node parameters

when specifying baremetal_ctlplanes or baremetal_workers as an array, the specification can be created with something like this

- redfish_address: 192.168.123.45
  mac: 98:03:9b:62:81:49

The following parameters can be used in this case:

• redfish_address. Redfish url
• boot_mode (optional). Should either be set to Legacy, UEFI or UEFISecureBoot
• bmc_user. If not specified, global bmc_password variable is used
• bmc_password. If not specified, global bmc_password variable is used
• disk. Optional rootDeviceHint disk device
• ip, nic, gateway. Those attributes can be provided to set static networking using nmstate. Nic can be omitted. If gateway isn't provided, the static_gateway is used or gateway is guessed from baremetal_cidr

Sample parameter files

The following sample parameter files are available for you to deploy:

• lab.yml This deploys 3 ctlplanes in a dedicated ipv4 network
• lab_ipv6.yml This deploys 3 ctlplanes in a dedicated ipv6 network (hence in a disconnected manner) and a SNO spoke on top