Merge pull request #35540 from aireilly/fix-35299-edit-sriovnetwork-typo

Updates to fix #35299 BZ1996069

Author: bmcelvee

modules/cnf-assigning-a-secondary-network-to-a-vrf.adoc

@@ -23,20 +23,16 @@ The Cluster Network Operator (CNO) manages additional network definitions. When
 Do not edit the `NetworkAttachmentDefinition` CRs that the Cluster Network Operator manages. Doing so might disrupt network traffic on your additional network.
 ====
 
+To create an additional network attachment with the CNI VRF plug-in, perform the following procedure.
+
 .Prerequisites
 
 * Install the {product-title} CLI (oc).
 * Log in to the OpenShift cluster as a user with cluster-admin privileges.
 
 .Procedure
 
-. Create the CNO CR by running the following command:
-+
-[source,terminal]
-----
-$ oc edit networks.operator.openshift.io cluster
-----
-. Extend the CR that you are creating by adding the `rawCNIConfig` configuration for the additional network, as in the example CR below. The following YAML configures the CNI VRF plug-in:
+. Create the `Network` custom resource (CR) for the additional network attachment and insert the `rawCNIConfig` configuration for the additional network, as in the following example CR. Save the YAML as the file `additional-network-attachment.yaml`.
 +
 [source,yaml]
 ----
@@ -47,7 +43,7 @@ metadata:
   spec:
   additionalNetworks:
   - name: test-network-1
-    namespace: test-1
+    namespace: additional-network-1
     type: Raw
     rawCNIConfig: '{
       "cniVersion": "0.3.1",
@@ -72,17 +68,24 @@ metadata:
       }]
     }'
 ----
-<1> `plugins` must be a list. The first item in the list must be secondary network underpinning the VRF network. The second item in the list is the VRF plugin configuration.
+<1> `plugins` must be a list. The first item in the list must be the secondary network underpinning the VRF network. The second item in the list is the VRF plugin configuration.
 <2> `type` must be set to `vrf`.
 <3> `vrfname` is the name of the VRF that the interface is assigned to. If it does not exist in the pod, it is created.
-<4> `table` is the routing table ID. Optional. By default, the `tableid` parameter is used. If it is not specified, the CNI assigns a free routing table ID to the VRF.
+<4> Optional. `table` is the routing table ID. By default, the `tableid` parameter is used. If it is not specified, the CNI assigns a free routing table ID to the VRF.
 +
 [NOTE]
 ====
-VRF will function correctly only when the resource is of type `netdevice`.
+VRF functions correctly only when the resource is of type `netdevice`.
 ====
-. Save your changes and quit the text editor to commit your changes.
-. Confirm that the CNO created the `NetworkAttachmentDefinition` CR by running the following command. Replace `<namespace>` with the namespace that you specified when configuring the network attachment. There might be a delay before the CNO creates the CR.
+
+. Create the `Network` resource:
++
+[source,terminal]
+----
+$ oc create -f additional-network-attachment.yaml
+----
+
+. Confirm that the CNO created the `NetworkAttachmentDefinition` CR by running the following command. Replace `<namespace>` with the namespace that you specified when configuring the network attachment, for example, `additional-network-1`.
 +
 [source,terminal]
 ----
@@ -95,14 +98,19 @@ $ oc get network-attachment-definitions -n <namespace>
 NAME                       AGE
 additional-network-1       14m
 ----
++
+[NOTE]
+====
+There might be a delay before the CNO creates the CR.
+====
 
 .Verifying that the additional VRF network attachment is successful
 
 To verify that the VRF CNI is correctly configured and the additional network attachment is attached, do the following:
 
 . Create a network that uses the VRF CNI.
 . Assign the network to a pod.
-. Verify that the pod network attachment is connected to the VRF additional network. SSH into the pod and run the following command:
+. Verify that the pod network attachment is connected to the VRF additional network. Remote shell into the pod and run the following command:
 +
 [source,terminal]
 ----

modules/cnf-assigning-a-sriov-network-to-a-vrf.adoc

@@ -24,19 +24,16 @@ The SR-IOV Network Operator manages additional network definitions. When you spe
 Do not edit `NetworkAttachmentDefinition` custom resources that the SR-IOV Network Operator manages. Doing so might disrupt network traffic on your additional network.
 ====
 
+To create an additional SR-IOV network attachment with the CNI VRF plug-in, perform the following procedure.
+
 .Prerequisites
+
 * Install the {product-title} CLI (oc).
 * Log in to the {product-title} cluster as a user with cluster-admin privileges.
 
 .Procedure
-. Create the `SriovNetwork` CR by running the following command:
-+
-[source,terminal]
-----
-$ oc create sriovnetwork.openshift.io cluster
-----
-. Extend the CR that you are creating by adding the `metaPlugins` configuration for the additional network you are creating, as in the following example CR.
-. Save your changes and quit the text editor to commit your changes. The following YAML configures the `SriovNetwork` object:
+
+. Create the `SriovNetwork` custom resource (CR) for the additional SR-IOV network attachment and insert the `metaPlugins` configuration, as in the following example CR. Save the YAML as the file `sriov-network-attachment.yaml`.
 +
 [source,yaml]
 ----
@@ -68,28 +65,42 @@ spec:
 <1> `type` must be set to `vrf`.
 <2> `vrfname` is the name of the VRF that the interface is assigned to. If it does not exist in the pod, it is created.
 
-.Verify the `NetworkAttachmentDefinition` CR is successfully created
-Confirm that the SR-IOV Network Operator created the `NetworkAttachmentDefinition` CR by running the following command. Replace `<namespace>` with the namespace that you specified when configuring the network attachment. There might be a delay before the SR-IOV Network Operator creates the CR.
-
+. Create the `SriovNetwork` resource:
++
 [source,terminal]
 ----
-$ oc get network-attachment-definitions -n <namespace>
+$ oc create -f sriov-network-attachment.yaml
 ----
 
+.Verifying that the `NetworkAttachmentDefinition` CR is successfully created
+
+* Confirm that the SR-IOV Network Operator created the `NetworkAttachmentDefinition` CR by running the following command.
++
+[source,terminal]
+----
+$ oc get network-attachment-definitions -n <namespace> <1>
+----
+<1> Replace `<namespace>` with the namespace that you specified when configuring the network attachment, for example, `additional-sriov-network-1`.
++
 .Example output
 [source,terminal]
 ----
 NAME                            AGE
 additional-sriov-network-1      14m
 ----
++
+[NOTE]
+====
+There might be a delay before the SR-IOV Network Operator creates the CR.
+====
 
 .Verifying that the additional SR-IOV network attachment is successful
 
 To verify that the VRF CNI is correctly configured and the additional SR-IOV network attachment is attached, do the following:
 
 . Create an SR-IOV network that uses the VRF CNI.
 . Assign the network to a pod.
-. Verify that the pod network attachment is connected to the SR-IOV additional network. SSH into the pod and run the following command:
+. Verify that the pod network attachment is connected to the SR-IOV additional network. Remote shell into the pod and run the following command:
 +
 [source,terminal]
 ----
@@ -113,6 +124,7 @@ $ ip link
 .Example output
 [source,terminal]
 ----
+...
 5: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master red state UP mode
+...
 ----
-