Merge pull request #27332 from jboxman/refresh-terms-networking

Refresh terminology style

Author: jboxman

modules/nw-about-multicast.adoc

@@ -28,12 +28,8 @@ Multicast traffic between {product-title} pods is disabled by default. If you ar
 ifdef::openshift-sdn[]
 When using the OpenShift SDN network plug-in in `networkpolicy` isolation mode:
 
-* Multicast packets sent by a pod will be delivered to all other pods in the
-project, regardless of NetworkPolicy objects. Pods might be able to communicate
-over multicast even when they cannot communicate over unicast.
-* Multicast packets sent by a pod in one project will never be delivered to pods
-in any other project, even if there are NetworkPolicy objects that allow
-communication between the projects.
+* Multicast packets sent by a pod will be delivered to all other pods in the project, regardless of `NetworkPolicy` objects. Pods might be able to communicate over multicast even when they cannot communicate over unicast.
+* Multicast packets sent by a pod in one project will never be delivered to pods in any other project, even if there are `NetworkPolicy` objects that allow communication between the projects.
 
 When using the OpenShift SDN network plug-in in `multitenant` isolation mode:
 

modules/nw-configuring-high-performance-multicast-with-sriov.adoc

@@ -10,7 +10,7 @@ For applications such as streaming media, like Internet Protocol television (IPT
 
 When using additional SR-IOV interfaces for multicast:
 
-* Multicast packages must be sent or received by a Pod through the additional SR-IOV interface.
+* Multicast packages must be sent or received by a pod through the additional SR-IOV interface.
 * The physical network which connects the SR-IOV interfaces decides the
 multicast routing and topology, which is not controlled by {product-title}.
 
@@ -26,7 +26,7 @@ The follow procedure creates an example SR-IOV interface for multicast.
 
 .Procedure
 
-. Create a SriovNetworkNodePolicy custom resource (CR):
+. Create a `SriovNetworkNodePolicy` object:
 +
 [source,yaml]
 ----
@@ -46,7 +46,7 @@ spec:
     rootDevices: ['0000:86:00.0']
 ----
 
-. Create a SriovNetwork CR:
+. Create a `SriovNetwork` object:
 +
 [source,yaml]
 ----
@@ -73,7 +73,7 @@ spec:
 ----
 <1> If you choose to configure DHCP as IPAM, ensure that you provision the following default routes through your DHCP server: `224.0.0.0/5` and `232.0.0.0/5`. This is to override the static multicast route set by the default network provider.
 
-. Create a Pod with multicast application:
+. Create a pod with multicast application:
 +
 [source,yaml]
 ----

modules/nw-dns-operator.adoc

@@ -5,15 +5,16 @@
 = DNS Operator
 
 The DNS Operator implements the `dns` API from the `operator.openshift.io` API
-group. The operator deploys CoreDNS using a daemon set, creates a Service for
+group. The Operator deploys CoreDNS using a daemon set, creates a service for
 the daemon set, and configures the kubelet to instruct pods to use the CoreDNS
-Service IP for name resolution.
+service IP address for name resolution.
 
 ifdef::openshift-enterprise,openshift-webscale,openshift-origin[]
 .Procedure
-The DNS Operator is deployed during installation as a Kubernetes `Deployment`.
 
-. Use the `oc get` command to view the Deployment status:
+The DNS Operator is deployed during installation with a `Deployment` object.
+
+. Use the `oc get` command to view the deployment status:
 +
 [source,terminal]
 ----
@@ -26,9 +27,6 @@ $ oc get -n openshift-dns-operator deployment/dns-operator
 NAME           READY     UP-TO-DATE   AVAILABLE   AGE
 dns-operator   1/1       1            1           23h
 ----
-ClusterOperator is the Custom Resource object which holds the current state
-of an operator. This object is used by operators to convey their state to
-the rest of the cluster.
 
 . Use the `oc get` command to view the state of the DNS Operator:
 +
@@ -44,7 +42,5 @@ NAME      VERSION     AVAILABLE   PROGRESSING   DEGRADED   SINCE
 dns       4.1.0-0.11  True        False         False      92m
 ----
 +
-`AVAILABLE`, `PROGRESSING` and `DEGRADED` provide information about the status of
-the operator. `AVAILABLE` is `True` when at least 1 pod from the CoreDNS DaemonSet
-is reporting an `Available` status condition.
+`AVAILABLE`, `PROGRESSING` and `DEGRADED` provide information about the status of the operator. `AVAILABLE` is `True` when at least 1 pod from the CoreDNS daemon set reports an `Available` status condition.
 endif::[]

modules/nw-dns-view.adoc

@@ -32,12 +32,12 @@ Status:
 ...
 ----
 <1> The Cluster Domain field is the base DNS domain used to construct fully
-qualified Pod and Service domain names.
+qualified pod and service domain names.
 <2> The Cluster IP is the address pods query for name resolution. The IP is
-defined as the 10th address in the Service CIDR range.
+defined as the 10th address in the service CIDR range.
 
 ifdef::openshift-enterprise,openshift-webscale,openshift-origin[]
-. To find the Service CIDR of your cluster,
+. To find the service CIDR of your cluster,
 use the `oc get` command:
 +
 [source,terminal]

modules/nw-egress-ips-about.adoc

@@ -134,13 +134,13 @@ Egress IP addresses must not be configured in any Linux network configuration fi
 Allowing additional IP addresses on the primary network interface might require extra configuration when using some cloud or VM solutions.
 ====
 
-You can assign egress IP addresses to namespaces by setting the `egressIPs` parameter of the `NetNamespace` resource. After an egress IP is associated with a project, OpenShift SDN allows you to assign egress IPs to hosts in two ways:
+You can assign egress IP addresses to namespaces by setting the `egressIPs` parameter of the `NetNamespace` object. After an egress IP is associated with a project, OpenShift SDN allows you to assign egress IPs to hosts in two ways:
 
 * In the _automatically assigned_ approach, an egress IP address range is assigned to a node.
 * In the _manually assigned_ approach, a list of one or more egress IP address is assigned to a node.
 
 Namespaces that request an egress IP address are matched with nodes that can host those egress IP addresses, and then the egress IP addresses are assigned to those nodes.
-If the `egressIPs` parameter is set on a `NetNamespace` resource, but no node hosts that egress IP address, then egress traffic from the namespace will be dropped.
+If the `egressIPs` parameter is set on a `NetNamespace` object, but no node hosts that egress IP address, then egress traffic from the namespace will be dropped.
 
 High availability of nodes is automatic.
 If a node that hosts an egress IP address is unreachable and there are nodes that are able to host that egress IP address, then the egress IP address will move to a new node.

modules/nw-egress-ips-automatic.adoc

@@ -15,7 +15,7 @@ for a specific namespace across one or more nodes.
 
 .Procedure
 
-. Update the `NetNamespace` resource with the egress IP address using the
+. Update the `NetNamespace` object with the egress IP address using the
 following JSON:
 +
 [source,terminal]

modules/nw-egress-ips-static.adoc

@@ -14,7 +14,7 @@ In {product-title} you can associate one or more egress IP addresses with a name
 
 .Procedure
 
-. Update the `NetNamespace` resource by specifying the following JSON
+. Update the `NetNamespace` object by specifying the following JSON
 object with the desired IP addresses:
 +
 [source,terminal]

modules/nw-enabling-multicast.adoc

@@ -43,7 +43,7 @@ To verify that multicast is enabled for a project, complete the following proced
 $ oc project <project>
 ----
 
-. Create a Pod to act as a multicast receiver:
+. Create a pod to act as a multicast receiver:
 +
 [source,terminal]
 ----
@@ -68,7 +68,7 @@ spec:
 EOF
 ----
 
-. Create a Pod to act as a multicast sender:
+. Create a pod to act as a multicast sender:
 +
 [source,terminal]
 ----
@@ -108,7 +108,7 @@ $ oc exec mlistener -i -t -- \
 
 . Start the multicast transmitter.
 
-.. Get the Pod network IP address range:
+.. Get the pod network IP address range:
 +
 [source,terminal]
 ----

modules/nw-externalip-about.adoc

@@ -5,22 +5,22 @@
 [id="nw-externalip-about_{context}"]
 = About ExternalIP
 
-For non-cloud environments, {product-title} supports the assignment of external IP addresses to a Service `spec.externalIPs` field through the *ExternalIP* facility.
-This exposes an additional virtual IP address, assigned to the Service, that can be outside the service network defined for the cluster.
-A Service configured with an external IP functions similarly to a Service with `type=NodePort`, allowing you to direct traffic to a local node for load balancing.
+For non-cloud environments, {product-title} supports the assignment of external IP addresses to a `Service` object `spec.externalIPs` field through the *ExternalIP* facility.
+This exposes an additional virtual IP address, assigned to the service, that can be outside the service network defined for the cluster.
+A service configured with an external IP functions similarly to a service with `type=NodePort`, allowing you to direct traffic to a local node for load balancing.
 
 You must configure your networking infrastructure to ensure that the external IP address blocks that you define are routed to the cluster.
 
 {product-title} extends the ExternalIP functionality in Kubernetes by adding the following capabilities:
 
 - Restrictions on the use of external IP addresses through a configurable policy
-- Allocation of an external IP address automatically to a Service upon request
+- Allocation of an external IP address automatically to a service upon request
 
-By default, only a user with `cluster-admin` privileges can create a Service with `spec.externalIPs[]` set to IP addresses defined within an external IP address block.
+By default, only a user with `cluster-admin` privileges can create a `Service` object with `spec.externalIPs[]` set to IP addresses defined within an external IP address block.
 
 [WARNING]
 ====
-Disabled by default, use of ExternalIP functionality can be a security risk, because in-cluster traffic to an external IP address is directed to that Service.
+Disabled by default, use of ExternalIP functionality can be a security risk, because in-cluster traffic to an external IP address is directed to that service.
 This could allow cluster users to intercept sensitive traffic destined for external resources.
 ====
 
@@ -33,19 +33,19 @@ For cloud deployments, use the load balancer services for automatic deployment o
 You can assign an external IP address in the following ways:
 
 Automatic assignment of an external IP::
-{product-title} automatically assigns an IP address from the `autoAssignCIDRs` CIDR block to the `spec.externalIPs[]` array when you create a Service with `spec.type=LoadBalancer` set.
-In this case, {product-title} implements a non-cloud version of the load balancer Service type and assigns IP addresses to the services.
+{product-title} automatically assigns an IP address from the `autoAssignCIDRs` CIDR block to the `spec.externalIPs[]` array when you create a `Service` object with `spec.type=LoadBalancer` set.
+In this case, {product-title} implements a non-cloud version of the load balancer service type and assigns IP addresses to the services.
 Automatic assignment is disabled by default and must be configured by a cluster administrator as described in the following section.
 
 Manual assignment of an external IP::
-{product-title} uses the IP addresses assigned to the `spec.externalIPs[]` array when you create a Service. You cannot specify an IP address that is already in use by another Service.
+{product-title} uses the IP addresses assigned to the `spec.externalIPs[]` array when you create a `Service` object. You cannot specify an IP address that is already in use by another service.
 
 [id="configuration-externalip_{context}"]
 == Configuration for ExternalIP
 
 Use of an external IP address in {product-title} is governed by the following fields in the `Network.config.openshift.io` CR named `cluster`:
 
-* `spec.externalIP.autoAssignCIDRs` defines an IP address block used by the load balancer when choosing an external IP address for the service. {product-title} supports only a single IP address block for automatic assignment. This can be simpler than having to manage the port space of a limited number of shared IP addresses when manually assigning ExternalIPs to services. If automatic assignment is enabled, a Service with `spec.type=LoadBalancer` is allocated an external IP address.
+* `spec.externalIP.autoAssignCIDRs` defines an IP address block used by the load balancer when choosing an external IP address for the service. {product-title} supports only a single IP address block for automatic assignment. This can be simpler than having to manage the port space of a limited number of shared IP addresses when manually assigning ExternalIPs to services. If automatic assignment is enabled, a `Service` object with `spec.type=LoadBalancer` is allocated an external IP address.
 * `spec.externalIP.policy` defines the permissible IP address blocks when manually specifying an IP address. {product-title} does not apply policy rules to IP address blocks defined by `spec.externalIP.autoAssignCIDRs`.
 
 If routed correctly, external traffic from the configured external IP address block can reach service endpoints through any TCP or UDP port that the service exposes.
@@ -65,9 +65,9 @@ of the ports exposed by other services.
 To use IP address blocks defined by `autoAssignCIDRs` in {product-title}, you must configure the necessary IP address assignment and routing for your host network.
 ====
 
-The following YAML describes a Service with an external IP configured:
+The following YAML describes a service with an external IP address configured:
 
-.Example Service object with `spec.externalIPs[]` set
+.Example `Service` object with `spec.externalIPs[]` set
 [source,yaml]
 ----
 apiVersion: v1
@@ -115,22 +115,22 @@ The policy object has the following shape:
 
 When configuring policy restrictions, the following rules apply:
 
-- If `policy={}` is set, then creating a Service with `spec.ExternalIPs[]` set will fail. This is the default for {product-title}.
-- If `policy=null` is set, then creating a Service with `spec.ExternalIPs[]` set to any IP address is allowed.
+- If `policy={}` is set, then creating a `Service` object with `spec.ExternalIPs[]` set will fail. This is the default for {product-title}.
+- If `policy=null` is set, then creating a `Service` object with `spec.ExternalIPs[]` set to any IP address is allowed.
 - If `policy` is set and either `policy.allowedCIDRs[]` or `policy.rejectedCIDRs[]` is set, the following rules apply:
 
 * If `allowedCIDRs[]` and `rejectedCIDRs[]` are both set, then `rejectedCIDRs[]` has precedence over `allowedCIDRs[]`.
-* If `allowedCIDRs[]` is set, creating a Service with `spec.ExternalIPs[]` will succeed only if the specified IP addresses are allowed.
-* If `rejectedCIDRs[]` is set, creating a Service with `spec.ExternalIPs[]` will succeed only if the specified IP addresses are not rejected.
+* If `allowedCIDRs[]` is set, creating a `Service` object with `spec.ExternalIPs[]` will succeed only if the specified IP addresses are allowed.
+* If `rejectedCIDRs[]` is set, creating a `Service` object with `spec.ExternalIPs[]` will succeed only if the specified IP addresses are not rejected.
 
 [id="example-policy-objects_{context}"]
 == Example policy objects
 
 The examples that follow demonstrate several different policy configurations.
 
-- In the following example, the policy prevents {product-title} from creating any Service with an external IP address specified:
+- In the following example, the policy prevents {product-title} from creating any service with an external IP address specified:
 +
-.Example policy to reject any value specified for Service `spec.externalIPs[]`
+.Example policy to reject any value specified for `Service` object `spec.externalIPs[]`
 [source,yaml]
 ----
 apiVersion: config.openshift.io/v1
@@ -165,7 +165,7 @@ spec:
 - In the following example, `policy` is set to `null`.
 If set to `null`, when inspecting the configuration object by entering `oc get networks.config.openshift.io -o yaml`, the `policy` field will not appear in the output.
 +
-.Example policy to allow any value specified for Service `spec.externalIPs[]`
+.Example policy to allow any value specified for `Service` object `spec.externalIPs[]`
 [source,yaml]
 ----
 apiVersion: config.openshift.io/v1

modules/nw-externalip-configuring.adoc

@@ -7,8 +7,8 @@
 
 As a cluster administrator, you can configure the following ExternalIP settings:
 
-- An ExternalIP address block used by {product-title} to automatically populate the `spec.clusterIP` field for a Service.
-- A policy object to restrict what IP addresses may be manually assigned to the `spec.clusterIP` array of a Service.
+- An ExternalIP address block used by {product-title} to automatically populate the `spec.clusterIP` field for a `Service` object.
+- A policy object to restrict what IP addresses may be manually assigned to the `spec.clusterIP` array of a `Service` object.
 
 .Prerequisites