Modularizes complex procedure

Author: Steven Smith

installing/installing_aws/aws-compute-edge-zone-tasks.adoc

@@ -30,7 +30,11 @@ You might need to change the maximum transmission unit (MTU) value for the clust
 include::modules/nw-cluster-mtu-change-about.adoc[leveloffset=+2]
 
 // Changing the cluster network MTU
-include::modules/nw-cluster-mtu-change.adoc[leveloffset=+3]
+include::modules/nw-cluster-mtu-change.adoc[leveloffset=+2]
+include::modules/nw-cluster-mtu-checking.adoc[leveloffset=+3]
+include::modules/nw-cluster-mtu-migration.adoc[leveloffset=+3]
+include::modules/nw-cluster-mtu-verifying-configuration.adoc[leveloffset=+3]
+include::modules/nw-cluster-mtu-finalizing-migration.adoc[leveloffset=+3]
 
 // Opting in to AWS Local Zones or Wavelength Zones
 include::modules/installation-aws-add-zone-locations.adoc[leveloffset=+2]

installing/installing_aws/ipi/installing-aws-outposts.adoc

@@ -42,6 +42,10 @@ To extend your VPC cluster into an Outpost, you must complete the following netw
 
 //Changing the Cluster Network MTU to support AWS Outposts
 include::modules/nw-cluster-mtu-change.adoc[leveloffset=+2]
+include::modules/nw-cluster-mtu-checking.adoc[leveloffset=+3]
+include::modules/nw-cluster-mtu-migration.adoc[leveloffset=+3]
+include::modules/nw-cluster-mtu-verifying-configuration.adoc[leveloffset=+3]
+include::modules/nw-cluster-mtu-finalizing-migration.adoc[leveloffset=+3]
 [role="_additional-resources"]
 .Additional resources
 * xref:../../../networking/advanced_networking/changing-cluster-network-mtu.adoc#changing-cluster-network-mtu[Changing the MTU for the cluster network]

modules/nw-cluster-mtu-applying-mtu-value.adoc

@@ -0,0 +1,79 @@
+// Module included in the following assemblies:
+//
+// * networking/changing-cluster-network-mtu.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="nw-cluster-mtu-applying-mtu-value_{context}"]
+= Applying the new hardware MTU value
+
+Use the following procedure to apply the new hardware maximum transmission unit (MTU) value.
+
+.Procedure
+
+. Update the underlying network interface MTU value:
+
+** If you are specifying the new MTU with a NetworkManager connection configuration, enter the following command. The MachineConfig Operator automatically performs a rolling reboot of the nodes in your cluster.
++
+[source,terminal]
+----
+$ for manifest in control-plane-interface worker-interface; do
+    oc create -f $manifest.yaml
+  done
+----
+
+** If you are specifying the new MTU with a DHCP server option or a kernel command line and PXE, make the necessary changes for your infrastructure.
+
+. As the Machine Config Operator updates machines in each machine config pool, the Operator reboots each node one by one. You must wait until all the nodes are updated. Check the machine config pool status by entering the following command:
++
+[source,terminal]
+----
+$ oc get machineconfigpools
+----
++
+A successfully updated node has the following status: `UPDATED=true`, `UPDATING=false`, `DEGRADED=false`.
++
+[NOTE]
+====
+By default, the Machine Config Operator updates one machine per pool at a time, causing the total time the migration takes to increase with the size of the cluster.
+====
+
+. Confirm the status of the new machine configuration on the hosts:
+
+.. To list the machine configuration state and the name of the applied machine configuration, enter the following command:
++
+[source,terminal]
+----
+$ oc describe node | egrep "hostname|machineconfig"
+----
++
+.Example output
+[source,text]
+----
+kubernetes.io/hostname=master-0
+machineconfiguration.openshift.io/currentConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b
+machineconfiguration.openshift.io/desiredConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b
+machineconfiguration.openshift.io/reason:
+machineconfiguration.openshift.io/state: Done
+----
++
+Verify that the following statements are true:
++
+--
+ * The value of `machineconfiguration.openshift.io/state` field is `Done`.
+ * The value of the `machineconfiguration.openshift.io/currentConfig` field is equal to the value of the `machineconfiguration.openshift.io/desiredConfig` field.
+--
+
+.. To confirm that the machine config is correct, enter the following command:
++
+[source,terminal]
+----
+$ oc get machineconfig <config_name> -o yaml | grep path:
+----
++
+--
+where:
+
+`<config_name>`:: Specifies the name of the machine config from the `machineconfiguration.openshift.io/currentConfig` field.
+--
++
+If the machine config is successfully deployed, the previous output contains the `/etc/NetworkManager/conf.d/99-<interface>-mtu.conf` file path and the `ExecStart=/usr/local/bin/mtu-migration.sh` line.

modules/nw-cluster-mtu-change-about.adoc

@@ -19,7 +19,7 @@ Only the OVN-Kubernetes cluster network plugin supports changing the MTU value.
 [id="service-interruption-considerations_{context}"]
 == Service interruption considerations
 
-When you initiate an MTU change on your cluster the following effects might impact service availability:
+When you initiate a maximum transmission unit (MTU) change on your cluster the following effects might impact service availability:
 
 * At least two rolling reboots are required to complete the migration to a new MTU. During this time, some nodes are not available as they restart.
 
@@ -28,7 +28,7 @@ When you initiate an MTU change on your cluster the following effects might impa
 [id="mtu-value-selection_{context}"]
 == MTU value selection
 
-When planning your MTU migration there are two related but distinct MTU values to consider.
+When planning your maximum transmission unit (MTU) migration there are two related but distinct MTU values to consider.
 
 * *Hardware MTU*: This MTU value is set based on the specifics of your network infrastructure.
 * *Cluster network MTU*: This MTU value is always less than your hardware MTU to account for the cluster network overlay overhead. The specific overhead is determined by your network plugin. For OVN-Kubernetes, the overhead is `100` bytes.