Reduce number of note boxes in Configure docs

Flow note boxes back into the surrounding paragraph, list, or table
text to ease readability.

doc/api/group_clusters.md

@@ -8,8 +8,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/30213) in GitLab 12.1.
 
-NOTE: **Note:**
-User will need at least maintainer access for the group to use these endpoints.
+Users need at least [Maintainer](../user/permissions.md) access for the group to use these endpoints.
 
 ## List group clusters
 

doc/api/project_clusters.md

@@ -8,8 +8,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/23922) in GitLab 11.7.
 
-NOTE: **Note:**
-User will need at least maintainer access to use these endpoints.
+Users need at least [Maintainer](../user/permissions.md) access to use these endpoints.
 
 ## List project clusters
 

doc/development/chatops_on_gitlabcom.md

@@ -22,9 +22,7 @@ To request access to Chatops on GitLab.com:
 1. Log into <https://ops.gitlab.net/users/sign_in> **using the same username** as for GitLab.com (you may have to rename it).
     1. You could also use the "Sign in with" Google button to sign in, with your GitLab.com email address.
 1. Ask one of your team members to add you to the `chatops` project in Ops. They can do it by running `/chatops run member add <username> gitlab-com/chatops --ops` command in the `#chat-ops-test` Slack channel.
-
-NOTE: **Note:**
-If you had to change your username for GitLab.com on the first step, make sure [to reflect this information](https://gitlab.com/gitlab-com/www-gitlab-com#adding-yourself-to-the-team-page) on [the team page](https://about.gitlab.com/company/team/).
+1. If you had to change your username for GitLab.com on the first step, make sure [to reflect this information](https://gitlab.com/gitlab-com/www-gitlab-com#adding-yourself-to-the-team-page) on [the team page](https://about.gitlab.com/company/team/).
 
 ## See also
 

doc/user/clusters/applications.md

@@ -143,7 +143,6 @@ The Ingress Controller installed is
 [Ingress-NGINX](https://kubernetes.io/docs/concepts/services-networking/ingress/),
 which is supported by the Kubernetes community.
 
-NOTE: **Note:**
 With the following procedure, a load balancer must be installed in your cluster
 to obtain the endpoint. You can use either
 Ingress, or Knative's own load balancer ([Istio](https://istio.io)) if using Knative.
@@ -725,8 +724,8 @@ least 2 people from the
 
 ### Install Sentry using GitLab CI/CD
 
-NOTE: **Note:**
-The Sentry Helm chart [recommends](https://github.com/helm/charts/blob/f6e5784f265dd459c5a77430185d0302ed372665/stable/sentry/values.yaml#L284-L285) at least 3GB of available RAM for database migrations.
+The Sentry Helm chart [recommends](https://github.com/helm/charts/blob/f6e5784f265dd459c5a77430185d0302ed372665/stable/sentry/values.yaml#L284-L285)
+at least 3 GB of available RAM for database migrations.
 
 To install Sentry, define the `.gitlab/managed-apps/config.yaml` file
 with:

doc/user/clusters/environments.md

@@ -43,6 +43,5 @@ Once you have successful deployments to your group-level or instance-level clust
 1. Navigate to your group's **Kubernetes** page.
 1. Click on the **Environments** tab.
 
-NOTE: **Note:**
-Only successful deployments to the cluster is included in this page.
-Non-cluster environments will not be included.
+Only successful deployments to the cluster are included in this page.
+Non-cluster environments aren't included.

doc/user/group/clusters/index.md

@@ -72,9 +72,8 @@ for deployments with a cluster not managed by GitLab, you must ensure:
   (this is [not automatic](https://gitlab.com/gitlab-org/gitlab/-/issues/31519)). Editing
   `KUBE_NAMESPACE` directly is discouraged.
 
-NOTE: **Note:**
 If you [install applications](#installing-applications) on your cluster, GitLab creates
-the resources required to run them even if you choose to manage your own cluster.
+the resources required to run them, even if you choose to manage your own cluster.
 
 ### Clearing the cluster cache
 

doc/user/infrastructure/index.md

@@ -67,8 +67,9 @@ local machine, this is a simple way to get started:
 1. On your local machine, run `terraform init`, passing in the following options,
    replacing `<YOUR-STATE-NAME>`, `<YOUR-PROJECT-ID>`,  `<YOUR-USERNAME>` and
    `<YOUR-ACCESS-TOKEN>` with the relevant values. This command initializes your
-   Terraform state, and stores that state within your GitLab project. This example
-   uses `gitlab.com`:
+   Terraform state, and stores that state within your GitLab project. The name of
+   your state can contain only uppercase and lowercase letters, decimal digits,
+   hyphens, and underscores. This example uses `gitlab.com`:
 
    ```shell
    terraform init \
@@ -82,10 +83,6 @@ local machine, this is a simple way to get started:
        -backend-config="retry_wait_min=5"
    ```
 
-   NOTE: **Note:**
-   The name of your state can contain only uppercase and lowercase letters,
-   decimal digits, hyphens and underscores.
-
 You can now run `terraform plan` and `terraform apply` as you normally would.
 
 ## Get started using GitLab CI

doc/user/project/clusters/add_eks_clusters.md

@@ -65,7 +65,9 @@ To create and add a new Kubernetes cluster to your project, group, or instance:
 1. In the [IAM Management Console](https://console.aws.amazon.com/iam/home), create an IAM policy:
    1. From the left panel, select **Policies**.
    1. Click **Create Policy**, which opens a new window.
-   1. Select the **JSON** tab, and paste in the following snippet in place of the existing content:
+   1. Select the **JSON** tab, and paste the following snippet in place of the
+      existing content. These permissions give GitLab the ability to create
+      resources, but not delete them:
 
       ```json
       {
@@ -112,9 +114,7 @@ To create and add a new Kubernetes cluster to your project, group, or instance:
       }
       ```
 
-      NOTE: **Note:**
-      These permissions give GitLab the ability to create resources, but not delete them.
-      This means that if an error is encountered during the creation process, changes will
+      If an error is encountered during the creation process, changes will
       not be rolled back and you must remove resources manually. You can do this by deleting
       the relevant [CloudFormation stack](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-delete-stack.html)
 

doc/user/project/clusters/add_remove_clusters.md

@@ -44,6 +44,8 @@ Before [adding a Kubernetes cluster](#create-new-cluster) using GitLab, you need
 
 ## Access controls
 
+> - Restricted service account for deployment was [introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/51716) in GitLab 11.5.
+
 When creating a cluster in GitLab, you are asked if you would like to create either:
 
 - A [Role-based access control (RBAC)](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)
@@ -55,9 +57,6 @@ GitLab creates the necessary service accounts and privileges to install and run
 a `gitlab` service account with `cluster-admin` privileges is created in the `default` namespace
 to manage the newly created cluster.
 
-NOTE: **Note:**
-Restricted service account for deployment was [introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/51716) in GitLab 11.5.
-
 The first time you install an application into your cluster, the `tiller` service
 account is created with `cluster-admin` privileges in the
 `gitlab-managed-apps` namespace. This service account is used by Helm to
@@ -152,11 +151,12 @@ Amazon Elastic Kubernetes Service (EKS) at the project, group, or instance level
 
 ## Add existing cluster
 
-If you have an existing Kubernetes cluster, you can add it to a project, group, or instance.
+If you have an existing Kubernetes cluster, you can add it to a project, group,
+or instance.
 
-NOTE: **Note:**
-Kubernetes integration is not supported for arm64 clusters. See the issue
-[Helm Tiller fails to install on arm64 cluster](https://gitlab.com/gitlab-org/gitlab/-/issues/29838) for details.
+Kubernetes integration isn't supported for arm64 clusters. See the issue
+[Helm Tiller fails to install on arm64 cluster](https://gitlab.com/gitlab-org/gitlab/-/issues/29838)
+for details.
 
 ### Existing Kubernetes cluster
 
@@ -191,7 +191,6 @@ To add a Kubernetes cluster to your project, group, or instance:
          kubectl get secret <secret name> -o jsonpath="{['data']['ca\.crt']}" | base64 --decode
          ```
 
-         NOTE: **Note:**
          If the command returns the entire certificate chain, you must copy the Root CA
          certificate and any intermediate certificates at the bottom of the chain.
          A chain file has following structure:
@@ -321,7 +320,7 @@ integration to work properly.
 
 ![RBAC](img/rbac_v13_1.png)
 
-NOTE: **Note:**
+CAUTION: **Caution:**
 Disabling RBAC means that any application running in the cluster,
 or user who can authenticate to the cluster, has full API access. This is a
 [security concern](index.md#security-implications), and may not be desirable.

doc/user/project/clusters/runbooks/index.md

@@ -115,9 +115,7 @@ the components outlined above and the pre-loaded demo runbook.
       VARIABLE_VALUE = project.variables.get('PRIVATE_TOKEN').value
       ```
 
-1. To configure the operation of a runbook, create and configure variables:
-
-   NOTE: **Note:**
+1. To configure the operation of a runbook, create and configure variables.
    For this example, we are using the **Run SQL queries in Notebook** section in the
    sample runbook to query a PostgreSQL database. The first four lines of the following
    code block define the variables that are required for this query to function:

doc/user/project/clusters/serverless/aws.md

@@ -136,8 +136,8 @@ This example code does the following:
 In order to interact with your AWS account, the GitLab CI/CD pipelines require both `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` to be defined in your GitLab settings under **Settings > CI/CD > Variables**.
 For more information please see [Create a custom variable in the UI](../../../../ci/variables/README.md#create-a-custom-variable-in-the-ui).
 
-NOTE: **Note:**
-   The AWS credentials you provide must include IAM policies that provision correct access control to AWS Lambda, API Gateway, CloudFormation, and IAM resources.
+ The AWS credentials you provide must include IAM policies that provision correct
+ access control to AWS Lambda, API Gateway, CloudFormation, and IAM resources.
 
 #### Deploying your function
 
@@ -154,9 +154,7 @@ endpoints:
 #### Manually testing your function
 
 Running the following `curl` command should trigger your function.
-
-NOTE: **Note:**
-Your URL should be the one retrieved from the GitLab deploy stage log.
+Your URL should be the one retrieved from the GitLab deploy stage log:
 
 ```shell
 curl https://u768nzby1j.execute-api.us-east-1.amazonaws.com/production/hello

doc/user/project/clusters/serverless/index.md

@@ -75,8 +75,8 @@ To run Knative on GitLab, you will need:
 
 ## Installing Knative via GitLab's Kubernetes integration
 
-NOTE: **Note:**
-The minimum recommended cluster size to run Knative is 3-nodes, 6 vCPUs, and 22.50 GB memory. **RBAC must be enabled.**
+The minimum recommended cluster size to run Knative is 3-nodes, 6 vCPUs, and 22.50 GB
+memory. **RBAC must be enabled.**
 
 1. [Add a Kubernetes cluster](../add_remove_clusters.md).
 1. Select the **Applications** tab and scroll down to the Knative app section. Enter the domain to be used with
@@ -99,22 +99,19 @@ The minimum recommended cluster size to run Knative is 3-nodes, 6 vCPUs, and 22.
 
    ![DNS entry](img/dns-entry.png)
 
-NOTE: **Note:**
 You can deploy either [functions](#deploying-functions) or [serverless applications](#deploying-serverless-applications)
-on a given project but not both. The current implementation makes use of a `serverless.yml` file to signal a FaaS project.
+on a given project, but not both. The current implementation makes use of a
+`serverless.yml` file to signal a FaaS project.
 
 ## Using an existing installation of Knative
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/58941) in GitLab 12.0.
 
-NOTE: **Note:**
-The "invocations" monitoring feature of GitLab serverless will not work when
+The _invocations_ monitoring feature of GitLab serverless won't work when
 adding an existing installation of Knative.
 
-It is also possible to use GitLab Serverless with an existing Kubernetes
-cluster which already has Knative installed.
-
-You must do the following:
+It's also possible to use GitLab Serverless with an existing Kubernetes cluster
+which already has Knative installed. You must do the following:
 
 1. Follow the steps to
    [add an existing Kubernetes
@@ -453,16 +450,16 @@ To run a function locally:
 
 > Introduced in GitLab 11.5.
 
+12345678901234567890123456789012345678901234567890123456789012345678901234567890
 Serverless applications are an alternative to [serverless functions](#deploying-functions).
-They are useful in scenarios where an existing runtime does not meet the needs of an application,
-such as one written in a language that has no runtime available. Note though that serverless
-applications should be stateless!
-
-NOTE: **Note:**
-You can reference and import the sample [Knative Ruby App](https://gitlab.com/knative-examples/knative-ruby-app) to get started.
+They're useful in scenarios where an existing runtime does not meet the needs of
+an application, such as one written in a language that has no runtime available.
+Note though that serverless applications should be stateless.
 
-Add the following `.gitlab-ci.yml` to the root of your repository
-(you may skip this step if you've previously cloned the sample [Knative Ruby App](https://gitlab.com/knative-examples/knative-ruby-app) mentioned above):
+You can reference and import the sample [Knative Ruby App](https://gitlab.com/knative-examples/knative-ruby-app)
+to get started. Add the following `.gitlab-ci.yml` to the root of your repository
+(you may skip this step if you've previously cloned the previously mentioned,
+sample [Knative Ruby App](https://gitlab.com/knative-examples/knative-ruby-app)):
 
 ```yaml
 include:
@@ -561,14 +558,18 @@ Or:
 
 ## Enabling TLS for Knative services
 
-By default, a GitLab serverless deployment will be served over `http`. In order to serve over `https` you
-must manually obtain and install TLS certificates.
+By default, a GitLab serverless deployment will be served over `http`. To serve
+over `https`, you must manually obtain and install TLS certificates.
 
-The simplest way to accomplish this is to
-use [Certbot to manually obtain Let's Encrypt certificates](https://knative.dev/docs/serving/using-a-tls-cert/#using-certbot-to-manually-obtain-let-s-encrypt-certificates). Certbot is a free, open source software tool for automatically using Let’s Encrypt certificates on manually-administrated websites to enable HTTPS.
+12345678901234567890123456789012345678901234567890123456789012345678901234567890
+The simplest way to accomplish this is to use Certbot to
+[manually obtain Let's Encrypt certificates](https://knative.dev/docs/serving/using-a-tls-cert/#using-certbot-to-manually-obtain-let-s-encrypt-certificates).
+Certbot is a free, open source software tool for automatically using Let’s Encrypt
+certificates on manually-administrated websites to enable HTTPS.
 
-NOTE: **Note:**
-The instructions below relate to installing and running Certbot on a Linux server that has Python 3 installed and may not work on other operating systems or with other versions of Python.
+The following instructions relate to installing and running Certbot on a Linux
+server that has Python 3 installed, and may not work on other operating systems
+or with other versions of Python.
 
 1. Install Certbot by running the
    [`certbot-auto` wrapper script](https://certbot.eff.org/docs/install.html#certbot-auto).