Add latest changes from gitlab-org/gitlab@master

10 files changed, 15 insertions, 15 deletions

diff --git a/doc/administration/auth/how_to_configure_ldap_gitlab_ce/index.md b/doc/administration/auth/how_to_configure_ldap_gitlab_ce/index.md
index 743893d984a..800bb28c664 100644
--- a/doc/administration/auth/how_to_configure_ldap_gitlab_ce/index.md
+++ b/doc/administration/auth/how_to_configure_ldap_gitlab_ce/index.md
@@ -23,7 +23,7 @@ For example, [Active Directory](https://docs.microsoft.com/en-us/previous-versio
 - [Oracle Internet Directory](https://www.oracle.com/middleware/technologies/internet-directory.html)
 - [OpenLDAP](http://www.openldap.org/)
 - [389 Directory](http://directory.fedoraproject.org/)
-- [OpenDJ (Renamed to Foregerock Directory Services)](https://www.forgerock.com/platform/directory-services)
+- [OpenDJ (Renamed to Forgerock Directory Services)](https://www.forgerock.com/platform/directory-services)
 - [ApacheDS](https://directory.apache.org/)
 
 > GitLab uses the [Net::LDAP](https://rubygems.org/gems/net-ldap) library under the hood. This means it supports all [IETF](https://tools.ietf.org/html/rfc2251) compliant LDAPv3 servers.
diff --git a/doc/administration/gitaly/index.md b/doc/administration/gitaly/index.md
index f762c0417f4..17e2b66ce40 100644
--- a/doc/administration/gitaly/index.md
+++ b/doc/administration/gitaly/index.md
@@ -45,7 +45,7 @@ requiring a shared NFS mount for Git repository data.
 Between 11.4 and 11.8 the exception was the
 [Elasticsearch indexer](https://gitlab.com/gitlab-org/gitlab-elasticsearch-indexer).
 But since 11.8 the indexer uses Gitaly for data access as well. NFS can still
-be leveraged for redudancy on block level of the Git data. But only has to
+be leveraged for redundancy on block level of the Git data. But only has to
 be mounted on the Gitaly server.
 
 From GitLab v11.8 to v12.2, it is possible to use Elasticsearch in conjunction with
@@ -618,7 +618,7 @@ This will limit the number of in-flight RPC calls for the given RPC's.
 The limit is applied per repository. In the example above, each on the
 Gitaly server can have at most 20 simultaneous PostUploadPack calls in
 flight, and the same for SSHUploadPack. If another request comes in for
-a repository that hase used up its 20 slots, that request will get
+a repository that has used up its 20 slots, that request will get
 queued.
 
 You can observe the behavior of this queue via the Gitaly logs and via
@@ -762,7 +762,7 @@ Git implementation itself.
 
 Because Rugged+Unicorn was so efficient, GitLab's application code ended
 up with lots of duplicate Git object lookups (like looking up the
-`master` commmit a dozen times in one request). We could write
+`master` commit a dozen times in one request). We could write
 inefficient code without being punished for it.
 
 When we migrated these Git lookups to Gitaly calls, we were suddenly
@@ -927,7 +927,7 @@ Confirm the following are all true:
   ```
 
 - When any user adds or modifies a file from the repository using the GitLab
-  UI, it immediatley fails with a red `401 Unauthorized` banner.
+  UI, it immediately fails with a red `401 Unauthorized` banner.
 - Creating a new project and [initializing it with a README](../../gitlab-basics/create-project.md#blank-projects)
   successfully creates the project but doesn't create the README.
 - When [tailing the logs](https://docs.gitlab.com/omnibus/settings/logs.html#tail-logs-in-a-console-on-the-server) on an app node and reproducing the error, you get `401` errors
diff --git a/doc/administration/gitaly/praefect.md b/doc/administration/gitaly/praefect.md
index 6193a40ac4f..597be6cc97e 100644
--- a/doc/administration/gitaly/praefect.md
+++ b/doc/administration/gitaly/praefect.md
@@ -31,7 +31,7 @@ graph TB
 ```
 
 Where `GitLab` is the collection of clients that can request Git operations.
-The Praefect node has threestorage nodes attached. Praefect itself doesn't
+The Praefect node has three storage nodes attached. Praefect itself doesn't
 store data, but connects to three Gitaly nodes, `Gitaly-1`,  `Gitaly-2`, and `Gitaly-3`.
 
 Praefect may be enabled on its own node or can be run on the GitLab server.
diff --git a/doc/administration/high_availability/consul.md b/doc/administration/high_availability/consul.md
index 392b9b76c31..790296e8db9 100644
--- a/doc/administration/high_availability/consul.md
+++ b/doc/administration/high_availability/consul.md
@@ -100,7 +100,7 @@ If it is necessary to restart the server cluster, it is important to do this in
 
 To be safe, we recommend you only restart one server agent at a time to ensure the cluster remains intact.
 
-For larger clusters, it is possible to restart multiple agents at a time. See the [Consul consensus document](https://www.consul.io/docs/internals/consensus.html#deployment-table) for how many failures it can tolerate. This will be the number of simulateneous restarts it can sustain.
+For larger clusters, it is possible to restart multiple agents at a time. See the [Consul consensus document](https://www.consul.io/docs/internals/consensus.html#deployment-table) for how many failures it can tolerate. This will be the number of simultaneous restarts it can sustain.
 
 ## Upgrades for bundled Consul
 
diff --git a/doc/administration/job_logs.md b/doc/administration/job_logs.md
index 6042786d101..fc37fbb170d 100644
--- a/doc/administration/job_logs.md
+++ b/doc/administration/job_logs.md
@@ -81,7 +81,7 @@ with one change: _the stored path of the first two phases is different_. This in
 log architecture stores chunks of logs in Redis and a persistent store (object storage or database) instead of
 file storage. Redis is used as first-class storage, and it stores up-to 128KB
 of data. Once the full chunk is sent, it is flushed to a persistent store, either object storage (temporary directory) or database.
-After a while, the data in Redis and a persitent store will be archived to [object storage](#uploading-logs-to-object-storage).
+After a while, the data in Redis and a persistent store will be archived to [object storage](#uploading-logs-to-object-storage).
 
 The data are stored in the following Redis namespace: `Gitlab::Redis::SharedState`.
 
diff --git a/doc/administration/lfs/lfs_administration.md b/doc/administration/lfs/lfs_administration.md
index f3b8029f487..fbf48619854 100644
--- a/doc/administration/lfs/lfs_administration.md
+++ b/doc/administration/lfs/lfs_administration.md
@@ -238,8 +238,8 @@ and [projects APIs](../../api/projects.md).
 
 ## Troubleshooting: `Google::Apis::TransmissionError: execution expired`
 
-If LFS integration is configred with Google Cloud Storage and background uploads (`background_upload: true` and `direct_upload: false`),
-Sidekiq workers may encouter this error. This is because the uploading timed out with very large files.
+If LFS integration is configured with Google Cloud Storage and background uploads (`background_upload: true` and `direct_upload: false`),
+Sidekiq workers may encounter this error. This is because the uploading timed out with very large files.
 LFS files up to 6Gb can be uploaded without any extra steps, otherwise you need to use the following workaround.
 
 ```shell
diff --git a/doc/administration/monitoring/prometheus/gitlab_metrics.md b/doc/administration/monitoring/prometheus/gitlab_metrics.md
index 1b542d95d21..b0f1a5736b5 100644
--- a/doc/administration/monitoring/prometheus/gitlab_metrics.md
+++ b/doc/administration/monitoring/prometheus/gitlab_metrics.md
@@ -26,7 +26,7 @@ The following metrics are available:
 | Metric                                                         | Type      |                  Since | Description                                                                                         | Labels                                              |
 |:---------------------------------------------------------------|:----------|-----------------------:|:----------------------------------------------------------------------------------------------------|:----------------------------------------------------|
 | `gitlab_banzai_cached_render_real_duration_seconds`            | Histogram |                    9.4 | Duration of rendering Markdown into HTML when cached output exists                                  | controller, action                                  |
-| `gitlab_banzai_cacheless_render_real_duration_seconds`         | Histogram |                    9.4 | Duration of rendering Markdown into HTML when cached outupt does not exist                          | controller, action                                  |
+| `gitlab_banzai_cacheless_render_real_duration_seconds`         | Histogram |                    9.4 | Duration of rendering Markdown into HTML when cached output does not exist                          | controller, action                                  |
 | `gitlab_cache_misses_total`                                    | Counter   |                   10.2 | Cache read miss                                                                                     | controller, action                                  |
 | `gitlab_cache_operation_duration_seconds`                      | Histogram |                   10.2 | Cache access time                                                                                   |                                                     |
 | `gitlab_cache_operations_total`                                | Counter   |                   12.2 | Cache operations by controller/action                                                               | controller, action, operation                       |
@@ -59,7 +59,7 @@ The following metrics are available:
 | `gitlab_transaction_event_push_commit_total`                   | Counter   |                    9.4 | Counter for commits                                                                                 | branch                                              |
 | `gitlab_transaction_event_push_tag_total`                      | Counter   |                    9.4 | Counter for tag pushes                                                                              |                                                     |
 | `gitlab_transaction_event_rails_exception_total`               | Counter   |                    9.4 | Counter for number of rails exceptions                                                              |                                                     |
-| `gitlab_transaction_event_receive_email_total`                 | Counter   |                    9.4 | Counter for recieved emails                                                                         | handler                                             |
+| `gitlab_transaction_event_receive_email_total`                 | Counter   |                    9.4 | Counter for received emails                                                                         | handler                                             |
 | `gitlab_transaction_event_remote_mirrors_failed_total`         | Counter   |                   10.8 | Counter for failed remote mirrors                                                                   |                                                     |
 | `gitlab_transaction_event_remote_mirrors_finished_total`       | Counter   |                   10.8 | Counter for finished remote mirrors                                                                 |                                                     |
 | `gitlab_transaction_event_remote_mirrors_running_total`        | Counter   |                   10.8 | Counter for running remote mirrors                                                                  |                                                     |
diff --git a/doc/administration/troubleshooting/elasticsearch.md b/doc/administration/troubleshooting/elasticsearch.md
index 560c6b2f53a..a582e07b141 100644
--- a/doc/administration/troubleshooting/elasticsearch.md
+++ b/doc/administration/troubleshooting/elasticsearch.md
@@ -325,7 +325,7 @@ feel free to update that page with issues you encounter and solutions.
 
 ## Replication
 
-Setting up Elasticsearch isn't too bad, but it can be a bit finnicky and time consuming.
+Setting up Elasticsearch isn't too bad, but it can be a bit finicky and time consuming.
 
 The easiest method is to spin up a docker container with the required version and
 bind ports 9200/9300 so it can be used.
diff --git a/doc/administration/troubleshooting/postgresql.md b/doc/administration/troubleshooting/postgresql.md
index 65c6952bf1c..ab302c919b2 100644
--- a/doc/administration/troubleshooting/postgresql.md
+++ b/doc/administration/troubleshooting/postgresql.md
@@ -41,7 +41,7 @@ This section is for links to information elsewhere in the GitLab documentation.
 
 - [Using Slony to update PostgreSQL](../../update/upgrading_postgresql_using_slony.md)
   - Uses replication to handle PostgreSQL upgrades - providing the schemas are the same.
-  - Reduces downtime to a short window for swinging over to the newer vewrsion.
+  - Reduces downtime to a short window for swinging over to the newer version.
 
 - Managing Omnibus PostgreSQL versions [from the development docs](https://docs.gitlab.com/omnibus/development/managing-postgresql-versions.html)
 
diff --git a/doc/administration/troubleshooting/sidekiq.md b/doc/administration/troubleshooting/sidekiq.md
index 41657368ea4..91361dddf02 100644
--- a/doc/administration/troubleshooting/sidekiq.md
+++ b/doc/administration/troubleshooting/sidekiq.md
@@ -174,7 +174,7 @@ the query details.
 ## Managing Sidekiq queues
 
 It is possible to use [Sidekiq API](https://github.com/mperham/sidekiq/wiki/API)
-to perform a number of troubleshoting on Sidekiq.
+to perform a number of troubleshooting on Sidekiq.
 
 These are the administrative commands and it should only be used if currently
 admin interface is not suitable due to scale of installation.