WTD-21 - Update consul.md for Vale issue

doc/administration/consul.md

@@ -83,7 +83,7 @@ curl "http://127.0.0.1:8500/v1/health/state/critical"
 Consul nodes communicate using the raft protocol. If the current leader goes
 offline, there needs to be a leader election. A leader node must exist to facilitate
 synchronization across the cluster. If too many nodes go offline at the same time,
-the cluster will lose quorum and not elect a leader due to
+the cluster looses quorum and not elect a leader due to
 [broken consensus](https://www.consul.io/docs/architecture/consensus).
 
 Consult the [troubleshooting section](#troubleshooting-consul) if the cluster is not
@@ -122,19 +122,19 @@ db-a            XX.XX.X.Y:8301        alive   client  0.9.0  2         gitlab_co
 db-b            XX.XX.X.Y:8301        alive   client  0.9.0  2         gitlab_consul
 ```
 
-Ideally all nodes will have a `Status` of `alive`.
+Ideally all nodes have a `Status` of `alive`.
 
 ### Restart Consul
 
 If it is necessary to restart Consul, it is important to do this in
 a controlled manner to maintain quorum. If quorum is lost, to recover the cluster,
-you will need to follow the Consul [outage recovery](#outage-recovery) process.
+you follow the Consul [outage recovery](#outage-recovery) process.
 
 To be safe, it's recommended that you only restart Consul in one node at a time to
 ensure the cluster remains intact. For larger clusters, it is possible to restart
 multiple nodes at a time. See the
 [Consul consensus document](https://www.consul.io/docs/architecture/consensus#deployment-table)
-for how many failures it can tolerate. This will be the number of simultaneous
+for the number of failures it can tolerate. This will be the number of simultaneous
 restarts it can sustain.
 
 To restart Consul:
@@ -145,13 +145,13 @@ sudo gitlab-ctl restart consul
 
 ### Consul nodes unable to communicate
 
-By default, Consul will attempt to
+By default, Consul attempts to
 [bind](https://www.consul.io/docs/agent/options#_bind) to `0.0.0.0`, but
-it will advertise the first private IP address on the node for other Consul nodes
+it advertises the first private IP address on the node for other Consul nodes
 to communicate with it. If the other nodes cannot communicate with a node on
-this address, then the cluster will have a failed status.
+this address, then the cluster has a failed status.
 
-If you are running into this issue, you will see messages like the following in `gitlab-ctl tail consul` output:
+If you run into this issue, then messages like the following are output in `gitlab-ctl tail consul`:
 
 ```plaintext
 2017-09-25_19:53:39.90821     2017/09/25 19:53:39 [WARN] raft: no known peers, aborting election
@@ -181,10 +181,10 @@ If you still see the errors, you may have to
 
 ### Consul does not start - multiple private IPs
 
-In case that a node has multiple private IPs, Consul will be confused as to
+If a node has multiple private IPs, Consul will be confused about
 which of the private addresses to advertise, and then immediately exit on start.
 
-You will see messages like the following in `gitlab-ctl tail consul` output:
+Messages like the following are output in `gitlab-ctl tail consul`:
 
 ```plaintext
 2017-11-09_17:41:45.52876 ==> Starting Consul agent...
@@ -211,8 +211,8 @@ To fix this:
 
 ### Outage recovery
 
-If you lost enough Consul nodes in the cluster to break quorum, then the cluster
-is considered failed, and it will not function without manual intervention.
+If you have lost enough Consul nodes in the cluster to break quorum, then the cluster
+is considered to have failed and cannot function without manual intervention.
 In that case, you can either recreate the nodes from scratch or attempt a
 recover.
 

doc/administration/geo/index.md

@@ -27,7 +27,7 @@ to clone and fetch large repositories, speeding up development.
 
 For a video introduction to Geo, see [Introduction to GitLab Geo - GitLab Features](https://www.youtube.com/watch?v=-HDLxSjEh6w).
 
-To make sure you're using the right version of the documentation, navigate to [the source version of this page on GitLab.com](https://gitlab.com/gitlab-org/gitlab/blob/master/doc/administration/geo/index.md) and choose the appropriate release from the **Switch branch/tag** dropdown. For example, [`v11.2.3-ee`](https://gitlab.com/gitlab-org/gitlab/blob/v11.2.3-ee/doc/administration/geo/index.md).
+To make sure you're using the right version of the documentation, navigate to [this page on GitLab.com](https://gitlab.com/gitlab-org/gitlab/blob/master/doc/administration/geo/index.md) and choose the appropriate release from the **Switch branch/tag** dropdown. For example, [`v11.2.3-ee`](https://gitlab.com/gitlab-org/gitlab/blob/v11.2.3-ee/doc/administration/geo/index.md).
 
 ## Use cases
 

doc/ci/yaml/script.md

@@ -86,7 +86,7 @@ Second command line.
 When you omit the `>` or `|` block scalar indicators, GitLab concatenates non-empty
 lines to form the command. Make sure the lines can run when concatenated.
 
-[Shell here documents](https://en.wikipedia.org/wiki/Here_document) work with the
+[These documents](https://en.wikipedia.org/wiki/Here_document) work with the
 `|` and `>` operators as well. The example below transliterates lower case letters
 to upper case:
 

doc/development/go_guide/index.md

@@ -449,12 +449,12 @@ Once you've picked a new Go version to use, the steps to update Omnibus and CNG
 are:
 
 - [Create a merge request in the CNG project](https://gitlab.com/gitlab-org/build/CNG/-/edit/master/ci_files/variables.yml?branch_name=update-go-version),
-  updating the `GO_VERSION` in `ci_files/variables.yml`.
+  update the `GO_VERSION` in `ci_files/variables.yml`.
 - [Create a merge request in the `gitlab-omnibus-builder` project](https://gitlab.com/gitlab-org/gitlab-omnibus-builder/-/edit/master/docker/VERSIONS?branch_name=update-go-version),
-  updating the `GO_VERSION` in `docker/VERSIONS`.
+  update the `GO_VERSION` in `docker/VERSIONS`.
 - Tag a new release of `gitlab-omnibus-builder` containing the change.
 - [Create a merge request in the `omnibus-gitlab` project](https://gitlab.com/gitlab-org/omnibus-gitlab/edit/master/.gitlab-ci.yml?branch_name=update-gitlab-omnibus-builder-version),
-  updating the `BUILDER_IMAGE_REVISION` to match the newly-created tag.
+  update the `BUILDER_IMAGE_REVISION` to match the newly-created tag.
 
 To reduce unnecessary differences between two distribution methods, Omnibus and
 CNG **should always use the same Go version**.

doc/development/multi_version_compatibility.md

@@ -65,7 +65,7 @@ Let's see how we can handle them safely.
 ### Route changes
 
 When changing routing we should pay attention to make sure a route generated from the new version can be served by the old one and vice versa.
-As you can see in [an example later on this page](#some-links-to-issues-and-mrs-were-broken), not doing it can lead to an outage.
+As you can see in [this page](#some-links-to-issues-and-mrs-were-broken), not doing it can lead to an outage.
 This type of change may look like an immediate switch between the two implementations. However,
 especially with the canary stage, there is an extended period of time where both version of the code
 coexists in production.