You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/deploy-mno-byol.md
+24-28
Original file line number
Diff line number
Diff line change
@@ -1,14 +1,12 @@
1
-
# Deploy a Multi Node OpenShift cluster via Jetlag from a non-standard lab, BYOL (Bring Your Own Lab), quickstart
1
+
# Deploy a Multi Node OpenShift cluster via Jetlag without create-inventory playbook, BYOL (Bring Your Own Lab), quickstart
2
2
3
-
Assuming that you receive a set of machines to install OCP, this guide walks you through getting a multi node cluster installed on this allocation. For the purposes of the guide, the machines used are Dell r660s and r760s running RHEL 9.2. In a BYOL (or with any non-homogeneous allocation containing machines of different models) due to the non-standard interface names and NIC PCI slots, you must craft Jetlag's inventory file by hand.
4
-
5
-
In other words, the `create-inventory` playbook is not used with BYOL. You must instead create your own inventory file manually, which means gathering information regarding the machines such as NIC names and MAC addresses. Therefore, thinking about simplifying this step, it is recommended to group machines of same/similar models wisely to be the cluster's control-plane and worker nodes.
3
+
In a BYOL you will have to write your own Jetlag's inventory file as the `create-inventory` playbook is not used. You must gather information regarding the machines such as NIC names and MAC addresses and assemble an inventory file. If you have a non-homogenous set of machines, it is recommended to group machines of same/similar models to be the cluster's control-plane and worker nodes.
6
4
7
5
The bastion machine needs 2 interfaces:
8
6
- The interface connected to the network, i.e., with an IP assigned, a L3 network. This interface usually referred to as *lab_network* as it provides the connectivity into the bastion machine.
9
7
- The control-plane interface, from which the cluster nodes are accessed (this is a L2 network, i.e., it does not have an IP assigned).
10
8
11
-
Sometimes the bastion machine may have firewall rules in place that prevent proper connectivity from the target cluster machines to the assisted-service API hosted on the bastion. Depending on the lab setup, you might need to add rules to allow this traffic, or if the bastion machine is already behind a firewall, the firewall could be disabled. One can, for instance, check for`firewalld` or `iptables`.
9
+
Sometimes the bastion machine may have firewall rules in place that prevent proper connectivity from the target cluster machines to the assisted-service API hosted on the bastion. Depending on the lab setup, you might need to add rules to allow this traffic, or if the bastion machine is already behind a firewall, the firewall could be disabled. You should check both`firewalld`and/or `iptables`.
12
10
13
11
The cluster machines need a minimum of 1 online private interface:
14
12
- The control-plane interface, from which other cluster nodes are accessed.
@@ -226,10 +224,10 @@ Set `smcipmitool_url` to the location of the Supermicro SMCIPMITool binary. Sinc
226
224
227
225
In case of BYOL, the lab itself determines the values of `bastion_lab_interface` and `bastion_controlplane_interface`.
228
226
229
-
*`bastion_lab_interface` should be the L2 NIC interface
230
-
*`bastion_controlplane_interface` should be the L3 network NIC interface
227
+
*`bastion_lab_interface` should be the public lab network interface
228
+
*`bastion_controlplane_interface` should be the private network inferface
231
229
232
-
For Dell r660 from this guide, set those vars to the following:
230
+
For the hardware in this guide, set those vars to the following (Your hardware will be different, and you must determine those values):
0 commit comments