Merge pull request #44655 from jboxman-rh/fix-rogue-pods

jab-rh · web-flow · commit 69b5ebb84ec8 · 2022-04-18T13:47:44.000-04:00
Apply lowercase pod convention
diff --git a/logging/cluster-logging-release-notes.adoc b/logging/cluster-logging-release-notes.adoc
@@ -111,7 +111,7 @@ To see these metrics, open the *Administrator* perspective in the {product-title
 
 * Before this update, some log entries had unrecognized UTF-8 bytes, which caused Elasticsearch to reject the messages and block the entire buffered payload. With this update, rejected payloads drop the invalid log entries and resubmit the remaining entries to resolve the issue. (link:https://issues.redhat.com/browse/LOG-1499[LOG-1499])
 
-* Before this update, the `kibana-proxy` Pod sometimes entered the `CrashLoopBackoff` state and logged the following message `Invalid configuration: cookie_secret must be 16, 24, or 32 bytes to create an AES cipher when pass_access_token == true or cookie_refresh != 0, but is 29 bytes.` The exact actual number of bytes could vary. With this update, the generation of the Kibana session secret has been corrected, and the kibana-proxy Pod no longer enters a `CrashLoopBackoff` state due to this error. (link:https://issues.redhat.com/browse/LOG-1446[LOG-1446])
+* Before this update, the `kibana-proxy` pod sometimes entered the `CrashLoopBackoff` state and logged the following message `Invalid configuration: cookie_secret must be 16, 24, or 32 bytes to create an AES cipher when pass_access_token == true or cookie_refresh != 0, but is 29 bytes.` The exact actual number of bytes could vary. With this update, the generation of the Kibana session secret has been corrected, and the kibana-proxy pod no longer enters a `CrashLoopBackoff` state due to this error. (link:https://issues.redhat.com/browse/LOG-1446[LOG-1446])
 
 * Before this update, the AWS CloudWatch Fluentd plug-in logged its AWS API calls to the Fluentd log at all log levels, consuming additional {product-title} node resources. With this update, the AWS CloudWatch Fluentd plug-in logs AWS API calls only at the "debug" and "trace" log levels. This way, at the default "warn" log level, Fluentd does not consume extra node resources. (link:https://issues.redhat.com/browse/LOG-1071[LOG-1071])
 
diff --git a/modules/builds-using-secrets.adoc b/modules/builds-using-secrets.adoc
@@ -57,7 +57,7 @@ stringData:
 <3> File contains the provided string.
 <4> File contains the provided data.
 +
-.YAML of a Pod Populating Files in a Volume with Secret Data
+.YAML of a pod populating files in a volume with secret data
 [source,yaml]
 ----
 apiVersion: v1
@@ -81,7 +81,7 @@ spec:
   restartPolicy: Never
 ----
 +
-.YAML of a Pod Populating Environment Variables with Secret Data
+.YAML of a pod populating environment variables with secret data
 [source,yaml]
 ----
 apiVersion: v1
diff --git a/modules/certificate-injection-using-operators.adoc b/modules/certificate-injection-using-operators.adoc
@@ -31,7 +31,7 @@ injects certificates across any namespace when an empty ConfigMap is created wit
 `config.openshift.io/inject-trusted-cabundle=true` label.
 
 The ConfigMap can reside in any namespace, but the ConfigMap must be mounted as
-a volume to each container within a Pod that requires a custom CA. For example:
+a volume to each container within a pod that requires a custom CA. For example:
 
 [source,yaml]
 ----
diff --git a/modules/cluster-logging-collector-log-forward-cloudwatch.adoc b/modules/cluster-logging-collector-log-forward-cloudwatch.adoc
@@ -92,7 +92,7 @@ $ oc get Infrastructure/cluster -ojson | jq .status.infrastructureName
 "mycluster-7977k"
 ----
 
-To generate log data for this example, you run a `busybox` Pod in a namespace called `app`. The `busybox` Pod writes a message to stdout every three seconds:
+To generate log data for this example, you run a `busybox` pod in a namespace called `app`. The `busybox` pod writes a message to stdout every three seconds:
 
 [source,terminal]
 ----
@@ -105,7 +105,7 @@ My life is my message
 ----
 
 
-You can look up the UUID of the `app` namespace where the `busybox` Pod runs:
+You can look up the UUID of the `app` namespace where the `busybox` pod runs:
 
 [source,terminal]
 ----
diff --git a/modules/cluster-logging-configuration-of-json-log-data-for-default-elasticsearch.adoc b/modules/cluster-logging-configuration-of-json-log-data-for-default-elasticsearch.adoc
@@ -13,7 +13,7 @@ If you forward JSON logs to the default Elasticsearch instance managed by OpenSh
 You can use the following structure types in the `ClusterLogForwarder` CR to construct index names for the Elasticsearch log store:
 
 * `structuredTypeKey` (string, optional) is the name of a message field. The value of that field, if present, is used to construct the index name.
-** `kubernetes.labels.<key>` is the Kubernetes Pod label whose value is used to construct the index name.
+** `kubernetes.labels.<key>` is the Kubernetes pod label whose value is used to construct the index name.
 ** `openshift.labels.<key>` is the `pipeline.label.<key>` element in the `ClusterLogForwarder` CR whose value is used to construct the index name.
 ** `kubernetes.container_name` uses the container name to construct the index name.
 * `structuredTypeName`: (string, optional) If `structuredTypeKey` is not set or its key is not present, OpenShift Logging uses the value of `structuredTypeName` as the structured type. When you use both `structuredTypeKey` and `structuredTypeName` together,  `structuredTypeName` provides a fallback index name if the key in `structuredTypeKey` is missing from the JSON log data.
diff --git a/modules/cnf-creating-the-performance-profile-object.adoc b/modules/cnf-creating-the-performance-profile-object.adoc
@@ -53,7 +53,7 @@ realTimeKernel:
 +
 `reserved` - The housekeeping CPUs. Threads in the reserved group tend to be very busy, so latency-sensitive
 applications should be run in the isolated group.
-See link:https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/#create-a-pod-that-gets-assigned-a-qos-class-of-guaranteed[Create a Pod that gets assigned a QoS class of `Guaranteed`].
+See link:https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/#create-a-pod-that-gets-assigned-a-qos-class-of-guaranteed[Create a pod that gets assigned a QoS class of `Guaranteed`].
 
 For example, you can reserve cores (threads) from a single NUMA node and put your workloads on another NUMA node.
 The reason for this is that the housekeeping CPUs may be touching caches in the CPU.
diff --git a/modules/customize-certificates-add-service-serving-configmap.adoc b/modules/customize-certificates-add-service-serving-configmap.adoc
@@ -6,7 +6,7 @@
 [id="add-service-certificate-configmap_{context}"]
 = Add the service CA bundle to a config map
 
-A Pod can access the service CA certificate by mounting a `ConfigMap` object that
+A pod can access the service CA certificate by mounting a `ConfigMap` object that
 is annotated with `service.beta.openshift.io/inject-cabundle=true`.
 Once annotated, the cluster automatically injects the service CA
 certificate into the `service-ca.crt` key on the config map. Access to
diff --git a/modules/dedicated-aws-vpc-verifying-troubleshooting.adoc b/modules/dedicated-aws-vpc-verifying-troubleshooting.adoc
@@ -30,7 +30,7 @@ working correctly.
 helpful troubleshooting tool. It is included in the default image and provides
 quick and clear output if a connection can be established:
 
-.. Create a temporary Pod using the `busybox` image, which cleans up after itself:
+.. Create a temporary pod using the `busybox` image, which cleans up after itself:
 +
 ----
 $ oc run netcat-test \
diff --git a/modules/dedicated-aws-vpn-verifying.adoc b/modules/dedicated-aws-vpn-verifying.adoc
@@ -28,7 +28,7 @@ To test network connectivity to an endpoint device, `nc` (or `netcat`) is a
 helpful troubleshooting tool. It is included in the default image and provides
 quick and clear output if a connection can be established:
 
-.. Create a temporary Pod using the `busybox` image, which cleans up after itself:
+.. Create a temporary pod using the `busybox` image, which cleans up after itself:
 +
 ----
 $ oc run netcat-test \
diff --git a/modules/dedicated-cluster-install-deploy.adoc b/modules/dedicated-cluster-install-deploy.adoc
@@ -64,7 +64,7 @@ If either operator does not appear as installed, to troubleshoot further:
 +
 * Switch to the *Operators* → *Installed Operators* page and inspect
 the *Status* column for any errors or failures.
-* Switch to the *Workloads* → *Pods* page and check the logs in each Pod in the
+* Switch to the *Workloads* → *Pods* page and check the logs in each pod in the
 `openshift-logging` project that is reporting issues.
 
 . Create and deploy an OpenShift Logging instance:
diff --git a/modules/ephemeral-storage-csi-inline-pod.adoc b/modules/ephemeral-storage-csi-inline-pod.adoc
@@ -4,7 +4,7 @@
 
 :_content-type: PROCEDURE
 [id="ephemeral-storage-csi-inline-pod_{context}"]
-= Embedding a CSI inline ephemeral volume in the Pod specification
+= Embedding a CSI inline ephemeral volume in the pod specification
 
 You can embed a CSI inline ephemeral volume in the `Pod` specification in {product-title}. At runtime, nested inline volumes follow the ephemeral lifecycle of their associated pods so that the CSI driver handles all phases of volume operations as pods are created and destroyed.
 
diff --git a/modules/nodes-cluster-limit-ranges-about.adoc b/modules/nodes-cluster-limit-ranges-about.adoc
@@ -18,7 +18,7 @@ enumerated constraints, the resource is rejected.
 ifdef::openshift-online[]
 [IMPORTANT]
 ====
-For {product-title} Pro, the maximum Pod memory is 3Gi. The minimum Pod or
+For {product-title} Pro, the maximum pod memory is 3Gi. The minimum pod or
 container memory that you can specify is 100Mi.
 
 ====
diff --git a/modules/nodes-containers-downward-api-about.adoc b/modules/nodes-containers-downward-api-about.adoc
@@ -3,7 +3,7 @@
 // * nodes/nodes-containers-downward-api.adoc
 
 [id="nodes-containers-projected-volumes-about_{context}"]
-= Expose Pod information to Containers using the Downward API
+= Expose pod information to Containers using the Downward API
 
 The Downward API contains such information as the pod's name, project, and resource values. Containers can consume
 information from the downward API using environment variables or a volume
diff --git a/modules/nodes-containers-init-about.adoc b/modules/nodes-containers-init-about.adoc
@@ -28,7 +28,7 @@ For example, the following are some ways you can use Init Containers:
 for i in {1..100}; do sleep 1; if dig myservice; then exit 0; fi; done; exit 1
 ----
 
-* Register this Pod with a remote server from the downward API with a command like:
+* Register this pod with a remote server from the downward API with a command like:
 +
 [source,terminal]
 ----
diff --git a/modules/nodes-containers-init-creating.adoc b/modules/nodes-containers-init-creating.adoc
@@ -6,7 +6,7 @@
 [id="nodes-containers-init-creating_{context}"]
 = Creating Init Containers
 
-The following example outlines a simple Pod which has two Init Containers. The first waits for `myservice` and the second waits for `mydb`. After both containers complete, the pod begins.
+The following example outlines a simple pod which has two Init Containers. The first waits for `myservice` and the second waits for `mydb`. After both containers complete, the pod begins.
 
 .Procedure
 
diff --git a/modules/nodes-nodes-working-evacuating.adoc b/modules/nodes-nodes-working-evacuating.adoc
@@ -65,8 +65,8 @@ controller, replica set, job, daemon set, or stateful set:
 $ oc adm drain <node1> <node2> --force=true
 ----
 
-** Set a period  of time in seconds for each Pod to
-terminate gracefully, use `--grace-period`. If negative, the default value specified in the Pod will
+** Set a period  of time in seconds for each pod to
+terminate gracefully, use `--grace-period`. If negative, the default value specified in the pod will
 be used:
 +
 [source,terminal]
diff --git a/modules/nodes-pods-configmaps-use-case-setting-command-line-arguments.adoc b/modules/nodes-pods-configmaps-use-case-setting-command-line-arguments.adoc
@@ -52,7 +52,7 @@ spec:
 ----
 <1> Inject the values into a command in a container using the keys you want to use as environment variables.
 +
-When this Pod is run, the output from the echo command run in the test-container container is as follows:
+When this pod is run, the output from the echo command run in the test-container container is as follows:
 +
 ----
 very charm
diff --git a/modules/nodes-pods-configuring-bandwidth.adoc b/modules/nodes-pods-configuring-bandwidth.adoc
@@ -21,7 +21,7 @@ To limit the bandwidth on a pod:
 `kubernetes.io/ingress-bandwidth` and `kubernetes.io/egress-bandwidth`
 annotations. For example, to limit both pod egress and ingress bandwidth to 10M/s:
 +
-.Limited Pod Object Definition
+.Limited `Pod` object definition
 [source,json]
 ----
 {
diff --git a/modules/nodes-scheduler-node-selectors-about.adoc b/modules/nodes-scheduler-node-selectors-about.adoc
@@ -211,7 +211,7 @@ metadata:
 +
 When you create the pod using the example pod spec in this example project, the pod is created with the project node selectors and is scheduled on the labeled node:
 +
-.Example Pod object
+.Example `Pod` object
 [source,yaml]
 ----
 apiVersion: v1
@@ -235,7 +235,7 @@ pod-s1   1/1     Running   0          20s   10.131.2.6   ci-ln-qg1il3k-f76d1-hlm
 +
 A pod in the project is not created or scheduled if the pod contains different node selectors. For example, if you deploy the following pod into the example project, it is not be created:
 +
-.Example Pod object with an invalid node selector
+.Example `Pod` object with an invalid node selector
 [source,yaml]
 ----
 apiVersion: v1
diff --git a/modules/nodes-scheduler-taints-tolerations-adding.adoc b/modules/nodes-scheduler-taints-tolerations-adding.adoc
@@ -90,5 +90,5 @@ spec:
 ----
 ====
 +
-The tolerations on the Pod match the taint on the node. A pod with either toleration can be scheduled onto `node1`.
+The tolerations on the pod match the taint on the node. A pod with either toleration can be scheduled onto `node1`.
 
diff --git a/modules/nw-egress-router-pod.adoc b/modules/nw-egress-router-pod.adoc
@@ -100,7 +100,7 @@ spec:
 <3> Same value as the default gateway used by the node.
 <4> External server to direct traffic to. Using this example, connections to the pod are redirected to `203.0.113.25`, with a source IP address of `192.168.12.99`.
 
-.Example egress router Pod specification
+.Example egress router pod specification
 [source,yaml,subs="attributes+"]
 ----
 apiVersion: v1
diff --git a/modules/odc-adding-health-checks.adoc b/modules/odc-adding-health-checks.adoc
@@ -30,6 +30,6 @@ The `Timeout` value must be lower than the `Period` value. The `Timeout` default
 .. Click the check mark at the bottom of the form. The *Readiness Probe Added* message is displayed.
 
 . Click *Add* to add the health check. You are redirected to the *Topology* view and the container is restarted.
-. In the side panel, verify that the probes have been added by clicking on the deployed Pod under the *Pods* section.
+. In the side panel, verify that the probes have been added by clicking on the deployed pod under the *Pods* section.
 . In the *Pod Details* page, click the listed container in the *Containers* section.
 . In the *Container Details* page, verify that the Readiness probe - *Exec Command* `cat` `/tmp/healthy` has been added to the container.
diff --git a/modules/odc-interacting-with-applications-and-components.adoc b/modules/odc-interacting-with-applications-and-components.adoc
@@ -11,7 +11,7 @@ The *Topology* view in the *Developer* perspective of the web console provides t
 This feature is available only when you create applications using the *From Git*, *From Catalog*, and the *From Dockerfile* options.
 ====
 +
-* Hover your cursor over the lower left icon on the Pod to see the name of the latest build and its status. The status of the application build is indicated as *New* (image:odc_build_new.png[title="New Build"]), *Pending* (image:odc_build_pending.png[title="Pending Build"]), *Running* (image:odc_build_running.png[title="Running Build"]), *Completed* (image:odc_build_completed.png[title="Completed Build"]), *Failed* (image:odc_build_failed.png[title="Failed Build"]), and *Canceled* (image:odc_build_canceled.png[title="Canceled Build"]).
+* Hover your cursor over the lower left icon on the pod to see the name of the latest build and its status. The status of the application build is indicated as *New* (image:odc_build_new.png[title="New Build"]), *Pending* (image:odc_build_pending.png[title="Pending Build"]), *Running* (image:odc_build_running.png[title="Running Build"]), *Completed* (image:odc_build_completed.png[title="Completed Build"]), *Failed* (image:odc_build_failed.png[title="Failed Build"]), and *Canceled* (image:odc_build_canceled.png[title="Canceled Build"]).
 * The status or phase of the pod is indicated by different colors and tooltips as:
 ** *Running* (image:odc_pod_running.png[title="Pod Running"]): The pod is bound to a node and all of the containers are created. At least one container is still running or is in the process of starting or restarting.
 ** *Not Ready* (image:odc_pod_not_ready.png[title="Pod Not Ready"]): The pods which are running multiple containers, not all containers are ready.
diff --git a/modules/ossm-rn-fixed-issues-1x.adoc b/modules/ossm-rn-fixed-issues-1x.adoc
@@ -23,7 +23,7 @@ The following issues been resolved in the current release:
 
 * link:https://issues.redhat.com/browse/OSSM-542[OSSM-542] Galley is not using the new certificate after rotation.
 
-* link:https://issues.jboss.org/browse/OSSM-99[OSSM-99] Workloads generated from direct Pod without labels may crash Kiali.
+* link:https://issues.jboss.org/browse/OSSM-99[OSSM-99] Workloads generated from direct pod without labels may crash Kiali.
 
 * link:https://issues.jboss.org/browse/OSSM-93[OSSM-93] IstioConfigList can't filter by two or more names.
 
diff --git a/modules/pruning-images-manual.adoc b/modules/pruning-images-manual.adoc
@@ -211,7 +211,7 @@ information that this operation is not allowed.
 
 Separating the removal of {product-title} image API objects and image data from the registry by using `--prune-registry=false`, followed by hard pruning the registry, can narrow timing windows and is safer when compared to trying to prune both through one command. However, timing windows are not completely removed.
 
-For example, you can still create a Pod referencing an image as pruning identifies that image for pruning. You should still keep track of an API object created during the pruning operations that might reference images so that you can mitigate any references to deleted content.
+For example, you can still create a pod referencing an image as pruning identifies that image for pruning. You should still keep track of an API object created during the pruning operations that might reference images so that you can mitigate any references to deleted content.
 
 Re-doing the pruning without the `--prune-registry` option or with `--prune-registry=true` does not lead to pruning the associated storage in the image registry for images previously pruned by `--prune-registry=false`. Any images that were pruned with `--prune-registry=false` can only be deleted from registry storage by hard pruning the registry.
 
diff --git a/modules/pruning-images.adoc b/modules/pruning-images.adoc
@@ -56,10 +56,10 @@ status:
 <3> `keepTagRevisions`: The number of revisions per tag to keep. This is an optional field, default is `3`. The initial value is `3`.
 <4> `keepYoungerThanDuration`: Retain images younger than this duration. This is an optional field. If a value is not specified, either `keepYoungerThan` or the default value `60m` (60 minutes) is used.
 <5> `keepYoungerThan`: Deprecated. The same as `keepYoungerThanDuration`, but the duration is specified as an integer in nanoseconds. This is an optional field. When `keepYoungerThanDuration` is set, this field is ignored.
-<6> `resources`: Standard Pod resource requests and limits. This is an optional field.
-<7> `affinity`: Standard Pod affinity. This is an optional field.
-<8> `nodeSelector`: Standard Pod node selector. This is an optional field.
-<9> `tolerations`: Standard Pod tolerations. This is an optional field.
+<6> `resources`: Standard pod resource requests and limits. This is an optional field.
+<7> `affinity`: Standard pod affinity. This is an optional field.
+<8> `nodeSelector`: Standard pod node selector. This is an optional field.
+<9> `tolerations`: Standard pod tolerations. This is an optional field.
 <10> `successfulJobsHistoryLimit`: The maximum number of successful jobs to retain. Must be `>= 1` to ensure metrics are reported. This is an optional field, default is `3`. The initial value is `3`.
 <11> `failedJobsHistoryLimit`: The maximum number of failed jobs to retain. Must be `>= 1` to ensure metrics are reported. This is an optional field, default is `3`. The initial value is `3`.
 <12> `observedGeneration`: The generation observed by the Operator.
diff --git a/modules/storage-persistent-storage-efs-authorization.adoc b/modules/storage-persistent-storage-efs-authorization.adoc
@@ -64,7 +64,7 @@ roleRef:
   name: efs-provisioner-runner
   apiGroup: rbac.authorization.k8s.io
 ----
-<1> The namespace where the EFS provisioner Pod will run. If the EFS
+<1> The namespace where the EFS provisioner pod will run. If the EFS
 provisioner is running in a namespace other than `default`, this value must
 be updated.
 
@@ -101,7 +101,7 @@ roleRef:
   name: leader-locking-efs-provisioner
   apiGroup: rbac.authorization.k8s.io
 ----
-<1> The namespace where the EFS provisioner Pod will run. If the EFS
+<1> The namespace where the EFS provisioner pod will run. If the EFS
 provisioner is running in a namespace other than `default`, this value must
 be updated.
 
diff --git a/modules/storage-persistent-storage-nfs-group-ids.adoc b/modules/storage-persistent-storage-nfs-group-ids.adoc
@@ -18,7 +18,7 @@ To gain access to persistent storage, it is generally preferable to use suppleme
 ====
 
 Because the group ID on the example target NFS directory
-is `5555`, the Pod can define that group ID using `supplementalGroups`
+is `5555`, the pod can define that group ID using `supplementalGroups`
 under the `securityContext` definition of the pod. For example:
 
 [source,yaml]
diff --git a/modules/storage-persistent-storage-nfs-user-ids.adoc b/modules/storage-persistent-storage-nfs-user-ids.adoc
@@ -34,7 +34,7 @@ the pod.
 Assuming that the project is `default` and the SCC is `restricted`, the user ID of `65534` as requested by the pod is not allowed. Therefore, the pod fails for the following reasons:
 
 * It requests `65534` as its user ID.
-* All SCCs available to the Pod are examined to see which SCC allows a
+* All SCCs available to the pod are examined to see which SCC allows a
 user ID of `65534`. While all policies of the SCCs are checked, the focus
 here is on user ID.
 * Because all available SCCs use `MustRunAsRange` for their `runAsUser`
diff --git a/networking/cidr-range-definitions.adoc b/networking/cidr-range-definitions.adoc
diff --git a/openshift_images/using_images/images-other-jenkins-agent.adoc b/openshift_images/using_images/images-other-jenkins-agent.adoc
diff --git a/scalability_and_performance/using-topology-manager.adoc b/scalability_and_performance/using-topology-manager.adoc

Original file line number	Diff line number	Diff line change
`@@ -53,7 +53,7 @@ realTimeKernel:`
`53`	`53`	`+`
`54`	`54`	`reserved` - The housekeeping CPUs. Threads in the reserved group tend to be very busy, so latency-sensitive
`55`	`55`	`applications should be run in the isolated group.`
`56`		-See link:https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/#create-a-pod-that-gets-assigned-a-qos-class-of-guaranteed[Create a Pod that gets assigned a QoS class of `Guaranteed`].
	`56`	+See link:https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/#create-a-pod-that-gets-assigned-a-qos-class-of-guaranteed[Create a pod that gets assigned a QoS class of `Guaranteed`].
`57`	`57`
`58`	`58`	`For example, you can reserve cores (threads) from a single NUMA node and put your workloads on another NUMA node.`
`59`	`59`	`The reason for this is that the housekeeping CPUs may be touching caches in the CPU.`
Original file line number	Diff line number	Diff line change
`@@ -30,7 +30,7 @@ working correctly.`
`30`	`30`	`helpful troubleshooting tool. It is included in the default image and provides`
`31`	`31`	`quick and clear output if a connection can be established:`
`32`	`32`
`33`		-.. Create a temporary Pod using the `busybox` image, which cleans up after itself:
	`33`	+.. Create a temporary pod using the `busybox` image, which cleans up after itself:
`34`	`34`	`+`
`35`	`35`	`----`
`36`	`36`	`$ oc run netcat-test \`
Original file line number	Diff line number	Diff line change
@@ -28,7 +28,7 @@ To test network connectivity to an endpoint device, `nc` (or `netcat`) is a
`28`	`28`	`helpful troubleshooting tool. It is included in the default image and provides`
`29`	`29`	`quick and clear output if a connection can be established:`
`30`	`30`
`31`		-.. Create a temporary Pod using the `busybox` image, which cleans up after itself:
	`31`	+.. Create a temporary pod using the `busybox` image, which cleans up after itself:
`32`	`32`	`+`
`33`	`33`	`----`
`34`	`34`	`$ oc run netcat-test \`
Original file line number	Diff line number	Diff line change
`@@ -64,7 +64,7 @@ If either operator does not appear as installed, to troubleshoot further:`
`64`	`64`	`+`
`65`	`65`	`* Switch to the Operators → Installed Operators page and inspect`
`66`	`66`	`the Status column for any errors or failures.`
`67`		`-* Switch to the Workloads → Pods page and check the logs in each Pod in the`
	`67`	`+* Switch to the Workloads → Pods page and check the logs in each pod in the`
`68`	`68`	`openshift-logging` project that is reporting issues.
`69`	`69`
`70`	`70`	`. Create and deploy an OpenShift Logging instance:`