Merge pull request #80911 from JoeAldinger/OSDOCS-11784

OSDOCS-11784: removes SDN from commands and misc spots

Author: JoeAldinger

_unused_topics/monitoring-monitoring-overview.adoc

@@ -38,7 +38,7 @@ All the components of the monitoring stack are monitored by the stack. Additiona
 * kube-controller-manager-operator
 * kube-scheduler
 * kubelet
-* monitor-sdn
+* monitor-ovn-kubernetes
 * openshift-apiserver
 * openshift-apiserver-operator
 * openshift-controller-manager

modules/assisted-installer-using-the-assisted-installer.adoc

@@ -21,7 +21,7 @@ The {ai-full} provides installation functionality as a service. This software-as
 ** Eliminates the need to install and run the {product-title} installer locally.
 ** Ensures the latest version of the installer up to the latest tested z-stream releases. Older versions remain available, if needed.
 ** Enables building automation by using the API without the need to run the {product-title} installer locally.
-* *Advanced networking:* The {ai-full} supports IPv4 networking with SDN and OVN, IPv6 and dual stack networking with OVN only, NMState-based static IP addressing, and an HTTP/S proxy. OVN is the default Container Network Interface (CNI) for OpenShift Container Platform 4.12 and later releases. SDN is supported up to {product-title} 4.14, but is not supported for {product-title} 4.15 and later releases.
+* *Advanced networking:* The {ai-full} supports IPv4 and IPv6 networking, as well as dual-stack networking with the OVN-Kubernetes network plugin, NMState-based static IP addressing, and an HTTP/S proxy. OVN-Kubernetes is the default Container Network Interface (CNI) for {product-title} 4.12 and later releases. OpenShift SDN is supported up to {product-title} 4.14, but is not supported for {product-title} 4.15 and later releases.
 
 * *Preinstallation validation:* The {ai-full} validates the configuration before installation to ensure a high probability of success. The validation process includes the following checks:
 ** Ensuring network connectivity

modules/baseline-router-performance.adoc

@@ -21,7 +21,7 @@ When evaluating a single HAProxy router performance in terms of HTTP requests ha
 
 * Back end server page size
 
-* Underlying infrastructure (network/SDN solution, CPU, and so on)
+* Underlying infrastructure (network, CPU, and so on)
 
 While performance in your specific environment will vary, Red Hat lab tests on a public cloud instance of size 4 vCPU/16GB RAM. A single HAProxy router handling 100 routes terminated by backends serving 1kB static pages is able to handle the following number of transactions per second.
 

modules/configuring-default-seccomp-profile.adoc

@@ -53,7 +53,7 @@ metadata:
   annotations:
     k8s.v1.cni.cncf.io/network-status: |-
       [{
-          "name": "openshift-sdn",
+          "name": "ovn-kubernetes",
           "interface": "eth0",
           "ips": [
               "10.131.0.18"
@@ -63,7 +63,7 @@ metadata:
       }]
     k8s.v1.cni.cncf.io/network-status: |-
       [{
-          "name": "openshift-sdn",
+          "name": "ovn-kubernetes",
           "interface": "eth0",
           "ips": [
               "10.131.0.18"

modules/dr-restoring-cluster-state-about.adoc

@@ -18,7 +18,7 @@ Restoring to a previous cluster state is a destructive and destablizing action t
 If you are able to retrieve data using the Kubernetes API server, then etcd is available and you should not restore using an etcd backup.
 ====
 
-Restoring etcd effectively takes a cluster back in time and all clients will experience a conflicting, parallel history. This can impact the behavior of watching components like kubelets, Kubernetes controller managers, SDN controllers, and persistent volume controllers.
+Restoring etcd effectively takes a cluster back in time and all clients will experience a conflicting, parallel history. This can impact the behavior of watching components like kubelets, Kubernetes controller managers, persistent volume controllers, and OpenShift operators, including the network operator.
 
 It can cause Operator churn when the content in etcd does not match the actual content on disk, causing Operators for the Kubernetes API server, Kubernetes controller manager, Kubernetes scheduler, and etcd to get stuck when files on disk conflict with content in etcd. This can require manual actions to resolve the issues.
 

modules/getting-started-cli-examining-pod.adoc

@@ -55,7 +55,7 @@ Labels:       app=national-parks-app
               role=frontend
 Annotations:  k8s.v1.cni.cncf.io/network-status:
                 [{
-                    "name": "openshift-sdn",
+                    "name": "ovn-kubernetes",
                     "interface": "eth0",
                     "ips": [
                         "10.131.0.14"
@@ -65,7 +65,7 @@ Annotations:  k8s.v1.cni.cncf.io/network-status:
                 }]
               k8s.v1.cni.cncf.io/network-status:
                 [{
-                    "name": "openshift-sdn",
+                    "name": "ovn-kubernetes",
                     "interface": "eth0",
                     "ips": [
                         "10.131.0.14"
@@ -117,9 +117,9 @@ Events:
   Type    Reason          Age   From               Message
   ----    ------          ----  ----               -------
   Normal  Scheduled       46s   default-scheduler  Successfully assigned user-getting-started/parksmap-848bd4954b-5pvcc to ci-ln-fr1rt92-72292-4fzf9-worker-a-g9g7c
-  Normal  AddedInterface  44s   multus             Add eth0 [10.131.0.14/23] from openshift-sdn
+  Normal  AddedInterface  44s   multus             Add eth0 [10.131.0.14/23] from ovn-kubernetes
   Normal  Pulling         44s   kubelet            Pulling image "quay.io/openshiftroadshow/parksmap@sha256:89d1e324846cb431df9039e1a7fd0ed2ba0c51aafbae73f2abd70a83d5fa173b"
   Normal  Pulled          35s   kubelet            Successfully pulled image "quay.io/openshiftroadshow/parksmap@sha256:89d1e324846cb431df9039e1a7fd0ed2ba0c51aafbae73f2abd70a83d5fa173b" in 9.49243308s
   Normal  Created         35s   kubelet            Created container parksmap
   Normal  Started         35s   kubelet            Started container parksmap
-----
+----

modules/how-to-plan-your-environment-according-to-cluster-maximums.adoc

@@ -42,4 +42,4 @@ Where:
 required pods per cluster / total number of nodes = expected pods per node
 ----
 
-{product-title} comes with several system pods, such as SDN, DNS, Operators, and others, which run across every worker node by default. Therefore, the result of the above formula can vary.
+{product-title} comes with several system pods, such as OVN-Kubernetes, DNS, Operators, and others, which run across every worker node by default. Therefore, the result of the above formula can vary.

modules/ibm-z-choose-networking-setup.adoc

@@ -14,5 +14,5 @@ Depending on your setup, consider these best practices:
 * Always use the latest available NIC version. For example, OSA Express 7S 10 GbE shows great improvement compared to OSA Express 6S 10 GbE with transactional workload types, although both are 10 GbE adapters.
 * Each virtual switch adds an additional layer of latency.
 * The load balancer plays an important role for network communication outside the cluster. Consider using a production-grade hardware load balancer if this is critical for your application.
-* {product-title} SDN introduces flows and rules, which impact the networking performance. Make sure to consider pod affinities and placements, to benefit from the locality of services where communication is critical.
+* {product-title} OVN-Kubernetes network plugin introduces flows and rules, which impact the networking performance. Make sure to consider pod affinities and placements, to benefit from the locality of services where communication is critical.
 * Balance the trade-off between performance and functionality.

modules/installation-osp-creating-sr-iov-compute-machines.adoc

@@ -63,7 +63,7 @@ After standing up the control plane, create compute machines that run on the SR-
     nic_list: []
 
   tasks:
-  # Create the SDN/primary port for each worker node
+  # Create the primary port for each worker node
   - name: 'Create the Compute ports'
     os_port:
       name: "{{ item.1 }}-{{ item.0 }}"
@@ -75,7 +75,7 @@ After standing up the control plane, create compute machines that run on the SR-
     with_indexed_items: "{{ [os_port_worker] * os_compute_nodes_number }}"
     register: ports
 
-  # Tag each SDN/primary port with cluster name
+  # Tag each primary port with cluster name
   - name: 'Set Compute ports tag'
     command:
       cmd: "openstack port set --tag {{ cluster_id_tag }} {{ item.1 }}-{{ item.0 }}"