Remove future tense from Configure docs

Remove future tense, in favor of present tense, from the Configure documentation.

Remove future tense from Configure docs
Remove future tense, in favor of present tense, from the Configure documentation.
76b58e30 · Amy Qualls · Nick Gaskill · a42447df · 76b58e30 · 76b58e30
Commit 76b58e30 authored Nov 18, 2020 by Amy Qualls Committed by Nick Gaskill Nov 18, 2020
19 changed files
--- a/doc/administration/terraform_state.md
+++ b/doc/administration/terraform_state.md
@@ -68,7 +68,7 @@ The following settings are:
 | Setting | Description | Default |
 |---------|-------------|---------|
 | `enabled` | Enable/disable object storage | `false` |
-| `remote_directory` | The bucket name where Terraform state files will be stored | |
+| `remote_directory` | The bucket name where Terraform state files are stored | |
 | `connection` | Various connection options described below | |
 ### S3-compatible connection settings

--- a/doc/api/group_clusters.md
+++ b/doc/api/group_clusters.md
@@ -164,8 +164,8 @@ Parameters:
 | `name`                                               | string         | yes      | The name of the cluster                                                                             |
 | `domain`                                             | string         | no       | The [base domain](../user/group/clusters/index.md#base-domain) of the cluster                       |
 | `management_project_id`                              | integer        | no       | The ID of the [management project](../user/clusters/management_project.md) for the cluster          |
-| `enabled`                                            | boolean        | no       | Determines if cluster is active or not, defaults to true                                            |
+| `enabled`                                            | boolean        | no       | Determines if cluster is active or not, defaults to `true`                                            |
-| `managed`                                            | boolean        | no       | Determines if GitLab will manage namespaces and service accounts for this cluster, defaults to true |
+| `managed`                                            | boolean        | no       | Determines if GitLab manages namespaces and service accounts for this cluster. Defaults to `true` |
 | `platform_kubernetes_attributes[api_url]`            | string         | yes      | The URL to access the Kubernetes API                                                                |
 | `platform_kubernetes_attributes[token]`              | string         | yes      | The token to authenticate against Kubernetes                                                        |
 | `platform_kubernetes_attributes[ca_cert]`            | string         | no       | TLS certificate. Required if API is using a self-signed TLS certificate.                            |
@@ -237,7 +237,7 @@ Parameters:
 | `domain`                                  | string         | no       | The [base domain](../user/group/clusters/index.md#base-domain) of the cluster              |
 | `management_project_id`                   | integer        | no       | The ID of the [management project](../user/clusters/management_project.md) for the cluster |
 | `enabled`                                 | boolean        | no       | Determines if cluster is active or not                                                     |
-| `managed`                                 | boolean        | no       | Determines if GitLab will manage namespaces and service accounts for this cluster          |
+| `managed`                                 | boolean        | no       | Determines if GitLab manages namespaces and service accounts for this cluster          |
 | `platform_kubernetes_attributes[api_url]` | string         | no       | The URL to access the Kubernetes API                                                       |
 | `platform_kubernetes_attributes[token]`   | string         | no       | The token to authenticate against Kubernetes                                               |
 | `platform_kubernetes_attributes[ca_cert]` | string         | no       | TLS certificate. Required if API is using a self-signed TLS certificate.                   |

--- a/doc/api/instance_clusters.md
+++ b/doc/api/instance_clusters.md
@@ -9,7 +9,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/36001) in GitLab 13.2.
 NOTE: **Note:**
-User will need admin access to use these endpoints.
+Users need admin access to use these endpoints.
 Use these API endpoints with your instance clusters, which enable you to use the same cluster across multiple projects. [More information](../user/instance/clusters/index.md)
@@ -164,7 +164,7 @@ Parameters:
 | `environment_scope`                                  | string  | no       | The associated environment to the cluster. Defaults to `*`                                            |
 | `management_project_id`                              | integer | no       | The ID of the [management project](../user/clusters/management_project.md) for the cluster            |
 | `enabled`                                            | boolean | no       | Determines if cluster is active or not, defaults to `true`                                            |
-| `managed`                                            | boolean | no       | Determines if GitLab will manage namespaces and service accounts for this cluster, defaults to `true` |
+| `managed`                                            | boolean | no       | Determines if GitLab manages namespaces and service accounts for this cluster. Defaults to `true` |
 | `platform_kubernetes_attributes[api_url]`            | string  | yes      | The URL to access the Kubernetes API                                                                  |
 | `platform_kubernetes_attributes[token]`              | string  | yes      | The token to authenticate against Kubernetes                                                          |
 | `platform_kubernetes_attributes[ca_cert]`            | string  | no       | TLS certificate. Required if API is using a self-signed TLS certificate.                              |
@@ -232,7 +232,7 @@ Parameters:
 | `environment_scope`                         | string  | no       | The associated environment to the cluster                                                  |
 | `management_project_id`                     | integer | no       | The ID of the [management project](../user/clusters/management_project.md) for the cluster |
 | `enabled`                                   | boolean | no       | Determines if cluster is active or not                                                     |
-| `managed`                                   | boolean | no       | Determines if GitLab will manage namespaces and service accounts for this cluster          |
+| `managed`                                   | boolean | no       | Determines if GitLab manages namespaces and service accounts for this cluster          |
 | `platform_kubernetes_attributes[api_url]`   | string  | no       | The URL to access the Kubernetes API                                                       |
 | `platform_kubernetes_attributes[token]`     | string  | no       | The token to authenticate against Kubernetes                                               |
 | `platform_kubernetes_attributes[ca_cert]`   | string  | no       | TLS certificate. Required if API is using a self-signed TLS certificate.                   |

--- a/doc/api/project_clusters.md
+++ b/doc/api/project_clusters.md
@@ -190,7 +190,7 @@ Parameters:
 | `domain`                                             | string  | no       | The [base domain](../user/project/clusters/index.md#base-domain) of the cluster                       |
 | `management_project_id`                              | integer | no       | The ID of the [management project](../user/clusters/management_project.md) for the cluster            |
 | `enabled`                                            | boolean | no       | Determines if cluster is active or not, defaults to `true`                                            |
-| `managed`                                            | boolean | no       | Determines if GitLab will manage namespaces and service accounts for this cluster, defaults to `true` |
+| `managed`                                            | boolean | no       | Determines if GitLab manages namespaces and service accounts for this cluster. Defaults to `true` |
 | `platform_kubernetes_attributes[api_url]`            | string  | yes      | The URL to access the Kubernetes API                                                                  |
 | `platform_kubernetes_attributes[token]`              | string  | yes      | The token to authenticate against Kubernetes                                                          |
 | `platform_kubernetes_attributes[ca_cert]`            | string  | no       | TLS certificate. Required if API is using a self-signed TLS certificate.                              |
@@ -287,7 +287,7 @@ Parameters:
 | `domain`                                    | string  | no       | The [base domain](../user/project/clusters/index.md#base-domain) of the cluster            |
 | `management_project_id`                     | integer | no       | The ID of the [management project](../user/clusters/management_project.md) for the cluster |
 | `enabled`                                   | boolean | no       | Determines if cluster is active or not                                                     |
-| `managed`                                   | boolean | no       | Determines if GitLab will manage namespaces and service accounts for this cluster          |
+| `managed`                                   | boolean | no       | Determines if GitLab manages namespaces and service accounts for this cluster          |
 | `platform_kubernetes_attributes[api_url]`   | string  | no       | The URL to access the Kubernetes API                                                       |
 | `platform_kubernetes_attributes[token]`     | string  | no       | The token to authenticate against Kubernetes                                               |
 | `platform_kubernetes_attributes[ca_cert]`   | string  | no       | TLS certificate. Required if API is using a self-signed TLS certificate.                   |

--- a/doc/topics/autodevops/customize.md
+++ b/doc/topics/autodevops/customize.md
--- a/doc/topics/autodevops/index.md
+++ b/doc/topics/autodevops/index.md
@@ -49,7 +49,7 @@ runs on pipelines automatically only if a [`Dockerfile` or matching buildpack](s
 exists.
 If a [CI/CD configuration file](../../ci/yaml/README.md) is present in the project,
-it will continue to be used, whether or not Auto DevOps is enabled.
+it continues to be used, whether or not Auto DevOps is enabled.
 ## Quick start
@@ -146,7 +146,7 @@ any of the following places:
 The base domain variable `KUBE_INGRESS_BASE_DOMAIN` follows the same order of precedence
 as other environment [variables](../../ci/variables/README.md#priority-of-environment-variables).
 If the CI/CD variable is not set and the cluster setting is left blank, the instance-wide **Auto DevOps domain**
-setting will be used if set.
+setting is used if set.
 TIP: **Tip:**
 If you use the [GitLab managed app for Ingress](../../user/clusters/applications.md#ingress),
@@ -236,7 +236,7 @@ Auto DevOps at the group and project level, respectively.
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/38542) in GitLab 11.0.
-You can change the deployment strategy used by Auto DevOps by going to your
+You can change the deployment strategy used by Auto DevOps by visiting your
 project's **Settings > CI/CD > Auto DevOps**. The following options
 are available:
@@ -372,7 +372,7 @@ To fix this issue, you must either:
 ### Failure to create a Kubernetes namespace
-Auto Deploy will fail if GitLab can't create a Kubernetes namespace and
+Auto Deploy fails if GitLab can't create a Kubernetes namespace and
 service account for your project. For help debugging this issue, see
 [Troubleshooting failed deployment jobs](../../user/project/clusters/index.md#troubleshooting).
@@ -476,7 +476,7 @@ that works for this problem. Follow these steps to use the tool in Auto DevOps:
 ### Error: error initializing: Looks like "https://kubernetes-charts.storage.googleapis.com" is not a valid chart repository or cannot be reached
 As [announced in the official CNCF blogpost](https://www.cncf.io/blog/2020/10/07/important-reminder-for-all-helm-users-stable-incubator-repos-are-deprecated-and-all-images-are-changing-location/),
-the stable Helm chart repository will be deprecated and removed on November 13th, 2020.
+the stable Helm chart repository was deprecated and removed on November 13th, 2020.
 You may encounter this error after that date.
 Some GitLab features had dependencies on the stable chart. To mitigate the impact, we changed them
@@ -495,7 +495,7 @@ include:
  image: "registry.gitlab.com/gitlab-org/cluster-integration/auto-deploy-image:v1.0.5"
 ```
-Keep in mind that this approach will eventually stop working when the stable repository is removed,
+Keep in mind that this approach stops working when the stable repository is removed,
 so you must eventually fix your custom chart.
 To fix your custom chart:

--- a/doc/topics/autodevops/quick_start_guide.md
+++ b/doc/topics/autodevops/quick_start_guide.md
@@ -6,15 +6,15 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 # Getting started with Auto DevOps
-This step-by-step guide will help you use [Auto DevOps](index.md) to
+This step-by-step guide helps you use [Auto DevOps](index.md) to
 deploy a project hosted on GitLab.com to Google Kubernetes Engine.
-You will use GitLab's native Kubernetes integration, so you won't need
+You are using GitLab's native Kubernetes integration, so you don't need
 to create a Kubernetes cluster manually using the Google Cloud Platform console.
-You will create and deploy a simple application that you create from a GitLab template.
+You are creating and deploying a simple application that you create from a GitLab template.
-These instructions will also work for a self-managed GitLab instance; you'll just
+These instructions also work for a self-managed GitLab instance;
-need to ensure your own [runners are configured](../../ci/runners/README.md) and
+ensure your own [runners are configured](../../ci/runners/README.md) and
 [Google OAuth is enabled](../../integration/google.md).
 ## Configure your Google account
@@ -38,7 +38,7 @@ and apply for credit.
 ## Create a new project from a template
-We will use one of GitLab's project templates to get started. As the name suggests,
+We are using one of GitLab's project templates to get started. As the name suggests,
 those projects provide a bare-bones application built on some well-known frameworks.
 1. In GitLab, click the plus icon (**{plus-square}**) at the top of the navigation bar, and select
@@ -57,7 +57,7 @@ those projects provide a bare-bones application built on some well-known framewo
 1. Click **Create project**.
-Now that you've created a project, you'll next create the Kubernetes cluster
+Now that you've created a project, create the Kubernetes cluster
 to deploy this project to.
 ## Create a Kubernetes cluster from within GitLab
@@ -98,30 +98,30 @@ to deploy this project to.
 1. Click **Create Kubernetes cluster**.
-After a couple of minutes, the cluster will be created. You can also see its
+After a couple of minutes, the cluster is created. You can also see its
 status on your [GCP dashboard](https://console.cloud.google.com/kubernetes).
-Next, you will install some applications on your cluster that are needed
+Next, install some applications on your cluster that are needed
 to take full advantage of Auto DevOps.
 ## Install Ingress and Prometheus
-After your cluster is running, you can install your first applications.
+After your cluster is running, you can install your first applications,
-In this guide, we will install Ingress and Prometheus:
+Ingress and Prometheus:
 - Ingress - Provides load balancing, SSL termination, and name-based virtual hosting,
  using NGINX behind the scenes.
 - Prometheus - An open-source monitoring and alerting system used to supervise the
  deployed application.
-We won't install GitLab Runner in this quick start guide, as this guide uses the
+We aren't installing GitLab Runner in this quick start guide, as this guide uses the
 shared runners provided by GitLab.com.
 To install the applications:
 - Click the **Install** button for **Ingress**.
 - When the **Ingress Endpoint** is displayed, copy the IP address.
- Add your **Base domain**. For this guide, we will use the domain suggested by GitLab.
+- Add your **Base domain**. For this guide, use the domain suggested by GitLab.
 - Click **Save changes**.
 ![Cluster Base Domain](img/guide_base_domain_v12_3.png)
@@ -251,7 +251,7 @@ a few more that run only on branches other than `master`.
 ![Merge request](img/guide_merge_request_v12_3.png)
-After a few minutes you'll notice a test failed, which means a test was
+After a few minutes a test fails, which means a test was
 'broken' by your change. Click on the failed `test` job to see more information
 about it:

--- a/doc/topics/autodevops/requirements.md
+++ b/doc/topics/autodevops/requirements.md
@@ -46,7 +46,7 @@ To make full use of Auto DevOps with Kubernetes, you need:
  [Auto Deploy](stages.md#auto-deploy), and [Auto Monitoring](stages.md#auto-monitoring))
  You need a domain configured with wildcard DNS, which all of your Auto DevOps
-  applications will use. If you're using the
+  applications use. If you're using the
  [GitLab-managed app for Ingress](../../user/clusters/applications.md#ingress),
  the URL endpoint is automatically configured for you.
@@ -111,7 +111,7 @@ After all requirements are met, you can [enable Auto DevOps](index.md#enablingdi
 You can choose to target [AWS ECS](../../ci/cloud_deployment/index.md) as a deployment platform instead of using Kubernetes.
-To get started on Auto DevOps to AWS ECS, you'll have to add a specific Environment
+To get started on Auto DevOps to AWS ECS, you must add a specific Environment
 Variable. To do so, follow these steps:
 1. In your project, go to **Settings > CI / CD** and expand the **Variables**
@@ -124,19 +124,19 @@ Variable. To do so, follow these steps:
 When you trigger a pipeline, if you have Auto DevOps enabled and if you have correctly
 [entered AWS credentials as environment variables](../../ci/cloud_deployment/index.md#deploy-your-application-to-the-aws-elastic-container-service-ecs),
-your application will be deployed to AWS ECS.
+your application is deployed to AWS ECS.
 [GitLab Managed Apps](../../user/clusters/applications.md) are not available when deploying to AWS ECS.
 You must manually configure your application (such as Ingress or Help) on AWS ECS.
 If you have both a valid `AUTO_DEVOPS_PLATFORM_TARGET` variable and a Kubernetes cluster tied to your project,
-only the deployment to Kubernetes will run.
+only the deployment to Kubernetes runs.
 CAUTION: **Warning:**
-Setting the `AUTO_DEVOPS_PLATFORM_TARGET` variable to `ECS` will trigger jobs
+Setting the `AUTO_DEVOPS_PLATFORM_TARGET` variable to `ECS` triggers jobs
 defined in the [`Jobs/Deploy/ECS.gitlab-ci.yml` template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/Deploy/ECS.gitlab-ci.yml).
 However, it's not recommended to [include](../../ci/yaml/README.md#includetemplate)
 it on its own. This template is designed to be used with Auto DevOps only. It may change
 unexpectedly causing your pipeline to fail if included on its own. Also, the job
 names within this template may also change. Do not override these jobs' names in your
-own pipeline, as the override will stop working when the name changes.
+own pipeline, as the override stops working when the name changes.
--- a/doc/topics/autodevops/stages.md
+++ b/doc/topics/autodevops/stages.md
@@ -64,7 +64,7 @@ value. The default builder is `heroku/buildpacks:18` but a different builder
 can be selected using the CI variable `AUTO_DEVOPS_BUILD_IMAGE_CNB_BUILDER`.
 Cloud Native Buildpacks (CNBs) are an evolution of Heroku buildpacks, and
-will eventually supersede Herokuish-based builds within Auto DevOps. For more
+GitLab expects them to eventually supersede Herokuish-based builds within Auto DevOps. For more
 information, see [this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/212692).
 Builds using Cloud Native Buildpacks support the same options as builds using
@@ -150,7 +150,7 @@ out. The merge request widget also displays any
 Static Application Security Testing (SAST) uses the
 [SAST Docker image](https://gitlab.com/gitlab-org/security-products/sast) to run static
 analysis on the current code, and checks for potential security issues. The
-Auto SAST stage will be skipped on licenses other than
+Auto SAST stage is skipped on licenses other than
 [Ultimate](https://about.gitlab.com/pricing/), and requires
 [GitLab Runner](https://docs.gitlab.com/runner/) 11.5 or above.
@@ -387,16 +387,16 @@ in the first place, and thus not realize that it needs to re-apply the old confi
 [GitLab Deploy Tokens](../../user/project/deploy_tokens/index.md#gitlab-deploy-token)
 are created for internal and private projects when Auto DevOps is enabled, and the
 Auto DevOps settings are saved. You can use a Deploy Token for permanent access to
-the registry. After you manually revoke the GitLab Deploy Token, it won't be
+the registry. After you manually revoke the GitLab Deploy Token, it isn't
 automatically created.
 If the GitLab Deploy Token can't be found, `CI_REGISTRY_PASSWORD` is
 used.
 NOTE: **Note:**
-`CI_REGISTRY_PASSWORD` is only valid during deployment. Kubernetes will be able
+`CI_REGISTRY_PASSWORD` is only valid during deployment. Kubernetes can
-to successfully pull the container image during deployment, but if the image must
+successfully pull the container image during deployment, but if the image must
-be pulled again, such as after pod eviction, Kubernetes will fail to do so
+be pulled again, such as after pod eviction, Kubernetes cannot do so
 as it attempts to fetch the image using `CI_REGISTRY_PASSWORD`.
 ### Kubernetes 1.16+
@@ -455,7 +455,7 @@ initialization completes, GitLab deploys a second release with the application
 deployment as normal.
 Note that a post-install hook means that if any deploy succeeds,
-`DB_INITIALIZE` won't be processed thereafter.
+`DB_INITIALIZE` isn't processed thereafter.
 If present, `DB_MIGRATE` is run as a shell command within an application pod as
 a Helm pre-upgrade hook.
@@ -492,7 +492,7 @@ the standard health checks, which expect a successful HTTP response on port
 the [`sidekiq_alive` gem](https://rubygems.org/gems/sidekiq_alive).
 To work with Sidekiq, you must also ensure your deployments have
-access to a Redis instance. Auto DevOps won't deploy this instance for you, so
+access to a Redis instance. Auto DevOps doesn't deploy this instance for you, so
 you must:
 - Maintain your own Redis instance.

--- a/doc/topics/autodevops/upgrading_postgresql.md
+++ b/doc/topics/autodevops/upgrading_postgresql.md
@@ -79,7 +79,7 @@ being modified after the database dump is created.
    deployment.extensions/production scaled
    ```
-1. You also will need to set replicas to zero for workers if you have any.
+1. You must also set replicas to zero for workers if you have any.
 ## Backup
@@ -112,7 +112,7 @@ being modified after the database dump is created.
   - `USERNAME` is the username you have configured for PostgreSQL. The default is `user`.
   - `DATABASE_NAME` is usually the environment name.
-   - You will be asked for the database password, the default is `testing-password`.
+   - When prompted for the database password, the default is `testing-password`.
    ```shell
    ## Format is:
@@ -169,7 +169,7 @@ pvc-9085e3d3-5239-11ea-9c8d-42010a8e0096   8Gi        RWO            Retain
 ## Install new PostgreSQL
 CAUTION: **Caution:**
-Using the newer version of PostgreSQL will delete
+Using the newer version of PostgreSQL deletes
 the older 0.7.1 PostgreSQL. To prevent the underlying data from being
 deleted, you can choose to retain the [persistent volume](#retain-persistent-volumes).
@@ -196,9 +196,9 @@ higher*. This is the
   `XDB_INITIALIZE` or the `XDB_MIGRATE` to effectively disable them.
 1. Run a new CI pipeline for the branch. In this case, we run a new CI
   pipeline for `master`.
-1. Once the pipeline is successful, your application will now be upgraded
+1. After the pipeline is successful, your application is upgraded
-   with the new PostgreSQL installed. There will also be zero replicas
+   with the new PostgreSQL installed. Zero replicas exist at this time, so
-   which means no traffic will be served for your application (to prevent
+   no traffic is served for your application (to prevent
   new data from coming in).
 ## Restore
@@ -226,7 +226,7 @@ higher*. This is the
 1. Once connected to the pod, run the following command to restore the database.
-   - You will be asked for the database password, the default is `testing-password`.
+   - When asked for the database password, the default is `testing-password`.
   - `USERNAME` is the username you have configured for PostgreSQL. The default is `user`.
   - `DATABASE_NAME` is usually the environment name.

--- a/doc/user/clusters/applications.md
+++ b/doc/user/clusters/applications.md
@@ -78,7 +78,7 @@ in a pod within the `gitlab-managed-apps` namespace inside the cluster.
  to [GitLab 13.2](https://gitlab.com/gitlab-org/gitlab/-/issues/209736), GitLab
  used an in-cluster Tiller server in the `gitlab-managed-apps` namespace. You
  can safely uninstall the server from GitLab's application page if you have
-  previously installed it. This will not affect your other applications.
+  previously installed it. This doesn't affect your other applications.
 GitLab's Helm integration does not support installing applications behind a proxy,
 but a [workaround](../../topics/autodevops/index.md#install-applications-behind-a-proxy)
@@ -233,7 +233,7 @@ rules that allow external access to your deployed applications.
  ```
  If EKS is used, an [Elastic Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/)
-  is also created, which will incur additional AWS costs.
+  is also created, which incurs additional AWS costs.
 - For Istio/Knative, the command is different:
@@ -258,7 +258,7 @@ a wildcard DNS CNAME record for the desired domain name. For example,
 By default, an ephemeral external IP address is associated to the cluster's load
 balancer. If you associate the ephemeral IP with your DNS and the IP changes,
-your apps won't be reachable, and you'd have to change the DNS record again.
+your apps aren't reachable, and you'd have to change the DNS record again.
 To avoid that, change it into a static reserved IP.
 Read how to [promote an ephemeral external IP address in GKE](https://cloud.google.com/compute/docs/ip-addresses/reserve-static-external-ip-address#promote_ephemeral_ip).
@@ -439,7 +439,7 @@ The [`knative/knative`](https://storage.googleapis.com/triggermesh-charts)
 chart is used to install this application.
 During installation, you must enter a wildcard domain where your applications
-will be exposed. Configure your DNS server to use the external IP address for that
+are exposed. Configure your DNS server to use the external IP address for that
 domain. Applications created and installed are accessible as
 `<program_name>.<kubernetes_namespace>.<domain_name>`, which requires
 your Kubernetes cluster to have
@@ -668,8 +668,8 @@ is saved as a [CI job artifact](../../ci/pipelines/job_artifacts.md).
 For GitLab versions 13.5 and below, the Ingress, Fluentd, Prometheus,
 and Sentry apps are fetched from the central Helm [stable
 repository](https://kubernetes-charts.storage.googleapis.com/), which
-will be [deleted](https://github.com/helm/charts#deprecation-timeline)
+is [scheduled for deletion](https://github.com/helm/charts#deprecation-timeline)
-on November 13, 2020. This will cause the installation CI/CD pipeline to
+on November 13, 2020. This causes the installation CI/CD pipeline to
 fail. Upgrade to GitLab 13.6, or alternatively, you can
 use the following `.gitlab-ci.yml`, which has been tested on GitLab
 13.5:

--- a/doc/user/clusters/cost_management.md
+++ b/doc/user/clusters/cost_management.md
@@ -58,7 +58,7 @@ file or creating similar dashboard configuration files. To learn more, read abou
 #### Available metrics
-Metrics contain both instance and node labels. The instance label will be deprecated in a future version.
+Metrics contain both instance and node labels. The instance label is scheduled for deprecation in a future version.
 - `node_cpu_hourly_cost` - Hourly cost per vCPU on this node.
 - `node_gpu_hourly_cost` - Hourly cost per GPU on this node.

--- a/doc/user/clusters/management_project.md
+++ b/doc/user/clusters/management_project.md
@@ -4,7 +4,7 @@ group: Configure
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#designated-technical-writers
 ---
-# Cluster management project (alpha)
+# Cluster management project
 CAUTION: **Warning:**
 This is an _alpha_ feature, and it is subject to change at any time without
@@ -25,8 +25,8 @@ This can be useful for:
 ## Permissions
-Only the management project will receive `cluster-admin` privileges. All
+Only the management project receives `cluster-admin` privileges. All
-other projects will continue to receive [namespace scoped `edit` level privileges](../project/clusters/add_remove_clusters.md#rbac-cluster-resources).
+other projects continue to receive [namespace scoped `edit` level privileges](../project/clusters/add_remove_clusters.md#rbac-cluster-resources).
 Management projects are restricted to the following:
@@ -92,7 +92,7 @@ to a management project:
 | Production  | `production`      |
 The following environments set in
-[`.gitlab-ci.yml`](../../ci/yaml/README.md) will deploy to the
+[`.gitlab-ci.yml`](../../ci/yaml/README.md) deploy to the
 Development, Staging, and Production cluster respectively.
 ```yaml

--- a/doc/user/group/clusters/index.md
+++ b/doc/user/group/clusters/index.md
@@ -58,11 +58,11 @@ differentiate the new cluster from your other clusters.
 > - Became [optional](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/26565) in GitLab 11.11.
 You can choose to allow GitLab to manage your cluster for you. If GitLab manages
-your cluster, resources for your projects will be automatically created. See the
+your cluster, resources for your projects are automatically created. See the
 [Access controls](../../project/clusters/add_remove_clusters.md#access-controls)
 section for details on which resources GitLab creates for you.
-For clusters not managed by GitLab, project-specific resources won't be created
+For clusters not managed by GitLab, project-specific resources aren't created
 automatically. If you're using [Auto DevOps](../../../topics/autodevops/index.md)
 for deployments with a cluster not managed by GitLab, you must ensure:
@@ -97,7 +97,7 @@ To clear the cache:
 Domains at the cluster level permit support for multiple domains
 per [multiple Kubernetes clusters](#multiple-kubernetes-clusters) When specifying a domain,
-this will be automatically set as an environment variable (`KUBE_INGRESS_BASE_DOMAIN`) during
+this is automatically set as an environment variable (`KUBE_INGRESS_BASE_DOMAIN`) during
 the [Auto DevOps](../../../topics/autodevops/index.md) stages.
 The domain should have a wildcard DNS configured to the Ingress IP address.

--- a/doc/user/project/clusters/add_eks_clusters.md
+++ b/doc/user/project/clusters/add_eks_clusters.md
@@ -23,9 +23,9 @@ requirements are met:
 ### Additional requirements for self-managed instances **(CORE ONLY)**
 If you are using a self-managed GitLab instance, GitLab must first be configured with a set of
-Amazon credentials. These credentials will be used to assume an Amazon IAM role provided by the user
+Amazon credentials. These credentials are used to assume an Amazon IAM role provided by the user
 creating the cluster. Create an IAM user and ensure it has permissions to assume the role(s) that
-your users will use to create EKS clusters.
+your users need to create EKS clusters.
 For example, the following policy document allows assuming a role whose name starts with
 `gitlab-eks-` in account `123456789012`:
@@ -60,7 +60,7 @@ To create and add a new Kubernetes cluster to your project, group, or instance:
   - Group's **Kubernetes** page, for a group-level cluster.
   - **Admin Area > Kubernetes**, for an instance-level cluster.
 1. Click **Add Kubernetes cluster**.
-1. Under the **Create new cluster** tab, click **Amazon EKS**. You will be provided with an
+1. Under the **Create new cluster** tab, click **Amazon EKS** to display an
   `Account ID` and `External ID` needed for later steps.
 1. In the [IAM Management Console](https://console.aws.amazon.com/iam/home), create an IAM policy:
   1. From the left panel, select **Policies**.
@@ -137,9 +137,9 @@ To create and add a new Kubernetes cluster to your project, group, or instance:
   1. Click **Next: Tags**, and optionally enter any tags you wish to associate with this role.
   1. Click **Next: Review**.
   1. Enter a role name and optional description into the fields provided.
-   1. Click **Create role**, the new role name will appear at the top. Click on its name and copy the `Role ARN` from the newly created role.
+   1. Click **Create role**, the new role name displays at the top. Click on its name and copy the `Role ARN` from the newly created role.
 1. In GitLab, enter the copied role ARN into the `Role ARN` field.
-1. In the **Cluster Region** field, enter the [region](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html) you plan to use for your new cluster. GitLab will authenticate you have access to this region when authenticating your role.
+1. In the **Cluster Region** field, enter the [region](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html) you plan to use for your new cluster. GitLab confirms you have access to this region when authenticating your role.
 1. Click **Authenticate with AWS**.
 1. Choose your cluster's settings:
   - **Kubernetes cluster name** - The name you wish to give the cluster.
@@ -158,7 +158,7 @@ To create and add a new Kubernetes cluster to your project, group, or instance:
   - **VPC** - Select a [VPC](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html)
     to use for your EKS Cluster resources.
   - **Subnets** - Choose the [subnets](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Subnets.html)
-     in your VPC where your worker nodes will run. You must select at least two.
+     in your VPC where your worker nodes run. You must select at least two.
   - **Security group** - Choose the [security group](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html)
     to apply to the EKS-managed Elastic Network Interfaces that are created in your worker node subnets.
   - **Instance type** - The [instance type](https://aws.amazon.com/ec2/instance-types/) of your worker nodes.
@@ -167,11 +167,11 @@ To create and add a new Kubernetes cluster to your project, group, or instance:
     See the [Managed clusters section](index.md#gitlab-managed-clusters) for more information.
 1. Finally, click the **Create Kubernetes cluster** button.
-After about 10 minutes, your cluster will be ready to go. You can now proceed
+After about 10 minutes, your cluster is ready to go. You can now proceed
 to install some [pre-defined applications](index.md#installing-applications).
 NOTE: **Note:**
-You will need to add your AWS external ID to the
+You must add your AWS external ID to the
 [IAM Role in the AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-role.html#cli-configure-role-xaccount)
 to manage your cluster using `kubectl`.
@@ -219,9 +219,9 @@ For information on adding an existing EKS cluster, see
 ### Create a default Storage Class
 Amazon EKS doesn't have a default Storage Class out of the box, which means
-requests for persistent volumes will not be automatically fulfilled. As part
+requests for persistent volumes are not automatically fulfilled. As part
 of Auto DevOps, the deployed PostgreSQL instance requests persistent storage,
-and without a default storage class it will fail to start.
+and without a default storage class it cannot start.
 If a default Storage Class doesn't already exist and is desired, follow Amazon's
 [guide on storage classes](https://docs.aws.amazon.com/eks/latest/userguide/storage-classes.html)
@@ -239,18 +239,17 @@ to build, test, and deploy the app.
 [Enable Auto DevOps](../../../topics/autodevops/index.md#at-the-project-level)
 if not already enabled. If a wildcard DNS entry was created resolving to the
 Load Balancer, enter it in the `domain` field under the Auto DevOps settings.
-Otherwise, the deployed app will not be externally available outside of the cluster.
+Otherwise, the deployed app isn't externally available outside of the cluster.
 ![Deploy Pipeline](img/pipeline.png)
-A new pipeline will automatically be created, which will begin to build, test,
+GitLab creates a new pipeline, which begins to build, test, and deploy the app.
-and deploy the app.
-After the pipeline has finished, your app will be running in EKS and available
+After the pipeline has finished, your app runs in EKS, and is available
 to users. Click on **CI/CD > Environments**.
 ![Deployed Environment](img/environment.png)
-You will see a list of the environments and their deploy status, as well as
+GitLab displays a list of the environments and their deploy status, as well as
 options to browse to the app, view monitoring metrics, and even access a shell
 on the running pod.
--- a/doc/user/project/clusters/add_gke_clusters.md
+++ b/doc/user/project/clusters/add_gke_clusters.md
@@ -33,7 +33,7 @@ Note the following:
  created by GitLab are RBAC-enabled. Take a look at the [RBAC section](add_remove_clusters.md#rbac-cluster-resources) for
  more information.
 - Starting from [GitLab 12.5](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/18341), the
-  cluster's pod address IP range will be set to /16 instead of the regular /14. /16 is a CIDR
+  cluster's pod address IP range is set to `/16` instead of the regular `/14`. `/16` is a CIDR
  notation.
 - GitLab requires basic authentication enabled and a client certificate issued for the cluster to
  set up an [initial service account](add_remove_clusters.md#access-controls). In [GitLab versions
@@ -57,20 +57,20 @@ To create and add a new Kubernetes cluster to your project, group, or instance:
   - **Kubernetes cluster name** - The name you wish to give the cluster.
   - **Environment scope** - The [associated environment](index.md#setting-the-environment-scope) to this cluster.
   - **Google Cloud Platform project** - Choose the project you created in your GCP
-     console that will host the Kubernetes cluster. Learn more about
+     console to host the Kubernetes cluster. Learn more about
     [Google Cloud Platform projects](https://cloud.google.com/resource-manager/docs/creating-managing-projects).
   - **Zone** - Choose the [region zone](https://cloud.google.com/compute/docs/regions-zones/)
-     under which the cluster will be created.
+     under which to create the cluster.
   - **Number of nodes** - Enter the number of nodes you wish the cluster to have.
   - **Machine type** - The [machine type](https://cloud.google.com/compute/docs/machine-types)
-     of the Virtual Machine instance that the cluster will be based on.
+     of the Virtual Machine instance to base the cluster on.
   - **Enable Cloud Run for Anthos** - Check this if you want to use Cloud Run for Anthos for this cluster.
     See the [Cloud Run for Anthos section](#cloud-run-for-anthos) for more information.
   - **GitLab-managed cluster** - Leave this checked if you want GitLab to manage namespaces and service accounts for this cluster.
     See the [Managed clusters section](index.md#gitlab-managed-clusters) for more information.
 1. Finally, click the **Create Kubernetes cluster** button.
-After a couple of minutes, your cluster will be ready to go. You can now proceed
+After a couple of minutes, your cluster is ready. You can now proceed
 to install some [pre-defined applications](index.md#installing-applications).
 ### Cloud Run for Anthos
@@ -79,7 +79,7 @@ to install some [pre-defined applications](index.md#installing-applications).
 You can choose to use Cloud Run for Anthos in place of installing Knative and Istio
 separately after the cluster has been created. This means that Cloud Run
-(Knative), Istio, and HTTP Load Balancing will be enabled on the cluster at
+(Knative), Istio, and HTTP Load Balancing are enabled on the cluster at
 create time and cannot be [installed or uninstalled](../../clusters/applications.md) separately.
 ## Existing GKE cluster

--- a/doc/user/project/clusters/runbooks/index.md
+++ b/doc/user/project/clusters/runbooks/index.md
@@ -37,7 +37,7 @@ for an overview of how this is accomplished in GitLab!
 ## Requirements
-To create an executable runbook, you will need:
+To create an executable runbook, you need:
 - **Kubernetes** - A Kubernetes cluster is required to deploy the rest of the
  applications. The simplest way to get started is to add a cluster using one
@@ -71,7 +71,7 @@ the components outlined above and the pre-loaded demo runbook.
   ![install ingress](img/ingress-install.png)
 1. After Ingress has been installed successfully, click the **Install** button next
-   to the **JupyterHub** application. You will need the **Jupyter Hostname** provided
+   to the **JupyterHub** application. You need the **Jupyter Hostname** provided
   here in the next step.
   ![install JupyterHub](img/jupyterhub-install.png)
@@ -84,8 +84,8 @@ the components outlined above and the pre-loaded demo runbook.
   ![authorize Jupyter](img/authorize-jupyter.png)
-1. Click **Authorize**, and you will be redirected to the JupyterHub application.
+1. Click **Authorize**, and GitLab redirects you to the JupyterHub application.
-1. Click **Start My Server**, and the server will start in a few seconds.
+1. Click **Start My Server** to start the server in a few seconds.
 1. To configure the runbook's access to your GitLab project, you must enter your
   [GitLab Access Token](../../../profile/personal_access_tokens.md)
   and your Project ID in the **Setup** section of the demo runbook:

--- a/doc/user/project/clusters/serverless/aws.md
+++ b/doc/user/project/clusters/serverless/aws.md
@@ -29,7 +29,7 @@ Alternatively, you can quickly [create a new project with a template](../../../.
 ### Example
-In the following example, you will:
+This example shows you how to:
 1. Create a basic AWS Lambda Node.js function.
 1. Link the function to an API Gateway `GET` endpoint.
@@ -49,7 +49,7 @@ Lets take it step by step.
 #### Creating a Lambda handler function
-Your Lambda function will be the primary handler of requests. In this case we will create a very simple Node.js `hello` function:
+Your Lambda function is the primary handler of requests. In this case, create a very simple Node.js `hello` function:
 ```javascript
 'use strict';
@@ -72,13 +72,13 @@ Place this code in the file `src/handler.js`.
 `src` is the standard location for serverless functions, but is customizable should you desire that.
-In our case, `module.exports.hello` defines the `hello` handler that will be referenced later in the `serverless.yml`
+In our case, `module.exports.hello` defines the `hello` handler to reference later in the `serverless.yml`.
 You can learn more about the AWS Lambda Node.js function handler and all its various options here: <https://docs.aws.amazon.com/lambda/latest/dg/nodejs-prog-model-handler.html>
 #### Creating a `serverless.yml` file
-In the root of your project, create a `serverless.yml` file that will contain configuration specifics for the Serverless Framework.
+In the root of your project, create a `serverless.yml` file containing configuration specifics for the Serverless Framework.
 Put the following code in the file:
@@ -97,9 +97,9 @@ functions:
 Our function contains a handler and a event.
-The handler definition will provision the Lambda function using the source code located `src/handler.hello`.
+The handler definition provisions the Lambda function using the source code located `src/handler.hello`.
-The `events` declaration will create a AWS API Gateway `GET` endpoint to receive external requests and hand them over to the Lambda function via a service integration.
+The `events` declaration creates an AWS API Gateway `GET` endpoint to receive external requests and hand them over to the Lambda function via a service integration.
 You can read more about the [available properties and additional configuration possibilities](https://www.serverless.com/framework/docs/providers/aws/guide/serverless.yml/) of the Serverless Framework.
@@ -141,10 +141,10 @@ For more information please see [Create a custom variable in the UI](../../../..
 #### Deploying your function
-`git push` the changes to your GitLab repository and the GitLab build pipeline will automatically deploy your function.
+`git push` the changes to your GitLab repository and the GitLab build pipeline deploys your function.
-In your GitLab deploy stage log, there will be output containing your AWS Lambda endpoint URL.
+Your GitLab deploy stage log contains output containing your AWS Lambda endpoint URL,
-The log line will look similar to this:
+with log lines similar to this:
 ```plaintext
 endpoints:
@@ -227,7 +227,7 @@ provider:
 ```
 From there, you can reference them in your functions as well.
-Remember to add `A_VARIABLE` to your GitLab CI/CD variables under **Settings > CI/CD > Variables**, and it will get picked up and deployed with your function.
+Remember to add `A_VARIABLE` to your GitLab CI/CD variables under **Settings > CI/CD > Variables** to be picked up and deployed with your function.
 NOTE: **Note:**
 Anyone with access to the AWS environment may be able to see the values of those
@@ -309,7 +309,7 @@ GitLab allows developers to build and deploy serverless applications using the c
 ### Example
-In the following example, you will:
+This example shows you how to:
 - Install SAM CLI.
 - Create a sample SAM application including a Lambda function and API Gateway.
@@ -414,8 +414,8 @@ Let’s examine the configuration file more closely:
 ### Deploying your application
-Push changes to your GitLab repository and the GitLab build pipeline will automatically
+Push changes to your GitLab repository and the GitLab build pipeline
-deploy your application. If your:
+deploys your application. If your:
 - Build and deploy are successful, [test your deployed application](#testing-the-deployed-application).
 - Build fails, look at the build log to see why the build failed. Some common reasons

--- a/doc/user/project/clusters/serverless/index.md
+++ b/doc/user/project/clusters/serverless/index.md