Minor doc updates (#594)

Author: thegridman

docs/logging/020_logging.adoc

@@ -140,13 +140,13 @@ spec:
       - "-Dcoherence.log.logger=com.oracle.coherence"
       - "-Djava.util.logging.config.file=/coherence-operator/utils/logging/logging.properties"
   volumes:
-    - name: logs           # <1>
+    - name: logs
       emptyDir: {}
   volumeMounts:
-    - name: logs           # <2>
+    - name: logs
       mountPath: /logs
   sideCars:
-    - name: fluentd                                                                    # <1>
+    - name: fluentd                                     # <1>
       image: "fluent/fluentd-kubernetes-daemonset:v1.14-debian-elasticsearch7-1"
       args:
         - "-c"

docs/management/020_management_over_rest.adoc

@@ -191,7 +191,7 @@ Which should result in a response similar to the following:
 
 === Access the Swagger Endpoint
 
-Issue the following `curl` command to access the Sagger endpoint, which documents all the REST API's available.
+Issue the following `curl` command to access the Swagger endpoint, which documents all the REST APIs available.
 
 [source,bash]
 ----

docs/ordering/010_overview.adoc

@@ -14,7 +14,7 @@ The default behaviour of the operator is to create the `StatefulSet` for a `Cohe
 Sometimes this behaviour is not suitable if, for example, when application code running in one deployment depends on the
 availability of another deployment.
 Typically, this might be storage disabled members having functionality that relies on the storage members being ready first.
-The `Coherence` CRD allows can be configured with a `startQuorum` that defines a deployment's dependency on other
+The `Coherence` CRD can be configured with a `startQuorum` that defines a deployment's dependency on other
 deployments in the cluster.
 
 NOTE: The `startQuorum` only applies when a cluster is initially being started by the operator, it does not apply in other

docs/ports/020_container_ports.adoc

@@ -56,7 +56,7 @@ spec:
 The `name` field in the `Coherence` CRD's port spec maps to the `name` field in the Container port spec.
 <2> The `port` field in the `Coherence` CRD's port spec maps to the `containerPort` in the Container port spec.
 
-For each additional port the Operator will create a `Service` of tyep `ClusterIP` with a default configuration.
+For each additional port the Operator will create a `Service` of type `ClusterIP` with a default configuration.
 The name of the service will be the `Coherence` resource's name with the port name appended to it,
 so in this case it will be `test-cluster-rest`. The `Service` might look like this:
 

docs/scaling/010_overview.adoc

@@ -95,7 +95,7 @@ spec:
 === Scaling StatusHA Probe
 
 The StatusHA check performed by the Operator uses a http endpoint that the Operator runs on a well-known port in the
-Coherence JVM. This endpoint does performs a simple check to verify that none of the partitioned cache services known
+Coherence JVM. This endpoint performs a simple check to verify that none of the partitioned cache services known
 about by Coherence have an endangered status. If an application has a different concept of what "safe" means it can
 implement a different method to check the status during scaling.
 
@@ -105,7 +105,7 @@ types of probe to be configured.
 
 ==== Using a HTTP Get Probe
 
-A HTTP get probe works the same way as a
+An HTTP get probe works the same way as a
 https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-a-liveness-http-request[Kubernetes liveness http request]
 
 The probe can be configured as follows
@@ -147,7 +147,7 @@ spec:
 
 ==== Using an Exec Command Probe
 
-A TCP probe works the same way as a
+An exec probe works the same way as a
 https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-a-liveness-command[Kubernetes Exec liveness probe]
 
 The probe can be configured as follows