Minor style/punctuation changes to Elasticsearch docs

- Many missing commas
- Some wording improvements

doc/development/elasticsearch.md

@@ -289,7 +289,7 @@ Follow these best practices for best results:
 ## Deleting Advanced Search migrations in a major version upgrade
 
 Since our Advanced Search migrations usually require us to support multiple
-code paths for a long period of time it's important to clean those up when we
+code paths for a long period of time, it's important to clean those up when we
 safely can.
 
 We choose to use GitLab major version upgrades as a safe time to remove
@@ -298,30 +298,30 @@ backwards compatibility for indices that have not been fully migrated. We
 documentation](../update/index.md#upgrading-to-a-new-major-version). We also
 choose to remove the migration code and tests so that:
 
-1. We don't need to maintain any code that is called from our Advanced Search
-   migrations
-1. We don't waste CI time running tests for migrations that we don't support
-   anymore
+- We don't need to maintain any code that is called from our Advanced Search
+  migrations.
+- We don't waste CI time running tests for migrations that we don't support
+  anymore.
 
-To be extra safe we will not delete migrations that were created in the last
-minor version before the major upgrade. So if the we are upgrading to `%14.0`
+To be extra safe, we will not delete migrations that were created in the last
+minor version before the major upgrade. So, if the we are upgrading to `%14.0`,
 we should not delete migrations that were only added in `%13.11`. This is an
 extra safety net as we expect there are migrations that get merged that may
 take multiple weeks to finish on GitLab.com. It would be bad if we upgraded
 GitLab.com to `%14.0` before the migrations in `%13.11` were finished. Since
 our deployments to GitLab.com are automated and we currently don't have
-automated checks to prevent this the extra precaution is warranted.
+automated checks to prevent this, the extra precaution is warranted.
 Additionally, even if we did have automated checks to prevent it, we wouldn't
-actually want to hold up GitLab.com deployments on Advanced Search migrations
-as they may still have another week to go and that's too long to block
+actually want to hold up GitLab.com deployments on Advanced Search migrations,
+as they may still have another week to go, and that's too long to block
 deployments.
 
 ### Process for removing migrations
 
 For every migration that was created 2 minor versions before the major version
-being upgraded to we do the following:
+being upgraded to, we do the following:
 
-1. Confirm the migration has actually completed successfully for GitLab.com
+1. Confirm the migration has actually completed successfully for GitLab.com.
 1. Replace the content of `migrate` and `completed?` methods as follows:
 
    ```ruby
@@ -336,10 +336,10 @@ being upgraded to we do the following:
    end
    ```
 
-1. Delete any spec files to support this migration
+1. Delete any spec files to support this migration.
 1. Remove any logic handling backwards compatibility for this migration. You
    can find this by looking for
-   `Elastic::DataMigrationService.migration_has_finished?(:migration_name_in_lowercase)`
+   `Elastic::DataMigrationService.migration_has_finished?(:migration_name_in_lowercase)`.
 1. Create a merge request with these changes. Noting that we should not
    accidentally merge this before the major release is started.
 

doc/integration/elasticsearch.md

@@ -402,7 +402,7 @@ debug why the migration was halted and make any changes before retrying the migr
 fixed the cause of the failure, click "Retry migration", and the migration will be scheduled to be retried
 in the background.
 
-If there appears to be no way you can get the migration to succeed you may
+If you cannot get the migration to succeed, you may
 consider the [last resort to recreate the index from
 scratch](#last-resort-to-recreate-an-index). This may allow you to skip over
 the problem because a newly created index will skip all migrations as the index
@@ -410,9 +410,9 @@ will be recreated with the correct up-to-date schema.
 
 ### All migrations must be finished before doing a major upgrade
 
-Before doing a major version upgrade of GitLab you should have completed all
+Before doing a major version GitLab upgrade, you should have completed all
 migrations that exist up until the latest minor version before that major
-version. If you have halted migrations these will need to be resolved and
+version. If you have halted migrations, these will need to be resolved and
 [retried](#retry-a-halted-migration) before proceeding with a major version
 upgrade. Read more about [upgrading to a new major
 version](../update/index.md#upgrading-to-a-new-major-version).
@@ -903,31 +903,31 @@ In GitLab 13.9, a change was made where [binary file names are being indexed](ht
 ### Last resort to recreate an index
 
 There may be cases where somehow data never got indexed and it's not in the
-queue or the index is somehow in a state where migrations just simply cannot
+queue, or the index is somehow in a state where migrations just simply cannot
 proceed. It is always best to try to troubleshoot the root cause of the problem
-using above [troubleshooting](#troubleshooting) steps.
+using the above [troubleshooting](#troubleshooting) steps.
 
-If there are no other options then you always have the option of recreating the
-entire index from scratch. If you have a small GitLab installation this can
-sometimes be a quick way to resolve a problem but if you have a large GitLab
-installation then this will likely take a very long time to complete. Until the
-index is fully recreated your index will not be serving correct search results
+If there are no other options, then you always have the option of recreating the
+entire index from scratch. If you have a small GitLab installation, this can
+sometimes be a quick way to resolve a problem, but if you have a large GitLab
+installation, then this will likely take a very long time to complete. Until the
+index is fully recreated, your index will not be serving correct search results,
 so you may want to disable **Search with Elasticsearch** while it is running.
 
-If you are sure you've read the above caveats and want to proceed then you
+If you are sure you've read the above caveats and want to proceed, then you
 should run the following Rake task to recreate the entire index from scratch:
 
 **For Omnibus installations**
 
 ```shell
-# WARNING DO NOT RUN THIS UNTIL YOU READ ABOVE DESCRIPTION
+# WARNING: DO NOT RUN THIS UNTIL YOU READ THE DESCRIPTION ABOVE
 sudo gitlab-rake gitlab:elastic:index
 ```
 
 **For installations from source**
 
 ```shell
-# WARNING DO NOT RUN THIS UNTIL YOU READ ABOVE DESCRIPTION
+# WARNING: DO NOT RUN THIS UNTIL YOU READ THE DESCRIPTION ABOVE
 cd /home/git/gitlab
 sudo -u git -H bundle exec rake gitlab:elastic:index
 ```

doc/update/index.md

@@ -211,7 +211,7 @@ before upgrading to a new major version. To see the current size of the `backgro
 [Check for background migrations before upgrading](#checking-for-background-migrations-before-upgrading).
 
 If you have enabled the [Elasticsearch
-integration](../integration/elasticsearch.md) then you will also need to ensure
+integration](../integration/elasticsearch.md), then you will also need to ensure
 all Advanced Search migrations are completed in the last minor version within
 your current version. Be sure to [check for pending Advanced Search
 migrations](#checking-for-pending-advanced-search-migrations) before proceeding