Skip to content

Commit 7017431

Browse files
jeana-redhatjeana-redhat
authored
Merge pull request #33082 from johnwilkins/TELCODOCS-128
TELCODOCS-128: KNIDEPLOY-3555, Enable provisioning network as a day-2 choice
2 parents f3649d4 + 1816c7c commit 7017431

File tree

3 files changed

+104
-6
lines changed

3 files changed

+104
-6
lines changed

‎installing/installing_bare_metal_ipi/ipi-install-post-installation-configuration.adoc‎

Lines changed: 4 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -3,6 +3,10 @@
33
include::modules/common-attributes.adoc[]
44
:context: ipi-install-post-installation-configuration
55

6+
toc::[]
7+
68
After successfully deploying an installer-provisioned cluster, consider the following post-installation procedures.
79

810
include::modules/ipi-install-configuring-ntp-for-disconnected-clusters.adoc[leveloffset=+1]
11+
12+
include::modules/nw-enabling-a-provisioning-network-after-installation.adoc[leveloffset=+1]

‎modules/ipi-install-network-requirements.adoc‎

Lines changed: 17 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -33,20 +33,31 @@ endif::[]
3333

3434
{product-title} deploys with two networks:
3535

36-
- `provisioning`: The `provisioning` network is an *optional* non-routable network used for provisioning the underlying operating system on each node that is a part of the {product-title} cluster. When deploying using the `provisioning` network, the first NIC on each node, such as `eth0` or `eno1`,
37-
*must* interface with the `provisioning` network.
36+
- `provisioning`: The `provisioning` network is an optional non-routable network used for provisioning the underlying operating system on each node that is a part of the {product-title} cluster. The network interface for the `provisioning` network on each cluster node must have the BIOS or UEFI configured to PXE boot.
37+
+
38+
In {product-title} 4.3, when deploying using the `provisioning` network, the first NIC on each node, such as `eth0` or `eno1`, must interface with the `provisioning` network.
39+
+
40+
In {product-title} 4.4 and later releases, you can specify the provisioning network NIC with the `provisioningNetworkInterface` configuration setting.
41+
42+
- `baremetal`: The `baremetal` network is a routable network.
43+
+
44+
In {product-title} 4.3, when deploying using the `provisioning` network, the second NIC on each node, such as `eth1` or `eno2`, must interface with the `baremetal` network.
45+
+
46+
In {product-title} 4.4 and later releases, you can use any NIC order to interface with the `baremetal` network, provided it is the same NIC order across worker and control plane nodes and not the NIC specified in the `provisioningNetworkInterface` configuration setting for the `provisioning` network.
3847

39-
- `baremetal`: The `baremetal` network is a routable network. When deploying using the `provisioning` network, the second NIC on each node, such as `eth1` or `eno2`, *must* interface with the `baremetal` network. When deploying without a `provisioning` network, you can use any NIC on each node to interface with the `baremetal` network.
48+
[NOTE]
49+
====
50+
Use a compatible approach such that cluster nodes use the same NIC ordering on all cluster nodes. NICs must have heterogeneous hardware with the same NIC naming convention such as `eth0` or `eno1`.
51+
====
4052

4153
[IMPORTANT]
4254
====
43-
Each NIC should be on a separate VLAN corresponding to the appropriate network.
55+
When using a VLAN, each NIC must be on a separate VLAN corresponding to the appropriate network.
4456
====
4557

4658
.Configuring the DNS server
4759

48-
Clients access the {product-title} cluster nodes over the `baremetal` network.
49-
A network administrator must configure a subdomain or subzone where the canonical name extension is the cluster name.
60+
Clients access the {product-title} cluster nodes over the `baremetal` network. A network administrator must configure a subdomain or subzone where the canonical name extension is the cluster name.
5061

5162
----
5263
<cluster-name>.<domain-name>

‎modules/nw-enabling-a-provisioning-network-after-installation.adoc‎

Lines changed: 83 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,83 @@
1+
// This is included in the following assemblies:
2+
//
3+
// ipi-install-post-installation-configuration.adoc
4+
5+
[id="enabling-a-provisioning-network-after-installation_{context}"]
6+
7+
= Enabling a provisioning network after installation
8+
9+
The assisted installer and installer-provisioned installation for bare metal clusters provide the ability to deploy a cluster without a `provisioning` network. This capability is for scenarios such as proof-of-concept clusters or deploying exclusively with Redfish virtual media when each node's baseboard management controller is routable via the `baremetal` network.
10+
11+
In {product-title} 4.8 and later, you can enable a `provisioning` network after installation using the Cluster Baremetal Operator (CBO).
12+
13+
.Prerequisites
14+
15+
. The `provisioning` network must exist.
16+
. The `provisioning` network must be enabled.
17+
. The cluster nodes must be connected to the `provisioning` network using the same network interface on both worker nodes and control plane nodes.
18+
. The cluster nodes must be homogeneous. If the cluster nodes use different network interface names for the same network interface order, such as `eth0` and `eno1` for the first network interface, the procedure fails.
19+
20+
.Procedure
21+
22+
. Identify the provisioning interface name for the cluster nodes. For example, `eth0` or `eno1`.
23+
24+
. Enable the preboot execution environment (PXE) on the `provisioning` network interface of the cluster nodes.
25+
26+
. Retrieve the current state of the `provisioning` network and save it to a provisioning configuration resource file:
27+
+
28+
[source,terminal]
29+
----
30+
$ oc get provisioning -o yaml > enable-provisioning-nw.yaml
31+
----
32+
33+
. Modify the provisioning configuration resource file:
34+
+
35+
[source,terminal]
36+
----
37+
$ vim ~/enable-provisioning-nw.yaml
38+
----
39+
+
40+
Scroll down to the `provisioningNetwork` configuration setting and change it from `Disabled` to `Managed`. Then, add the `provisioningOSDownloadURL`, `provisioningIP`, `provisioningNetworkCIDR`, `provisioningDHCPRange`, `provisioningInterface`, and `watchAllNameSpaces` configuration settings after the `provisioningNetwork` setting. Provide appropriate values for each setting.
41+
+
42+
[source,yaml]
43+
----
44+
apiVersion: v1
45+
items:
46+
- apiVersion: metal3.io/v1alpha1
47+
kind: Provisioning
48+
metadata:
49+
name: provisioning-configuration
50+
spec:
51+
provisioningNetwork: <1>
52+
provisioningOSDownloadURL: <2>
53+
provisioningIP: <3>
54+
provisioningNetworkCIDR: <4>
55+
provisioningDHCPRange: <5>
56+
provisioningInterface: <6>
57+
watchAllNameSpaces: <7>
58+
----
59+
+
60+
where:
61+
+
62+
<1> The `provisioningNetwork` is one of `Managed`, `Unmanaged`, or `Disabled`. When set to `Managed`, Metal3 manages the provisioning network and the CBO deploys the Metal3 pod with a configured DHCP server. When set to `Unmanaged`, the system administrator configures DHCP server manually.
63+
+
64+
<2> The `provisioningOSDownloadURL` is a valid HTTPS URL with a valid sha256 checksum that enables the Metal3 pod to download a qcow2 operating system image ending in `.qcow2.gz` or `.qcow2.xz`. This field is required whether the provisioning network is `Managed`, `Unmanaged`, or `Disabled`. For example: `\http://192.168.0.1/images/rhcos-_<version>_.x86_64.qcow2.gz?sha256=_<sha>_`.
65+
+
66+
<3> The `provisioningIP` is the static IP address that the DHCP server and ironic use to provision the network. This static IP address must be within the `provisioning` subnet, and outside of the DHCP range. If you configure this setting, it must have a valid IP address even if the `provisioning` network is `Disabled`. The static IP address is bound to the metal3 pod. If the metal3 pod fails and moves to another server, the static IP address also moves to the new server.
67+
+
68+
<4> The Classless Inter-Domain Routing (CIDR) address. If you configure this setting, it must have a valid CIDR address even if the `provisioning` network is `Disabled`. For example: `192.168.0.1/24`.
69+
+
70+
<5> The DHCP range. This setting is only applicable to a `Managed` provisioning network. Omit this configuration setting if the `provisioning` network is `Disabled`. For example: `192.168.0.64, 192.168.0.253`.
71+
+
72+
<6> The NIC name for the `provisioning` interface on cluster nodes. This setting is only applicable to `Managed` and `Unamanged` provisioning networks. Omit this configuration setting if the `provisioning` network is `Disabled`.
73+
+
74+
<7> Set this setting to `true` if you want metal3 to watch namespaces other than the default `openshift-machine-api` namespace. The default value is `false`.
75+
76+
. Save the changes to the provisioning configuration resource file.
77+
78+
. Apply the provisioning configuration resource file to the cluster:
79+
+
80+
[source,terminal]
81+
----
82+
$ oc apply -f enable-provisioning-nw.yaml
83+
----

0 commit comments

Comments
 (0)