Merge pull request #92929 from dfitzmau/OCPBUGS-55288-12

[enterprise-4.12] OCPBUGS-55288: Added note about bonded interface and node IP address …

Author: dfitzmau

modules/ipi-install-configuring-host-network-interfaces-in-the-install-config.yaml-file.adoc

@@ -6,7 +6,7 @@
 [id="configuring-host-network-interfaces-in-the-install-config-yaml-file_{context}"]
 = Optional: Configuring host network interfaces
 
-Before installation, you can set the `networkConfig` configuration setting in the `install-config.yaml` file to configure host network interfaces using NMState.
+Before installation, you can set the `networkConfig` configuration setting in the `install-config.yaml` file to use NMState to configure host network interfaces.
 
 The most common use case for this functionality is to specify a static IP address on the bare-metal network, but you can also configure other networks such as a storage network. This functionality supports other NMState features such as VLAN, VXLAN, bridges, bonds, routes, MTU, and DNS resolver settings.
 
@@ -17,36 +17,35 @@ The most common use case for this functionality is to specify a static IP addres
 
 .Procedure
 
-. Optional: Consider testing the NMState syntax with `nmstatectl gc` before including it in the `install-config.yaml` file, because the installer will not check the NMState YAML syntax.
+. Optional: Consider testing the NMState syntax with `nmstatectl gc` before including the syntax in the `install-config.yaml` file, because the installation program does not check the NMState YAML syntax.
 +
 [NOTE]
 ====
-Errors in the YAML syntax might result in a failure to apply the network configuration. Additionally, maintaining the validated YAML syntax is useful when applying changes using Kubernetes NMState after deployment or when expanding the cluster.
+Errors in the YAML syntax might result in a failure to apply the network configuration. Additionally, maintaining the validated YAML syntax is useful when applying changes by using Kubernetes NMState after deployment or when expanding the cluster.
 ====
 
-
 .. Create an NMState YAML file:
 +
 [source,yaml]
 ----
-interfaces:
-- name: <nic1_name> <1>
+interfaces: <1>
+- name: <nic1_name>
   type: ethernet
   state: up
   ipv4:
     address:
-    - ip: <ip_address> <1>
+    - ip: <ip_address>
       prefix-length: 24
     enabled: true
 dns-resolver:
   config:
     server:
-    - <dns_ip_address> <1>
+    - <dns_ip_address>
 routes:
   config:
   - destination: 0.0.0.0/0
-    next-hop-address: <next_hop_ip_address> <1>
-    next-hop-interface: <next_hop_nic1_name> <1>
+    next-hop-address: <next_hop_ip_address>
+    next-hop-interface: <next_hop_nic1_name>
 ----
 +
 <1> Replace `<nic1_name>`, `<ip_address>`, `<dns_ip_address>`, `<next_hop_ip_address>` and `<next_hop_nic1_name>` with appropriate values.
@@ -77,24 +76,24 @@ Replace `<nmstate_yaml_file>` with the configuration file name.
         rootDeviceHints:
           deviceName: "/dev/sda"
         networkConfig: <1>
-          interfaces:
-          - name: <nic1_name> <2>
+          interfaces: <2>
+          - name: <nic1_name>
             type: ethernet
             state: up
             ipv4:
               address:
-              - ip: <ip_address> <2>
+              - ip: <ip_address>
                 prefix-length: 24
               enabled: true
           dns-resolver:
             config:
               server:
-              - <dns_ip_address> <2>
+              - <dns_ip_address>
           routes:
             config:
             - destination: 0.0.0.0/0
-              next-hop-address: <next_hop_ip_address> <2>
-              next-hop-interface: <next_hop_nic1_name> <2>
+              next-hop-address: <next_hop_ip_address>
+              next-hop-interface: <next_hop_nic1_name>
 ----
 <1> Add the NMState YAML syntax to configure the host interfaces.
 <2> Replace `<nic1_name>`, `<ip_address>`, `<dns_ip_address>`, `<next_hop_ip_address>` and `<next_hop_nic1_name>` with appropriate values.

modules/ipi-install-establishing-communication-between-subnets.adoc

@@ -6,13 +6,13 @@
 [id="ipi-install-establishing-communication-between-subnets_{context}"]
 = Establishing communication between subnets
 
-In a typical {product-title} cluster setup, all nodes, including the control plane and worker nodes, reside in the same network. However, for edge computing scenarios, it can be beneficial to locate worker nodes closer to the edge. This often involves using different network segments or subnets for the remote worker nodes than the subnet used by the control plane and local worker nodes. Such a setup can reduce latency for the edge and allow for enhanced scalability. However, the network must be configured properly before installing {product-title} to ensure that the edge subnets containing the remote worker nodes can reach the subnet containing the control plane nodes and receive traffic from the control plane too.
+In a typical {product-title} cluster setup, all nodes, including the control plane and worker nodes, reside in the same network. However, for edge computing scenarios, it can be beneficial to locate worker nodes closer to the edge. This often involves using different network segments or subnets for the remote worker nodes than the subnet used by the control plane and local worker nodes. Such a setup can reduce latency for the edge and allow for enhanced scalability. 
+
+Before installing {product-title}, you must configure the network properly to ensure that the edge subnets containing the remote nodes can reach the subnet containing the control plane nodes and receive traffic from the control plane too.
 
 [IMPORTANT]
 ====
-All control plane nodes must run in the same subnet. When using more than one subnet, you can also configure the Ingress VIP to run on the control plane nodes by using a manifest. See "Configuring network components to run on the control plane" for details.
-
-Deploying a cluster with multiple subnets requires using virtual media.
+During cluster installation, assign permanent IP addresses to nodes in the network configuration of the `install-config.yaml` configuration file. If you do not do this, nodes might get assigned a temporary IP address that can impact how traffic reaches the nodes. For example, if a node has a temporary IP address assigned to it and you configured a bonded interface for a node, the bonded interface might receive a different IP address.
 ====
 
 This procedure details the network configuration required to allow the remote worker nodes in the second subnet to communicate effectively with the control plane nodes in the first subnet and to allow the control plane nodes in the first subnet to communicate effectively with the remote worker nodes in the second subnet.
@@ -22,6 +22,14 @@ In this procedure, the cluster spans two subnets:
 - The first subnet (`10.0.0.0`) contains the control plane and local worker nodes.
 - The second subnet (`192.168.0.0`) contains the edge worker nodes.
 
+[IMPORTANT]
+====
+All control plane nodes must run in the same subnet. When using more than one subnet, you can also configure the Ingress VIP to run on the control plane nodes by using a manifest. See "Configuring network components to run on the control plane" for details.
+
+Deploying a cluster with multiple subnets requires using virtual media.
+====
+
+
 .Procedure
 
 . Configure the first subnet to communicate with the second subnet: