15 files changed, 44 insertions, 24 deletions

diff --git a/doc/integration/elasticsearch.md b/doc/integration/elasticsearch.md
index 62b3de72a3a..44f32343151 100644
--- a/doc/integration/elasticsearch.md
+++ b/doc/integration/elasticsearch.md
@@ -17,9 +17,10 @@ special searches:
 
 | GitLab version | Elasticsearch version |
 | -------------- | --------------------- |
-| GitLab Enterprise Edition 8.4 - 8.17  | Elasticsearch 2.4 with [Delete By Query Plugin](https://www.elastic.co/guide/en/elasticsearch/plugins/2.4/plugins-delete-by-query.html) installed |
+| GitLab Enterprise Edition 8.4 - 8.17   | Elasticsearch 2.4 with [Delete By Query Plugin](https://www.elastic.co/guide/en/elasticsearch/plugins/2.4/plugins-delete-by-query.html) installed |
 | GitLab Enterprise Edition 9.0 - 11.4   | Elasticsearch 5.1 - 5.5 |
-| GitLab Enterprise Edition 11.5+        | Elasticsearch 5.6 - 6.x |
+| GitLab Enterprise Edition 11.5 - 12.6  | Elasticsearch 5.6 - 6.x |
+| GitLab Enterprise Edition 12.7+        | Elasticsearch 6.x - 7.x |
 
 ## Installing Elasticsearch
 
@@ -36,18 +37,20 @@ it yourself or by using the
 service. Running Elasticsearch on the same server as GitLab is not recommended
 and it will likely cause performance degradation on the GitLab installation.
 
+NOTE: **Note:**
+**For a single node Elasticsearch cluster the functional cluster health status will be yellow** (will never be green) because the primary shard is allocated but replicas can not be as there is no other node to which Elasticsearch can assign a replica.
+
 Once the data is added to the database or repository and [Elasticsearch is
-enabled in the admin area](#enabling-elasticsearch) the search index will be
+enabled in the Admin Area](#enabling-elasticsearch) the search index will be
 updated automatically.
 
-## Elasticsearch repository indexer (beta)
+## Elasticsearch repository indexer
 
-In order to improve Elasticsearch indexing performance, GitLab has made available a [new indexer written in Go](https://gitlab.com/gitlab-org/gitlab-elasticsearch-indexer).
-This will replace the included Ruby indexer in the future but should be considered beta software for now, so there may be some bugs.
+For indexing Git repository data, GitLab uses an [indexer written in Go](https://gitlab.com/gitlab-org/gitlab-elasticsearch-indexer).
 
-The Elasticsearch Go indexer is included in Omnibus for GitLab 11.8 and newer.
-
-To use the new Elasticsearch indexer included in Omnibus, check the box "Use the new repository indexer (beta)"  when [enabling the Elasticsearch integration](#enabling-elasticsearch).
+The Go indexer was included in Omnibus GitLab 11.8 as an optional replacement to a
+Ruby-based indexer. [Since GitLab v12.3](https://gitlab.com/gitlab-org/gitlab/issues/6481),
+all indexing is done by the Go indexer, and the Ruby indexer is removed.
 
 If you would like to use the Elasticsearch Go indexer with a source installation or an older version of GitLab, please follow the instructions below.
 
@@ -139,7 +142,6 @@ The following Elasticsearch settings are available:
 | Parameter                                             | Description |
 | ----------------------------------------------------- | ----------- |
 | `Elasticsearch indexing`                              | Enables/disables Elasticsearch indexing. You may want to enable indexing but disable search in order to give the index time to be fully completed, for example. Also, keep in mind that this option doesn't have any impact on existing data, this only enables/disables background indexer which tracks data changes. So by enabling this you will not get your existing data indexed, use special rake task for that as explained in [Adding GitLab's data to the Elasticsearch index](#adding-gitlabs-data-to-the-elasticsearch-index). |
-| `Use the new repository indexer (beta)`               | Perform repository indexing using [GitLab Elasticsearch Indexer](https://gitlab.com/gitlab-org/gitlab-elasticsearch-indexer). |
 | `Search with Elasticsearch enabled`                   | Enables/disables using Elasticsearch in search. |
 | `URL`                                                 | The URL to use for connecting to Elasticsearch. Use a comma-separated list to support clustering (e.g., `http://host1, https://host2:9200`). If your Elasticsearch instance is password protected, pass the `username:password` in the URL (e.g., `http://<username>:<password>@<elastic_host>:9200/`). |
 | `Number of Elasticsearch shards`                      | Elasticsearch indexes are split into multiple shards for performance reasons. In general, larger indexes need to have more shards. Changes to this value do not take effect until the index is recreated. You can read more about tradeoffs in the [Elasticsearch documentation](https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-create-index.html#create-index-settings) |
@@ -200,10 +202,9 @@ To backfill existing data, you can use one of the methods below to index it in b
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/merge_requests/15390) in [GitLab Starter](https://about.gitlab.com/pricing/) 12.3.
 
-To index via the admin area:
+To index via the Admin Area:
 
-1. Navigate to the **Admin Area** (wrench icon), then **Settings > Integrations** and expand the **Elasticsearch** section.
-1. [Enable **Elasticsearch indexing** and configure your host and port](#enabling-elasticsearch).
+1. [Configure your Elasticsearch host and port](#enabling-elasticsearch).
 1. Create empty indexes using one of the following commands:
 
    ```sh
@@ -214,7 +215,8 @@ To index via the admin area:
    bundle exec rake gitlab:elastic:create_empty_index RAILS_ENV=production
    ```
 
-1. Click **Index all projects**.
+1. [Enable **Elasticsearch indexing**](#enabling-elasticsearch).
+1. Click **Index all projects** in **Admin Area > Settings > Integrations > Elasticsearch**.
 1. Click **Check progress** in the confirmation message to see the status of the background jobs.
 1. Personal snippets need to be indexed manually by running one of these commands:
 
@@ -257,7 +259,7 @@ Performing asynchronous indexing will generate a lot of Sidekiq jobs.
 Make sure to prepare for this task by either [Horizontally Scaling](../administration/high_availability/README.md#basic-scaling)
 or creating [extra Sidekiq processes](../administration/operations/extra_sidekiq_processes.md)
 
-1. [Enable **Elasticsearch indexing** and configure your host and port](#enabling-elasticsearch).
+1. [Configure your Elasticsearch host and port](#enabling-elasticsearch).
 1. Create empty indexes using one of the following commands:
 
    ```sh
@@ -268,6 +270,7 @@ or creating [extra Sidekiq processes](../administration/operations/extra_sidekiq
    bundle exec rake gitlab:elastic:create_empty_index RAILS_ENV=production
    ```
 
+1. [Enable **Elasticsearch indexing**](#enabling-elasticsearch).
 1. Indexing large Git repositories can take a while. To speed up the process, you
    can temporarily disable auto-refreshing and replicating. In our experience, you can expect a 20%
    decrease in indexing time. We'll enable them when indexing is done. This step is optional!
@@ -592,6 +595,23 @@ Here are some common pitfalls and how to overcome them:
   AWS has [fixed limits](https://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/aes-limits.html)
   for this setting ("Maximum Size of HTTP Request Payloads"), based on the size of
   the underlying instance.
+  
+- **My single node Elasticsearch cluster status never goes from `yellow` to `green` even though everything seems to be running properly**
+
+  **For a single node Elasticsearch cluster the functional cluster health status will be yellow** (will never be green) because the primary shard is allocated but replicas can not be as there is no other node to which Elasticsearch can assign a replica. This also applies if you are using using the
+[Amazon Elasticsearch](https://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/aes-handling-errors.html#aes-handling-errors-yellow-cluster-status) service.
+
+  CAUTION: **Warning**: Setting the number of replicas to `0` is not something that we recommend (this is not allowed in the GitLab Elasticsearch Integration menu). If you are planning to add more Elasticsearch nodes (for a total of more than 1 Elasticsearch) the number of replicas will need to be set to an integer value larger than `0`. Failure to do so will result in lack of redundancy (losing one node will corrupt the index).
+
+  If you have a **hard requirement to have a green status for your single node Elasticsearch cluster**, please make sure you understand the risks outlined in the previous paragraph and then simply run the following query to set the number of replicas to `0`(the cluster will no longer try to create any shard replicas):
+
+  ```bash
+  curl --request PUT localhost:9200/gitlab-production/_settings --header 'Content-Type: application/json' --data '{
+  "index" : {
+     "number_of_replicas" : 0
+    }
+  }'
+  ```
 
 ### Reverting to basic search
 
diff --git a/doc/integration/img/authorize_vault_with_gitlab_v12_6.png b/doc/integration/img/authorize_vault_with_gitlab_v12_6.png
index dc5bc954cd7..2c9810bc9e8 100644
--- a/doc/integration/img/authorize_vault_with_gitlab_v12_6.png
+++ b/doc/integration/img/authorize_vault_with_gitlab_v12_6.png
diff --git a/doc/integration/img/gitlab_oauth_vault_v12_6.png b/doc/integration/img/gitlab_oauth_vault_v12_6.png
index f952abc2c6d..08fc56c8ec9 100644
--- a/doc/integration/img/gitlab_oauth_vault_v12_6.png
+++ b/doc/integration/img/gitlab_oauth_vault_v12_6.png
diff --git a/doc/integration/img/sign_into_vault_with_gitlab_v12_6.png b/doc/integration/img/sign_into_vault_with_gitlab_v12_6.png
index 8afa2c6aabd..474473e334d 100644
--- a/doc/integration/img/sign_into_vault_with_gitlab_v12_6.png
+++ b/doc/integration/img/sign_into_vault_with_gitlab_v12_6.png
diff --git a/doc/integration/img/signed_into_vault_via_oidc_v12_6.png b/doc/integration/img/signed_into_vault_via_oidc_v12_6.png
index 0ad81ef40e6..0a7f86ff5f0 100644
--- a/doc/integration/img/signed_into_vault_via_oidc_v12_6.png
+++ b/doc/integration/img/signed_into_vault_via_oidc_v12_6.png
diff --git a/doc/integration/img/sourcegraph_admin_v12_5.png b/doc/integration/img/sourcegraph_admin_v12_5.png
index 23e38f56619..54511541c87 100644
--- a/doc/integration/img/sourcegraph_admin_v12_5.png
+++ b/doc/integration/img/sourcegraph_admin_v12_5.png
diff --git a/doc/integration/img/sourcegraph_demo_v12_5.png b/doc/integration/img/sourcegraph_demo_v12_5.png
index c70448c0a8a..35a2e2a89e3 100644
--- a/doc/integration/img/sourcegraph_demo_v12_5.png
+++ b/doc/integration/img/sourcegraph_demo_v12_5.png
diff --git a/doc/integration/img/sourcegraph_popover_v12_5.png b/doc/integration/img/sourcegraph_popover_v12_5.png
index 878d6143646..62fa48129b2 100644
--- a/doc/integration/img/sourcegraph_popover_v12_5.png
+++ b/doc/integration/img/sourcegraph_popover_v12_5.png
diff --git a/doc/integration/img/sourcegraph_user_preferences_v12_5.png b/doc/integration/img/sourcegraph_user_preferences_v12_5.png
index 2c0e138e296..7b7f8945431 100644
--- a/doc/integration/img/sourcegraph_user_preferences_v12_5.png
+++ b/doc/integration/img/sourcegraph_user_preferences_v12_5.png
diff --git a/doc/integration/jira_development_panel.md b/doc/integration/jira_development_panel.md
index a3a66cf6cf2..02cfdc32abb 100644
--- a/doc/integration/jira_development_panel.md
+++ b/doc/integration/jira_development_panel.md
@@ -100,7 +100,7 @@ There are no special requirements if you are using GitLab.com.
    every 60 minutes.
 
    > **Note:**
-   > In the future, we plan on implementating real-time integration. If you need
+   > In the future, we plan on implementing real-time integration. If you need
    > to refresh the data manually, you can do this from the `Applications -> DVCS
    > accounts` screen where you initially set up the integration:
    >
diff --git a/doc/integration/kerberos.md b/doc/integration/kerberos.md
index 2a3e2e43d72..1cdbdb1c40e 100644
--- a/doc/integration/kerberos.md
+++ b/doc/integration/kerberos.md
@@ -265,7 +265,7 @@ so the client will fall back to attempting to negotiate `IAKERB`, leading to the
 above error message.
 
 To fix this, ensure that the forward and reverse DNS for your GitLab server
-match. So for instance, if you acces GitLab as `gitlab.example.com`, resolving
+match. So for instance, if you access GitLab as `gitlab.example.com`, resolving
 to IP address `1.2.3.4`, then `4.3.2.1.in-addr.arpa` must be a PTR record for
 `gitlab.example.com`.
 
diff --git a/doc/integration/oauth_provider.md b/doc/integration/oauth_provider.md
index 36b4836e6b3..6c9b272f35b 100644
--- a/doc/integration/oauth_provider.md
+++ b/doc/integration/oauth_provider.md
@@ -26,7 +26,7 @@ The 'GitLab Importer' feature is also using the OAuth protocol to give access
 to repositories without sharing user credentials to your GitLab.com account.
 
 GitLab supports two ways of adding a new OAuth2 application to an instance. You
-can either add an application as a regular user or add it in the admin area.
+can either add an application as a regular user or add it in the Admin Area.
 What this means is that GitLab can actually have instance-wide and a user-wide
 applications. There is no difference between them except for the different
 permission levels they are set (user/admin). The default callback URL is
@@ -51,14 +51,14 @@ connects to GitLab.
 
 ![OAuth application ID and secret](img/oauth_provider_application_id_secret.png)
 
-## OAuth applications in the admin area
+## OAuth applications in the Admin Area
 
 To create an application that does not belong to a certain user, you can create
-it from the admin area.
+it from the Admin Area.
 
 ![OAuth admin_applications](img/oauth_provider_admin_application.png)
 
-You're also able to mark an application as _trusted_ when creating it through the admin area. By doing that,
+You're also able to mark an application as _trusted_ when creating it through the Admin Area. By doing that,
 the user authorization step is automatically skipped for this application.
 
 ## Authorized applications
diff --git a/doc/integration/saml.md b/doc/integration/saml.md
index a667c2e84c9..11e768194bc 100644
--- a/doc/integration/saml.md
+++ b/doc/integration/saml.md
@@ -155,7 +155,7 @@ Identity Provider.
 ### Requirements
 
 First you need to tell GitLab where to look for group information. For this you
-need to make sure that your IdP server sends a specific `AttributeStament` along
+need to make sure that your IdP server sends a specific `AttributeStatement` along
 with the regular SAML response. Here is an example:
 
 ```xml
diff --git a/doc/integration/sourcegraph.md b/doc/integration/sourcegraph.md
index 358657ca172..25d1ef457c0 100644
--- a/doc/integration/sourcegraph.md
+++ b/doc/integration/sourcegraph.md
@@ -100,7 +100,7 @@ When visiting one of these views, you can now hover over a code reference to see
 
 - Details on how this reference was defined.
 - **Go to definition**, which navigates to the line of code where this reference was defined.
-- **Find references**, which navigates to the configured Sourcegraph instance, showing a list of references to the hilighted code.
+- **Find references**, which navigates to the configured Sourcegraph instance, showing a list of references to the highlighted code.
 
 ![Sourcegraph demo](img/sourcegraph_popover_v12_5.png)
 
diff --git a/doc/integration/vault.md b/doc/integration/vault.md
index 68803fed35d..8bd0897548a 100644
--- a/doc/integration/vault.md
+++ b/doc/integration/vault.md
@@ -7,7 +7,7 @@ type: reference, howto
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/22323) in GitLab 9.0
 
 [Vault](https://www.vaultproject.io/) is a secrets management application offered by HashiCorp.
-It allows you to store and manage sensitive information such secret environment variables, encryption keys, and authentication tokens.
+It allows you to store and manage sensitive information such as secret environment variables, encryption keys, and authentication tokens.
 Vault offers Identity-based Access, which means Vault users can authenticate through several of their preferred cloud providers.
 
 In this document, we'll explain how Vault users can authenticate themselves through GitLab by utilizing our OpenID authentication feature.