Add latest changes from gitlab-org/gitlab@14-4-stable-eev14.4.0-rc42

8 files changed, 203 insertions, 163 deletions

diff --git a/doc/update/deprecations.md b/doc/update/deprecations.md
index d453c5d8336..e2af4f453c0 100644
--- a/doc/update/deprecations.md
+++ b/doc/update/deprecations.md
@@ -6,6 +6,16 @@ info: "See the Technical Writers assigned to Development Guidelines: https://abo
 
 # Deprecated feature removal schedule
 
+DISCLAIMER:
+This page contains information related to upcoming products, features, and functionality.
+It is important to note that the information presented is for informational purposes only.
+Please do not rely on this information for purchasing or planning purposes.
+As with all projects, the items mentioned on this page are subject to change or delay.
+The development, release, and timing of any products, features, or functionality remain at the
+sole discretion of GitLab Inc.
+
+<!-- vale off -->
+
 <!--
 This page is automatically generated from the YAML files in `/data/deprecations` by the rake task
 located at `lib/tasks/gitlab/docs/compile_deprecations.rake`.
@@ -16,6 +26,24 @@ To add a deprecation, use the example.yml file in `/data/deprecations/templates`
 then run `bin/rake gitlab:docs:compile_deprecations`.
 -->
 
+## 14.4
+
+### Rename Task Runner pod to Toolbox
+
+The Task Runner pod is used to execute periodic housekeeping tasks within the GitLab application and is often confused with the GitLab Runner. Thus, [Task Runner will be renamed to Toolbox](https://gitlab.com/groups/gitlab-org/charts/-/epics/25).
+
+This will result in the rename of the sub-chart: `gitlab/task-runner` to `gitlab/toolbox`. Resulting pods will be named along the lines of `{{ .Release.Name }}-toolbox`, which will often be `gitlab-toolbox`. They will be locatable with the label `app=toolbox`.
+
+Announced: 2021-08-22
+
+## 14.6
+
+### Release CLI be distributed as a generic package
+
+The [release-cli](https://gitlab.com/gitlab-org/release-cli) will be released as a [generic package](https://gitlab.com/gitlab-org/release-cli/-/packages) starting in GitLab 14.2. We will continue to deploy it as a binary to S3 until GitLab 14.5 and stop distributing it in S3 in GitLab 14.6.
+
+Announced: 2021-08-22
+
 ## 15.0
 
 ### Legacy database configuration
@@ -30,19 +58,19 @@ Announced: 2021-09-22
 
 ### Audit events for repository push events
 
-Audit events for [repository events](../administration/audit_events.md#repository-push) are now deprecated and will be removed in GitLab 15.0.
+Audit events for [repository events](https://docs.gitlab.com/ee/administration/audit_events.html#repository-push) are now deprecated and will be removed in GitLab 15.0.
 
 These events have always been disabled by default and had to be manually enabled with a
 feature flag. Enabling them can cause too many events to be generated which can
 dramatically slow down GitLab instances. For this reason, they are being removed.
 
-Announced: 2021-09-02
+Announced: 2021-09-22
 
 ### OmniAuth Kerberos gem
 
 The `omniauth-kerberos` gem will be removed in our next major release, GitLab 15.0.
 
-This gem has not been maintained and has very little usage. We therefore plan to remove support for this authentication method and recommend using the Kerberos [SPNEGO](https://en.wikipedia.org/wiki/SPNEGO) integration instead. You can follow the [upgrade instructions](../integration/kerberos.md#upgrading-from-password-based-to-ticket-based-kerberos-sign-ins) to upgrade from the `omniauth-kerberos` integration to the supported one.
+This gem has not been maintained and has very little usage. We therefore plan to remove support for this authentication method and recommend using the Kerberos [SPNEGO](https://en.wikipedia.org/wiki/SPNEGO) integration instead. You can follow the [upgrade instructions](https://docs.gitlab.com/ee/integration/kerberos.html#upgrading-from-password-based-to-ticket-based-kerberos-sign-ins) to upgrade from the `omniauth-kerberos` integration to the supported one.
 
 Note that we are not deprecating the Kerberos SPNEGO integration, only the old password-based Kerberos integration.
 
@@ -50,18 +78,24 @@ Announced: 2021-09-22
 
 ### GitLab Serverless
 
-[GitLab Serverless](../user/project/clusters/serverless/index.md) is a feature set to support Knative-based serverless development with automatic deployments and monitoring.
+[GitLab Serverless](https://docs.gitlab.com/ee/user/project/clusters/serverless/) is a feature set to support Knative-based serverless development with automatic deployments and monitoring.
 
 We decided to remove the GitLab Serverless features as they never really resonated with our users. Besides, given the continuous development of Kubernetes and Knative, our current implementations do not even work with recent versions.
 
 Announced: 2021-09-22
 
-## 14.4
+## 15.2
 
-### Rename Task Runner pod to Toolbox
+### NFS for Git repository storage deprecated
 
-The Task Runner pod is used to execute periodic housekeeping tasks within the GitLab application and is often confused with the GitLab Runner. Thus, [Task Runner will be renamed to Toolbox](https://gitlab.com/groups/gitlab-org/charts/-/epics/25).
+With the general availability of Gitaly Cluster ([introduced in GitLab 13.0](https://about.gitlab.com/releases/2020/05/22/gitlab-13-0-released/)), we have deprecated development (bugfixes, performance improvements, etc) for NFS for Git repository storage in GitLab 14.0. We will continue to provide technical support for NFS for Git repositories throughout 14.x, but we will remove all support for NFS in GitLab 15.0. Please see our official [Statement of Support](https://about.gitlab.com/support/statement-of-support.html#gitaly-and-nfs) for further information.
 
-This will result in the rename of the sub-chart: `gitlab/task-runner` to `gitlab/toolbox`. Resulting pods will be named along the lines of `{{ .Release.Name }}-toolbox`, which will often be `gitlab-toolbox`. They will be locatable with the label `app=toolbox`.
+Gitaly Cluster offers tremendous benefits for our customers such as:
 
-Announced: 2021-09-22
+- [Variable replication factors](https://docs.gitlab.com/ee/administration/gitaly/index.html#replication-factor).
+- [Strong consistency](https://docs.gitlab.com/ee/administration/gitaly/index.html#strong-consistency).
+- [Distributed read capabilities](https://docs.gitlab.com/ee/administration/gitaly/index.html#distributed-reads).
+
+We encourage customers currently using NFS for Git repositories to plan their migration by reviewing our documentation on [migrating to Gitaly Cluster](https://docs.gitlab.com/ee/administration/gitaly/index.html#migrate-to-gitaly-cluster).
+
+Announced: 2021-06-22
diff --git a/doc/update/index.md b/doc/update/index.md
index fadb55684f8..b719c47ae26 100644
--- a/doc/update/index.md
+++ b/doc/update/index.md
@@ -79,6 +79,10 @@ See the guide to [plan your GitLab upgrade](plan_your_upgrade.md).
 Certain major/minor releases may require different migrations to be
 finished before you update to the newer version.
 
+Decrease the time required to complete these migrations by increasing the number of
+[Sidekiq workers](../administration/operations/extra_sidekiq_processes.md)
+that can process jobs in the `background_migration` queue.
+
 **For GitLab 14.0 and newer**
 
 To check the status of [batched background migrations](../user/admin_area/monitoring/background_migrations.md):
@@ -88,6 +92,16 @@ To check the status of [batched background migrations](../user/admin_area/monito
 
    ![queued batched background migrations table](img/batched_background_migrations_queued_v14_0.png)
 
+The status of batched background migrations can also be queried directly in the database.
+
+1. Log into a `psql` prompt according to the directions for your instance's installation method
+(for example, `sudo gitlab-psql` for Omnibus installations).
+1. Run the following query in the `psql` session to see details on incomplete batched background migrations:
+
+   ```sql
+   select job_class_name, table_name, column_name, job_arguments from batched_background_migrations where status <> 3;
+   ```
+
 **For Omnibus installations**
 
 You can also run:
@@ -136,9 +150,9 @@ pending_job_classes.each { |job_class| Gitlab::BackgroundMigration.steal(job_cla
 
 ## Dealing with running CI/CD pipelines and jobs
 
-If you upgrade your GitLab instance while the GitLab Runner is processing jobs, the trace updates will fail. Once GitLab is back online, then the trace updates should self-heal. However, depending on the error, the GitLab Runner will either retry or eventually terminate job handling.
+If you upgrade your GitLab instance while the GitLab Runner is processing jobs, the trace updates fail. When GitLab is back online, the trace updates should self-heal. However, depending on the error, the GitLab Runner either retries or eventually terminates job handling.
 
-As for the artifacts, the GitLab Runner will attempt to upload them three times, after which the job will eventually fail.
+As for the artifacts, the GitLab Runner attempts to upload them three times, after which the job eventually fails.
 
 To address the above two scenario's, it is advised to do the following prior to upgrading:
 
@@ -193,7 +207,7 @@ upgrade paths.
 
 | Target version | Your version | Supported upgrade path                                                                               | Note                                                                                                                              |
 | -------------- | ------------ | ---------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------- |
-| `14.1.2`       | `13.9.2`     | `13.9.2` -> `13.12.9` -> `14.0.7` -> `14.1.2`                                                        | Two intermediate versions are required: `13.12` and `14.0`, then `14.1`.                                                          |
+| `14.1.6`       | `13.9.2`     | `13.9.2` -> `13.12.12` -> `14.0.11` -> `14.1.6`                                                        | Two intermediate versions are required: `13.12` and `14.0`, then `14.1`.                                                          |
 | `13.12.10`     | `12.9.2`     | `12.9.2` -> `12.10.14` -> `13.0.14`  -> `13.1.11` -> `13.8.8` -> `13.12.10`                          | Four intermediate versions are required: `12.10`, `13.0`, `13.1` and `13.8.8`, then `13.12.10`.                               |
 | `13.2.10`      | `11.5.0`     | `11.5.0` -> `11.11.8` -> `12.0.12` -> `12.1.17` -> `12.10.14` -> `13.0.14` -> `13.1.11` -> `13.2.10` | Six intermediate versions are required: `11.11`, `12.0`, `12.1`, `12.10`, `13.0` and `13.1`, then `13.2.10`.                      |
 | `12.10.14`     | `11.3.4`     | `11.3.4` -> `11.11.8` -> `12.0.12` -> `12.1.17` -> `12.10.14`                                        | Three intermediate versions are required: `11.11`, `12.0` and `12.1`, then `12.10.14`.                                            |
@@ -206,7 +220,7 @@ upgrade paths.
 Upgrading the *major* version requires more attention.
 Backward-incompatible changes and migrations are reserved for major versions.
 Follow the directions carefully as we
-cannot guarantee that upgrading between major versions will be seamless.
+cannot guarantee that upgrading between major versions is seamless.
 
 It is required to follow the following upgrade steps to ensure a successful *major* version upgrade:
 
@@ -293,6 +307,11 @@ NOTE:
 Specific information that follow related to Ruby and Git versions do not apply to [Omnibus installations](https://docs.gitlab.com/omnibus/)
 and [Helm Chart deployments](https://docs.gitlab.com/charts/). They come with appropriate Ruby and Git versions and are not using system binaries for Ruby and Git. There is no need to install Ruby or Git when utilizing these two approaches.
 
+### 14.4.0
+
+Git 2.33.x and later is required. We recommend you use the
+[Git version provided by Gitaly](../install/installation.md#git).
+
 ### 14.3.0
 
 Ruby 2.7.4 is required. Refer to [the Ruby installation instructions](../install/installation.md#2-ruby)
@@ -402,7 +421,7 @@ Git 2.31.x and later is required. We recommend you use the
 ### 13.9.0
 
 We've detected an issue [with a column rename](https://gitlab.com/gitlab-org/gitlab/-/issues/324160)
-that will prevent upgrades to GitLab 13.9.0, 13.9.1, 13.9.2 and 13.9.3 when following the zero-downtime steps. It is necessary
+that prevents upgrades to GitLab 13.9.0, 13.9.1, 13.9.2, and 13.9.3 when following the zero-downtime steps. It is necessary
 to perform the following additional steps for the zero-downtime upgrade:
 
 1. Before running the final `sudo gitlab-rake db:migrate` command on the deploy node,
@@ -423,7 +442,7 @@ to perform the following additional steps for the zero-downtime upgrade:
    ```
 
 If you have already run the final `sudo gitlab-rake db:migrate` command on the deploy node and have
-encountered the [column rename issue](https://gitlab.com/gitlab-org/gitlab/-/issues/324160), you will
+encountered the [column rename issue](https://gitlab.com/gitlab-org/gitlab/-/issues/324160), you
 see the following error:
 
 ```shell
diff --git a/doc/update/package/downgrade.md b/doc/update/package/downgrade.md
index 9a528f5ee44..96b17a7632b 100644
--- a/doc/update/package/downgrade.md
+++ b/doc/update/package/downgrade.md
@@ -12,7 +12,7 @@ of a package.
 WARNING:
 You must at least have a database backup created under the version you are
 downgrading to. Ideally, you should have a
-[full backup archive](../../raketasks/backup_restore.md#back-up-gitlab)
+[full backup archive](../../raketasks/backup_restore.md)
 on hand.
 
 The example below demonstrates the downgrade procedure when downgrading between minor
diff --git a/doc/update/package/index.md b/doc/update/package/index.md
index 44be79f22fb..776a7111188 100644
--- a/doc/update/package/index.md
+++ b/doc/update/package/index.md
@@ -4,103 +4,99 @@ group: Distribution
 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
 ---
 
-# Upgrade GitLab using the GitLab Package **(FREE SELF)**
+# Upgrade GitLab by using the GitLab package **(FREE SELF)**
 
-This section describes how to upgrade GitLab to a new version using the
+You can upgrade GitLab to a new version by using the
 GitLab package.
 
-We recommend performing upgrades between major and minor releases no more than once per
-week, to allow time for background migrations to finish. Decrease the time required to
-complete these migrations by increasing the number of
-[Sidekiq workers](../../administration/operations/extra_sidekiq_processes.md)
-that can process jobs in the `background_migration` queue.
-
-If you don't follow the steps in [zero downtime upgrades](../zero_downtime.md),
-your GitLab application will not be available to users while an upgrade is in progress.
-They either see a "Deploy in progress" message or a "502" error in their web browser.
-
-Prerequisites:
-
-- [Supported upgrade paths](../index.md#upgrade-paths)
-  has suggestions on when to upgrade. Upgrade paths are enforced for version upgrades by
-  default. This restricts performing direct upgrades that skip major versions (for
-  example 10.3 to 12.7 in one jump) that **can break GitLab
-  installations** due to multiple reasons like deprecated or removed configuration
-  settings, upgrade of internal tools and libraries, and so on.
-- If you are upgrading from a non-Package installation to a GitLab Package installation, see
-  [Upgrading from a non-Package installation to a GitLab Package installation](https://docs.gitlab.com/omnibus/convert_to_omnibus.html).
-- It's important to ensure that any
+## Prerequisites
+
+- Decide when to upgrade by viewing the [supported upgrade paths](../index.md#upgrade-paths).
+  You can't directly skip major versions (for example, go from 10.3 to 12.7 in one step).
+- If you are upgrading from a non-package installation to a GitLab package installation, see
+  [Upgrading from a non-package installation to a GitLab package installation](https://docs.gitlab.com/omnibus/update/convert_to_omnibus.html).
+- Ensure that any
   [background migrations](../index.md#checking-for-background-migrations-before-upgrading)
-  have been fully completed before upgrading to a new major version. Upgrading
-  before background migrations have finished may lead to data corruption.
+  are fully completed. Upgrading
+  before background migrations have finished can lead to data corruption.
+  We recommend performing upgrades between major and minor releases no more than once per
+  week, to allow time for background migrations to finish.
 - Gitaly servers must be upgraded to the newer version prior to upgrading the application server.
   This prevents the gRPC client on the application server from sending RPCs that the old Gitaly version
   does not support.
 
-You can upgrade the GitLab Package using one of the following methods:
+## Downtime
+
+- For single node installations, GitLab is not available to users while an
+  upgrade is in progress. The user's web browser shows a `Deploy in progress` message or a `502` error.
+- For multi-node installations, see how to perform
+  [zero downtime upgrades](../zero_downtime.md).
+
+## Version-specific changes
+
+Upgrading versions might need some manual intervention. For more information,
+check the version your are upgrading to:
+
+- [GitLab 14](https://docs.gitlab.com/omnibus/update/gitlab_14_changes.html)
+- [GitLab 13](https://docs.gitlab.com/omnibus/update/gitlab_13_changes.html)
+- [GitLab 12](https://docs.gitlab.com/omnibus/update/gitlab_12_changes.html)
+- [GitLab 11](https://docs.gitlab.com/omnibus/update/gitlab_11_changes.html)
 
-- [Using the official repositories](#upgrade-using-the-official-repositories).
-- [Using a manually-downloaded package](#upgrade-using-a-manually-downloaded-package).
+## Back up before upgrading
 
-Both automatically back up the GitLab database before installing a newer
-GitLab version. You may skip this automatic database backup by creating an empty file
+The GitLab database is backed up before installing a newer GitLab version. You
+may skip this automatic database backup by creating an empty file
 at `/etc/gitlab/skip-auto-backup`:
 
 ```shell
 sudo touch /etc/gitlab/skip-auto-backup
 ```
 
-For safety reasons, you should maintain an up-to-date backup on your own if you plan to use this flag.
-
-## Version-specific changes
-
-Updating to major versions might need some manual intervention. For more information,
-check the version your are upgrading to:
-
-- [GitLab 14](https://docs.gitlab.com/omnibus/gitlab_14_changes.html)
-- [GitLab 13](https://docs.gitlab.com/omnibus/gitlab_13_changes.html)
-- [GitLab 12](https://docs.gitlab.com/omnibus/gitlab_12_changes.html)
-- [GitLab 11](https://docs.gitlab.com/omnibus/gitlab_11_changes.html)
+Nevertheless, it is highly recommended to maintain a full up-to-date
+[backup](../../raketasks/backup_restore.md) on your own.
 
 ## Upgrade using the official repositories
 
 All GitLab packages are posted to the GitLab [package server](https://packages.gitlab.com/gitlab/).
 Five repositories are maintained:
 
-- [GitLab EE](https://packages.gitlab.com/gitlab/gitlab-ee): for official
-  [Enterprise Edition](https://about.gitlab.com/pricing/) releases.
-- [GitLab CE](https://packages.gitlab.com/gitlab/gitlab-ce): for official Community Edition releases.
-- [Unstable](https://packages.gitlab.com/gitlab/unstable): for release candidates and other unstable versions.
-- [Nighty Builds](https://packages.gitlab.com/gitlab/nightly-builds): for nightly builds.
-- [Raspberry Pi](https://packages.gitlab.com/gitlab/raspberry-pi2): for official Community Edition releases built for [Raspberry Pi](https://www.raspberrypi.org) packages.
+- [`gitlab/gitlab-ee`](https://packages.gitlab.com/gitlab/gitlab-ee): The full
+  GitLab package that contains all the Community Edition features plus the
+  [Enterprise Edition](https://about.gitlab.com/pricing/) ones.
+- [`gitlab/gitlab-ce`](https://packages.gitlab.com/gitlab/gitlab-ce): A stripped
+  down package that contains only the Community Edition features.
+- [`gitlab/unstable`](https://packages.gitlab.com/gitlab/unstable): Release candidates and other unstable versions.
+- [`gitlab/nightly-builds`](https://packages.gitlab.com/gitlab/nightly-builds): Nightly builds.
+- [`gitlab/raspberry-pi2`](https://packages.gitlab.com/gitlab/raspberry-pi2): Official Community Edition releases built for [Raspberry Pi](https://www.raspberrypi.org) packages.
 
-If you have installed Omnibus GitLab [Community Edition](https://about.gitlab.com/install/?version=ce)
+If you have installed GitLab [Community Edition](https://about.gitlab.com/install/?version=ce)
 or [Enterprise Edition](https://about.gitlab.com/install/), then the
 official GitLab repository should have already been set up for you.
 
-To upgrade to the newest GitLab version, run:
+### Upgrade to the latest version using the official repositories
 
-- For GitLab [Enterprise Edition](https://about.gitlab.com/pricing/):
+If you upgrade GitLab regularly, for example once a month, you can upgrade to
+the latest version by using your package manager.
 
-  ```shell
-  # Debian/Ubuntu
-  sudo apt-get update
-  sudo apt-get install gitlab-ee
+To upgrade to the latest GitLab version:
 
-  # Centos/RHEL
-  sudo yum install gitlab-ee
-  ```
+```shell
+# Ubuntu/Debian
+sudo apt update && sudo apt install gitlab-ee
+
+# RHEL/CentOS 6 and 7
+sudo yum install gitlab-ee
 
-- For GitLab Community Edition:
+# RHEL/CentOS 8
+sudo dnf install gitlab-ee
 
-  ```shell
-  # Debian/Ubuntu
-  sudo apt-get update
-  sudo apt-get install gitlab-ce
+# SUSE
+sudo zypper install gitlab-ee
+```
 
-  # Centos/RHEL
-  sudo yum install gitlab-ce
-  ```
+NOTE:
+For the GitLab Community Edition, replace `gitlab-ee` with
+`gitlab-ce`.
 
 ### Upgrade to a specific version using the official repositories
 
@@ -113,30 +109,43 @@ versions, so you must specify the specific GitLab package with each upgrade.
 To specify the intended GitLab version number in your package manager's install
 or upgrade command:
 
-1. First, identify the GitLab version number in your package manager:
+1. Identify the version number of the installed package:
 
    ```shell
    # Ubuntu/Debian
    sudo apt-cache madison gitlab-ee
+
    # RHEL/CentOS 6 and 7
    yum --showduplicates list gitlab-ee
+
    # RHEL/CentOS 8
-   dnf search gitlab-ee*
+   dnf --showduplicates list gitlab-ee
+
+   # SUSE
+   zypper search -s gitlab-ee
    ```
 
-1. Then install the specific GitLab package:
+1. Install the specific `gitlab-ee` package by using one of the following commands
+   and replacing `<version>` with the version you found in the previous step:
 
    ```shell
    # Ubuntu/Debian
-   sudo apt install gitlab-ee=12.0.12-ee.0
+   sudo apt install gitlab-ee=<version>
+
    # RHEL/CentOS 6 and 7
-   yum install gitlab-ee-12.0.12-ee.0.el7
+   yum install gitlab-ee-<version>
+
    # RHEL/CentOS 8
-   dnf install gitlab-ee-12.0.12-ee.0.el8
+   dnf install gitlab-ee-<version>
+
    # SUSE
-   zypper install gitlab-ee=12.0.12-ee.0
+   zypper install gitlab-ee=<version>
    ```
 
+NOTE:
+For the GitLab Community Edition, replace `gitlab-ee` with
+`gitlab-ce`.
+
 ## Upgrade using a manually-downloaded package
 
 NOTE:
@@ -150,34 +159,30 @@ install GitLab for the first time or update it.
 To download and install GitLab:
 
 1. Visit the [official repository](#upgrade-using-the-official-repositories) of your package.
-1. Browse to the repository for the type of package you would like to see the
-   list of packages that are available. Multiple packages exist for a
-   single version, one for each supported distribution type. Next to the filename
-   is a label indicating the distribution, as the file names may be the same.
-1. Find the package version you wish to install and click on it.
-1. Click the **Download** button in the upper right corner to download the package.
-1. After the GitLab package is downloaded, install it using the following commands:
-
-   - For GitLab [Enterprise Edition](https://about.gitlab.com/pricing/):
+1. Filter the list by searching for the version you want to install (for example 14.1.6).
+   Multiple packages may exist for a single version, one for each supported distribution
+   and architecture. Next to the filename is a label indicating the distribution,
+   as the filenames may be the same.
+1. Find the package version you wish to install, and select the filename from the list.
+1. Select **Download** in the upper right corner to download the package.
+1. After the package is downloaded, install it by using one of the
+   following commands and replacing `<package_name>` with the package name
+   you downloaded:
 
-     ```shell
-     # Debian/Ubuntu
-     dpkg -i gitlab-ee-<version>.deb
-
-     # CentOS/RHEL
-     rpm -Uvh gitlab-ee-<version>.rpm
-     ```
+   ```shell
+   # Debian/Ubuntu
+   dpkg -i <package_name>
 
-   - For GitLab Community Edition:
+   # CentOS/RHEL
+   rpm -Uvh <package_name>
 
-     ```shell
-     # GitLab Community Edition
-     # Debian/Ubuntu
-     dpkg -i gitlab-ce-<version>.deb
+   # SUSE
+   zypper install <package_name>
+   ```
 
-     # CentOS/RHEL
-     rpm -Uvh gitlab-ce-<version>.rpm
-     ```
+NOTE:
+For the GitLab Community Edition, replace `gitlab-ee` with
+`gitlab-ce`.
 
 ## Troubleshooting
 
@@ -237,8 +242,8 @@ To avoid this issue, either:
 
 ### 500 error when accessing Project > Settings > Repository
 
-When GitLab is migrated from CE > EE > CE, and then back to EE, you
-might get the following error when viewing a project's repository settings:
+This error occurs when GitLab is converted from CE > EE > CE, and then back to EE.
+When viewing a project's repository settings, you can view this error in the logs:
 
 ```shell
 Processing by Projects::Settings::RepositoryController#show as HTML
diff --git a/doc/update/plan_your_upgrade.md b/doc/update/plan_your_upgrade.md
index 406f8322218..320f900dd21 100644
--- a/doc/update/plan_your_upgrade.md
+++ b/doc/update/plan_your_upgrade.md
@@ -4,7 +4,7 @@ group: Distribution
 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/#assignments
 ---
 
-# Create a GitLab upgrade plan
+# Create a GitLab upgrade plan **(FREE SELF)**
 
 This document serves as a guide to create a strong plan to upgrade a self-managed
 GitLab instance.
@@ -75,7 +75,7 @@ Create a backup of GitLab and all its data (database, repos, uploads, builds,
 artifacts, LFS objects, registry, pages). This is vital for making it possible
 to roll back GitLab to a working state if there's a problem with the upgrade:
 
-- Create a [GitLab backup](../raketasks/backup_restore.md#back-up-gitlab).
+- Create a [GitLab backup](../raketasks/backup_restore.md).
   Make sure to follow the instructions based on your installation method.
   Don't forget to back up the [secrets and configuration files](../raketasks/backup_restore.md#storing-configuration-files).
 - Alternatively, create a snapshot of your instance. If this is a multi-node
@@ -173,7 +173,7 @@ If anything doesn't go as planned:
   - [`kubesos`](https://gitlab.com/gitlab-com/support/toolbox/kubesos/) if
     you installed GitLab using the Helm Charts.
 - For support:
-  - [Contact GitLab Support](https://support.gitlab.com) and,
+  - [Contact GitLab Support](https://support.gitlab.com/hc) and,
     if you have one, your Technical Account Manager.
   - If [the situation qualifies](https://about.gitlab.com/support/#definitions-of-support-impact)
     and [your plan includes emergency support](https://about.gitlab.com/support/#priority-support),
diff --git a/doc/update/restore_after_failure.md b/doc/update/restore_after_failure.md
index b8cceb8c367..cedb46a7c71 100644
--- a/doc/update/restore_after_failure.md
+++ b/doc/update/restore_after_failure.md
@@ -31,9 +31,7 @@ attempts. This is because some tables may have been added during the failed
 upgrade. If these tables are still present after you restore from the
 older backup it can lead to migration failures on future upgrades.
 
-Starting in GitLab 8.6 we drop all tables prior to importing the backup to
-prevent this problem. If you've restored a backup to a version prior to 8.6 you
-may have to manually correct the problem next time you upgrade.
+We drop all tables prior to importing the backup to prevent this problem.
 
 Example error:
 
@@ -52,38 +50,16 @@ Copy the version from the error. In this case the version number is
 WARNING:
 Use the following steps only if you are certain you must do them.
 
-### GitLab 8.6+
+1. Pass the version to a database Rake task to manually mark the migration as
+   complete.
 
-Pass the version to a database Rake task to manually mark the migration as
-complete.
+   ```shell
+   # Source install
+   sudo -u git -H bundle exec rake gitlab:db:mark_migration_complete[20151103134857] RAILS_ENV=production
 
-```shell
-# Source install
-sudo -u git -H bundle exec rake gitlab:db:mark_migration_complete[20151103134857] RAILS_ENV=production
+   # Omnibus install
+   sudo gitlab-rake gitlab:db:mark_migration_complete[20151103134857]
+   ```
 
-# Omnibus install
-sudo gitlab-rake gitlab:db:mark_migration_complete[20151103134857]
-```
-
-After the migration is successfully marked, run the Rake `db:migrate` task again.
-Repeat this process until all failed migrations are complete.
-
-### GitLab < 8.6
-
-```shell
-# Source install
-sudo -u git -H bundle exec rails console -e production
-
-# Omnibus install
-sudo gitlab-rails console
-```
-
-At the Rails console, type the following commands:
-
-```ruby
-ActiveRecord::Base.connection.execute("INSERT INTO schema_migrations (version) VALUES('20151103134857')")
-exit
-```
-
-After the migration is successfully marked, run the Rake `db:migrate` task again.
-Repeat this process until all failed migrations are complete.
+1. After the migration is successfully marked, run the Rake `db:migrate` task again.
+1. Repeat this process until all failed migrations are complete.
diff --git a/doc/update/upgrading_from_source.md b/doc/update/upgrading_from_source.md
index 9abf993f0fe..67559db2cf0 100644
--- a/doc/update/upgrading_from_source.md
+++ b/doc/update/upgrading_from_source.md
@@ -258,6 +258,10 @@ sudo systemctl daemon-reload
 
 ### 10. Install libraries, migrations, etc
 
+Make sure you have the required
+[PostgreSQL extensions](../install/requirements.md#postgresql-requirements),
+then proceed to install the needed libraries:
+
 ```shell
 cd /home/git/gitlab
 
@@ -304,15 +308,18 @@ cd /home/git/gitlab
 sudo -u git -H bundle exec rake "gitlab:workhorse:install[/home/git/gitlab-workhorse]" RAILS_ENV=production
 ```
 
+NOTE:
+If you get any errors concerning Rack attack, see the [13.0](#1301) specific
+upgrade instructions.
+
 ### 13. Update Gitaly
 
 #### Compile Gitaly
 
 ```shell
-cd /home/git/gitaly
-sudo -u git -H git fetch --all --tags --prune
-sudo -u git -H git checkout v$(</home/git/gitlab/GITALY_SERVER_VERSION)
-sudo -u git -H make
+# Fetch Gitaly source with Git and compile with Go
+cd /home/git/gitlab
+sudo -u git -H bundle exec rake "gitlab:gitaly:install[/home/git/gitaly,/home/git/repositories]" RAILS_ENV=production
 ```
 
 ### 14. Update GitLab Pages
@@ -375,14 +382,13 @@ Additional instructions here.
 
 ### 13.0.1
 
-As part of [deprecating Rack Attack throttles on Omnibus GitLab](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/4750), Rack Attack initializer on GitLab
+As part of [deprecating Rack Attack throttles on Omnibus GitLab](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/4750), the Rack Attack initializer on GitLab
 was renamed from [`config/initializers/rack_attack_new.rb` to `config/initializers/rack_attack.rb`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/33072).
 If this file exists on your installation, consider creating a backup before updating:
 
 ```shell
 cd /home/git/gitlab
-
-cp config/initializers/rack_attack.rb config/initializers/rack_attack_backup.rb
+cp config/initializers/rack_attack.rb ~/config/initializers/rack_attack_backup.rb
 ```
 
 ## Troubleshooting
diff --git a/doc/update/zero_downtime.md b/doc/update/zero_downtime.md
index f0e6377f355..7a74435267f 100644
--- a/doc/update/zero_downtime.md
+++ b/doc/update/zero_downtime.md
@@ -4,7 +4,7 @@ group: Distribution
 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
 ---
 
-# Zero downtime upgrades
+# Zero downtime upgrades **(FREE SELF)**
 
 Starting with GitLab 9.1.0 it's possible to upgrade to a newer major, minor, or
 patch version of GitLab without having to take your GitLab instance offline.
@@ -428,7 +428,7 @@ sure you remove `/etc/gitlab/skip-auto-reconfigure` and revert
 setting `gitlab_rails['auto_migrate'] = false` in
 `/etc/gitlab/gitlab.rb` after you've completed these steps.
 
-### Use Redis HA (using Sentinel) **(PREMIUM ONLY)**
+### Use Redis HA (using Sentinel) **(PREMIUM SELF)**
 
 Package upgrades may involve version updates to the bundled Redis service. On
 instances using [Redis for scaling](../administration/redis/index.md),
@@ -525,7 +525,7 @@ failover is complete, we can go ahead and upgrade the original primary node.
 Install the package for new version and follow regular package upgrade
 procedure.
 
-## Geo deployment **(PREMIUM ONLY)**
+## Geo deployment **(PREMIUM SELF)**
 
 The order of steps is important. While following these steps, make
 sure you follow them in the right order, on the correct node.
@@ -645,7 +645,7 @@ sure you remove `/etc/gitlab/skip-auto-reconfigure` and revert
 setting `gitlab_rails['auto_migrate'] = false` in
 `/etc/gitlab/gitlab.rb` after you've completed these steps.
 
-## Multi-node / HA deployment with Geo **(PREMIUM ONLY)**
+## Multi-node / HA deployment with Geo **(PREMIUM SELF)**
 
 This section describes the steps required to upgrade a multi-node / HA
 deployment with Geo. Some steps must be performed on a particular node. This