Add latest changes from gitlab-org/gitlab@14-3-stable-eev14.3.0-rc42

20 files changed, 233 insertions, 108 deletions

diff --git a/doc/administration/geo/disaster_recovery/background_verification.md b/doc/administration/geo/disaster_recovery/background_verification.md
index 65e0ffd4366..caa806c92c8 100644
--- a/doc/administration/geo/disaster_recovery/background_verification.md
+++ b/doc/administration/geo/disaster_recovery/background_verification.md
@@ -60,7 +60,7 @@ Feature.enable('geo_repository_verification')
 
 On the **primary** node:
 
-1. On the top bar, select **Menu >** **{admin}** **Admin**.
+1. On the top bar, select **Menu > Admin**.
 1. On the left sidebar, select **Geo > Nodes**.
 1. Expand **Verification information** tab for that node to view automatic checksumming
    status for repositories and wikis. Successes are shown in green, pending work
@@ -70,7 +70,7 @@ On the **primary** node:
 
 On the **secondary** node:
 
-1. On the top bar, select **Menu >** **{admin}** **Admin**.
+1. On the top bar, select **Menu > Admin**.
 1. On the left sidebar, select **Geo > Nodes**.
 1. Expand **Verification information** tab for that node to view automatic checksumming
    status for repositories and wikis. Successes are shown in green, pending work
@@ -89,7 +89,7 @@ in sync.
 
 ## Repository re-verification
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/8550) in GitLab Enterprise Edition 11.6. Available in [GitLab Premium](https://about.gitlab.com/pricing/).
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/8550) in GitLab 11.6.
 
 Due to bugs or transient infrastructure failures, it is possible for Git
 repositories to change unexpectedly without being marked for verification.
@@ -100,7 +100,7 @@ increase load and vice versa.
 
 On the **primary** node:
 
-1. On the top bar, select **Menu >** **{admin}** **Admin**.
+1. On the top bar, select **Menu > Admin**.
 1. On the left sidebar, select **Geo > Nodes**.
 1. Select **Edit** for the **primary** node to customize the minimum
    re-verification interval:
@@ -151,7 +151,7 @@ sudo gitlab-rake geo:verification:wiki:reset
 If the **primary** and **secondary** nodes have a checksum verification mismatch, the cause may not be apparent. To find the cause of a checksum mismatch:
 
 1. On the **primary** node:
-   1. On the top bar, select **Menu >** **{admin}** **Admin**.
+   1. On the top bar, select **Menu > Admin**.
    1. On the left sidebar, select **Overview > Projects**.
    1. Find the project that you want to check the checksum differences and
       select its name.
diff --git a/doc/administration/geo/disaster_recovery/planned_failover.md b/doc/administration/geo/disaster_recovery/planned_failover.md
index 8b55bebb42b..a7a64701cbd 100644
--- a/doc/administration/geo/disaster_recovery/planned_failover.md
+++ b/doc/administration/geo/disaster_recovery/planned_failover.md
@@ -111,7 +111,7 @@ ensure these processes are close to 100% as possible during active use.
 
 On the **secondary** node:
 
-1. On the top bar, select **Menu >** **{admin}** **Admin**.
+1. On the top bar, select **Menu > Admin**.
 1. On the left sidebar, select **Geo > Nodes**.
    Replicated objects (shown in green) should be close to 100%,
    and there should be no failures (shown in red). If a large proportion of
@@ -139,7 +139,7 @@ This [content was moved to another location](background_verification.md).
 
 On the **primary** node:
 
-1. On the top bar, select **Menu >** **{admin}** **Admin**.
+1. On the top bar, select **Menu > Admin**.
 1. On the left sidebar, select **Messages**.
 1. Add a message notifying users on the maintenance window.
    You can check under **Geo > Nodes** to estimate how long it
@@ -152,7 +152,7 @@ To ensure that all data is replicated to a secondary site, updates (write reques
 be disabled on the **primary** site:
 
 1. Enable [maintenance mode](../../maintenance_mode/index.md) on the **primary** node.
-1. On the top bar, select **Menu >** **{admin}** **Admin**.
+1. On the top bar, select **Menu > Admin**.
 1. On the left sidebar, select **Monitoring > Background Jobs**.
 1. On the Sidekiq dashboard, select **Cron**.
 1. Select `Disable All` to disable non-Geo periodic background jobs.
@@ -165,7 +165,7 @@ be disabled on the **primary** site:
 1. If you are manually replicating any data not managed by Geo, trigger the
    final replication process now.
 1. On the **primary** node:
-   1. On the top bar, select **Menu >** **{admin}** **Admin**.
+   1. On the top bar, select **Menu > Admin**.
    1. On the left sidebar, select **Monitoring > Background Jobs**.
    1. On the Sidekiq dashboard, select **Queues**, and wait for all queues except
       those with `geo` in the name to drop to 0.
@@ -180,7 +180,7 @@ be disabled on the **primary** site:
       - The Geo log cursor is up to date (0 events behind).
 
 1. On the **secondary** node:
-   1. On the top bar, select **Menu >** **{admin}** **Admin**.
+   1. On the top bar, select **Menu > Admin**.
    1. On the left sidebar, select **Monitoring > Background Jobs**.
    1. On the Sidekiq dashboard, select **Queues**, and wait for all the `geo`
       queues to drop to 0 queued and 0 running jobs.
diff --git a/doc/administration/geo/disaster_recovery/runbooks/planned_failover_multi_node.md b/doc/administration/geo/disaster_recovery/runbooks/planned_failover_multi_node.md
index 27990748071..4255fba83f6 100644
--- a/doc/administration/geo/disaster_recovery/runbooks/planned_failover_multi_node.md
+++ b/doc/administration/geo/disaster_recovery/runbooks/planned_failover_multi_node.md
@@ -65,7 +65,7 @@ promote a Geo replica and perform a failover.
 
 On the **secondary** node:
 
-1. On the top bar, select **Menu >** **{admin}** **Admin**.
+1. On the top bar, select **Menu > Admin**.
 1. On the left sidebar, select **Geo > Nodes** to see its status.
    Replicated objects (shown in green) should be close to 100%,
    and there should be no failures (shown in red). If a large proportion of
@@ -130,7 +130,7 @@ follow these steps to avoid unnecessary data loss:
       connection.
 
    1. On the **primary** node:
-      1. On the top bar, select **Menu >** **{admin}** **Admin**.
+      1. On the top bar, select **Menu > Admin**.
       1. On the left sidebar, select **Monitoring > Background Jobs**.
       1. On the Sidekiq dhasboard, select **Cron**.
       1. Select `Disable All` to disable any non-Geo periodic background jobs.
@@ -148,7 +148,7 @@ follow these steps to avoid unnecessary data loss:
       [data not managed by Geo](../../replication/datatypes.md#limitations-on-replicationverification),
       trigger the final replication process now.
    1. On the **primary** node:
-      1. On the top bar, select **Menu >** **{admin}** **Admin**.
+      1. On the top bar, select **Menu > Admin**.
       1. On the left sidebar, select **Monitoring > Background Jobs**.
       1. On the Sidekiq dashboard, select **Queues**, and wait for all queues except
          those with `geo` in the name to drop to 0.
@@ -163,7 +163,7 @@ follow these steps to avoid unnecessary data loss:
          - The Geo log cursor is up to date (0 events behind).
 
    1. On the **secondary** node:
-      1. On the top bar, select **Menu >** **{admin}** **Admin**.
+      1. On the top bar, select **Menu > Admin**.
       1. On the left sidebar, select **Monitoring > Background Jobs**.
       1. On the Sidekiq dashboard, select **Queues**, and wait for all the `geo`
          queues to drop to 0 queued and 0 running jobs.
diff --git a/doc/administration/geo/disaster_recovery/runbooks/planned_failover_single_node.md b/doc/administration/geo/disaster_recovery/runbooks/planned_failover_single_node.md
index 9d5e65cd194..18923da1056 100644
--- a/doc/administration/geo/disaster_recovery/runbooks/planned_failover_single_node.md
+++ b/doc/administration/geo/disaster_recovery/runbooks/planned_failover_single_node.md
@@ -115,7 +115,7 @@ follow these steps to avoid unnecessary data loss:
       connection.
 
    1. On the **primary** node:
-      1. On the top bar, select **Menu >** **{admin}** **Admin**.
+      1. On the top bar, select **Menu > Admin**.
       1. On the left sidebar, select **Monitoring > Background Jobs**.
       1. On the Sidekiq dhasboard, select **Cron**.
       1. Select `Disable All` to disable any non-Geo periodic background jobs.
@@ -133,7 +133,7 @@ follow these steps to avoid unnecessary data loss:
       [data not managed by Geo](../../replication/datatypes.md#limitations-on-replicationverification),
       trigger the final replication process now.
    1. On the **primary** node:
-      1. On the top bar, select **Menu >** **{admin}** **Admin**.
+      1. On the top bar, select **Menu > Admin**.
       1. On the left sidebar, select **Monitoring > Background Jobs**.
       1. On the Sidekiq dashboard, select **Queues**, and wait for all queues except
          those with `geo` in the name to drop to 0.
@@ -148,7 +148,7 @@ follow these steps to avoid unnecessary data loss:
          - The Geo log cursor is up to date (0 events behind).
 
    1. On the **secondary** node:
-      1. On the top bar, select **Menu >** **{admin}** **Admin**.
+      1. On the top bar, select **Menu > Admin**.
       1. On the left sidebar, select **Monitoring > Background Jobs**.
       1. On the Sidekiq dashboard, select **Queues**, and wait for all the `geo`
          queues to drop to 0 queued and 0 running jobs.
diff --git a/doc/administration/geo/index.md b/doc/administration/geo/index.md
index 7175d41abd8..48091967189 100644
--- a/doc/administration/geo/index.md
+++ b/doc/administration/geo/index.md
@@ -7,12 +7,6 @@ type: howto
 
 # Geo **(PREMIUM SELF)**
 
-> - Introduced in GitLab Enterprise Edition 8.9.
-> - Using Geo in combination with
->   [multi-node architectures](../reference_architectures/index.md)
->   is considered **Generally Available** (GA) in
->   [GitLab Premium](https://about.gitlab.com/pricing/) 10.4.
-
 Geo is the solution for widely distributed development teams and for providing a warm-standby as part of a disaster recovery strategy.
 
 ## Overview
@@ -144,7 +138,7 @@ The following table lists basic ports that must be open between the **primary**
 | 22               | 22                 | TCP          |
 | 5432             |                    | PostgreSQL   |
 
-See the full list of ports used by GitLab in [Package defaults](https://docs.gitlab.com/omnibus/package-information/defaults.html)
+See the full list of ports used by GitLab in [Package defaults](../package_information/defaults.md)
 
 NOTE:
 [Web terminal](../../ci/environments/index.md#web-terminals) support requires your load balancer to correctly handle WebSocket connections.
@@ -214,11 +208,11 @@ For information on configuring Geo, see [Geo configuration](replication/configur
 
 ### Updating Geo
 
-For information on how to update your Geo site(s) to the latest GitLab version, see [Updating the Geo sites](replication/updating_the_geo_nodes.md).
+For information on how to update your Geo site(s) to the latest GitLab version, see [Updating the Geo sites](replication/updating_the_geo_sites.md).
 
 ### Pausing and resuming replication
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/35913) in [GitLab Premium](https://about.gitlab.com/pricing/) 13.2.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/35913) in GitLab 13.2.
 
 WARNING:
 In GitLab 13.2 and 13.3, promoting a secondary site to a primary while the
@@ -230,7 +224,7 @@ WARNING:
 Pausing and resuming of replication is currently only supported for Geo installations using an
 Omnibus GitLab-managed database. External databases are currently not supported.
 
-In some circumstances, like during [upgrades](replication/updating_the_geo_nodes.md) or a [planned failover](disaster_recovery/planned_failover.md), it is desirable to pause replication between the primary and secondary.
+In some circumstances, like during [upgrades](replication/updating_the_geo_sites.md) or a [planned failover](disaster_recovery/planned_failover.md), it is desirable to pause replication between the primary and secondary.
 
 Pausing and resuming replication is done via a command line tool from the a node in the secondary site where the `postgresql` service is enabled.
 
diff --git a/doc/administration/geo/replication/configuration.md b/doc/administration/geo/replication/configuration.md
index 5b22741f578..88f1ad5b490 100644
--- a/doc/administration/geo/replication/configuration.md
+++ b/doc/administration/geo/replication/configuration.md
@@ -199,7 +199,7 @@ keys must be manually replicated to the **secondary** site.
    gitlab-ctl reconfigure
    ```
 
-1. On the top bar, select **Menu >** **{admin}** **Admin**.
+1. On the top bar, select **Menu > Admin**.
 1. On the left sidebar, select **Geo > Sites**.
 1. Select **New site**.
    ![Add secondary site](img/adding_a_secondary_v13_3.png)
@@ -257,7 +257,7 @@ method to be enabled. This is enabled by default, but if converting an existing
 
 On the **primary** site:
 
-1. On the top bar, select **Menu >** **{admin}** **Admin**.
+1. On the top bar, select **Menu > Admin**.
 1. On the left sidebar, select **Settings > General**.
 1. Expand **Visibility and access controls**.
 1. Ensure "Enabled Git access protocols" is set to either "Both SSH and HTTP(S)" or "Only HTTP(S)".
@@ -267,7 +267,7 @@ On the **primary** site:
 You can sign in to the **secondary** site with the same credentials you used with
 the **primary** site. After you sign in:
 
-1. On the top bar, select **Menu >** **{admin}** **Admin**.
+1. On the top bar, select **Menu > Admin**.
 1. On the left sidebar, select **Geo > Sites**.
 1. Verify that it's correctly identified as a **secondary** Geo site, and that
    Geo is enabled.
@@ -338,7 +338,7 @@ when:
 
 ## Upgrading Geo
 
-See the [updating the Geo sites document](updating_the_geo_nodes.md).
+See the [updating the Geo sites document](updating_the_geo_sites.md).
 
 ## Troubleshooting
 
diff --git a/doc/administration/geo/replication/datatypes.md b/doc/administration/geo/replication/datatypes.md
index a696e5410e5..3f38436429a 100644
--- a/doc/administration/geo/replication/datatypes.md
+++ b/doc/administration/geo/replication/datatypes.md
@@ -47,12 +47,16 @@ verification methods:
 | Blobs    | Container registry _(object storage)_           | Geo with API/Managed/Docker API (*2*) | _Not implemented_      |
 | Blobs    | Package registry _(file system)_                | Geo with API                          | SHA256 checksum        |
 | Blobs    | Package registry _(object storage)_             | Geo with API/Managed (*2*)            | _Not implemented_      |
+| Blobs    | Infrastructure registry _(file system)_         | Geo with API                          | SHA256 checksum        |
+| Blobs    | Infrastructure registry _(object storage)_      | Geo with API/Managed (*2*)            | _Not implemented_      |
 | Blobs    | Versioned Terraform State _(file system)_       | Geo with API                          | SHA256 checksum        |
 | Blobs    | Versioned Terraform State _(object storage)_    | Geo with API/Managed (*2*)            | _Not implemented_      |
 | Blobs    | External Merge Request Diffs _(file system)_    | Geo with API                          | _Not implemented_      |
 | Blobs    | External Merge Request Diffs _(object storage)_ | Geo with API/Managed (*2*)            | _Not implemented_      |
 | Blobs    | Pipeline artifacts _(file system)_              | Geo with API                          | SHA256 checksum        |
 | Blobs    | Pipeline artifacts _(object storage)_           | Geo with API/Managed (*2*)            | SHA256 checksum        |
+| Blobs    | Pages _(file system)_                           | Geo with API                          | _Not implemented_      |
+| Blobs    | Pages _(object storage)_                        | Geo with API/Managed (*2*)            | _Not implemented_      |
 
 - (*1*): Redis replication can be used as part of HA with Redis sentinel. It's not used between Geo sites.
 - (*2*): Object storage replication can be performed by Geo or by your object storage provider/appliance
@@ -189,21 +193,15 @@ successfully, you must replicate their data using some other means.
 |[Job logs](../../job_logs.md)                                                                                  | **Yes** (10.4)                                                          | [No](https://gitlab.com/gitlab-org/gitlab/-/issues/8923)                | Via Object Storage provider if supported. Native Geo support (Beta).          | Verified only on transfer or manually using [Integrity Check Rake Task](../../raketasks/check.md) on both sites and comparing the output between them. |
 |[Container Registry](../../packages/container_registry.md)                                                     | **Yes** (12.3)                                                          | No                                                                      | No                                                                            | Disabled by default. See [instructions](docker_registry.md) to enable. |
 |[Content in object storage (beta)](object_storage.md)                                                          | **Yes** (12.4)                                                          | [No](https://gitlab.com/gitlab-org/gitlab/-/issues/13845)               | No                                                                            |       |
-|[Infrastructure Registry for Terraform Module](../../../user/packages/terraform_module_registry/index.md)                      | **Yes** (14.0)                                                          | [**Yes**](#limitation-of-verification-for-files-in-object-storage) (14.0)                                                         | Via Object Storage provider if supported. Native Geo support (Beta).          | Behind feature flag `geo_package_file_replication`, enabled by default. |
+|[Infrastructure Registry](../../../user/packages/infrastructure_registry/index.md)                             | **Yes** (14.0)                                                          | [**Yes**](#limitation-of-verification-for-files-in-object-storage) (14.0)                                                         | Via Object Storage provider if supported. Native Geo support (Beta).          | Behind feature flag `geo_package_file_replication`, enabled by default. |
 |[Project designs repository](../../../user/project/issues/design_management.md)                                | **Yes** (12.7)                                                          | [No](https://gitlab.com/gitlab-org/gitlab/-/issues/32467)               | No | Designs also require replication of LFS objects and Uploads. |
-|[Package Registry for npm](../../../user/packages/npm_registry/index.md)                                       | **Yes** (13.2)                                                          | [**Yes**](#limitation-of-verification-for-files-in-object-storage) (13.10)                                                         | Via Object Storage provider if supported. Native Geo support (Beta).          | Behind feature flag `geo_package_file_replication`, enabled by default. |
-|[Package Registry for Maven](../../../user/packages/maven_repository/index.md)                                 | **Yes** (13.2)                                                          | [**Yes**](#limitation-of-verification-for-files-in-object-storage) (13.10)                                                         | Via Object Storage provider if supported. Native Geo support (Beta).          | Behind feature flag `geo_package_file_replication`, enabled by default. |
-|[Package Registry for Conan](../../../user/packages/conan_repository/index.md)                                 | **Yes** (13.2)                                                          | [**Yes**](#limitation-of-verification-for-files-in-object-storage) (13.10)                                                         | Via Object Storage provider if supported. Native Geo support (Beta).          | Behind feature flag `geo_package_file_replication`, enabled by default. |
-|[Package Registry for NuGet](../../../user/packages/nuget_repository/index.md)                                 | **Yes** (13.2)                                                          | [**Yes**](#limitation-of-verification-for-files-in-object-storage) (13.10)                                                         | Via Object Storage provider if supported. Native Geo support (Beta).          | Behind feature flag `geo_package_file_replication`, enabled by default. |
-|[Package Registry for PyPI](../../../user/packages/pypi_repository/index.md)                                   | **Yes** (13.2)                                                          | [**Yes**](#limitation-of-verification-for-files-in-object-storage) (13.10)                                                         | Via Object Storage provider if supported. Native Geo support (Beta).          | Behind feature flag `geo_package_file_replication`, enabled by default. |
-|[Package Registry for Composer](../../../user/packages/composer_repository/index.md)                           | **Yes** (13.2)                                                          | [**Yes**](#limitation-of-verification-for-files-in-object-storage) (13.10)                                                         | Via Object Storage provider if supported. Native Geo support (Beta).          | Behind feature flag `geo_package_file_replication`, enabled by default. |
-|[Package Registry for generic packages](../../../user/packages/generic_packages/index.md)                      | **Yes** (13.5)                                                          | [**Yes**](#limitation-of-verification-for-files-in-object-storage) (13.10)                                                         | Via Object Storage provider if supported. Native Geo support (Beta).          | Behind feature flag `geo_package_file_replication`, enabled by default. |
+|[Package Registry](../../../user/packages/package_registry/index.md)                                           | **Yes** (13.2)                                                          | [**Yes**](#limitation-of-verification-for-files-in-object-storage) (13.10)                                                         | Via Object Storage provider if supported. Native Geo support (Beta).          | Behind feature flag `geo_package_file_replication`, enabled by default. |
 |[Versioned Terraform State](../../terraform_state.md)                                                          | **Yes** (13.5)                                                          | [**Yes**](#limitation-of-verification-for-files-in-object-storage) (13.12)                                                                     | Via Object Storage provider if supported. Native Geo support (Beta).          | Replication is behind the feature flag `geo_terraform_state_version_replication`, enabled by default. Verification was behind the feature flag `geo_terraform_state_version_verification`, which was removed in 14.0|
 |[External merge request diffs](../../merge_request_diffs.md)                                                   | **Yes** (13.5)                                                          | No                                                                      | Via Object Storage provider if supported. Native Geo support (Beta).          | Replication is behind the feature flag `geo_merge_request_diff_replication`, enabled by default. Verification is under development, behind the feature flag `geo_merge_request_diff_verification`, introduced in 14.0.|
 |[Versioned snippets](../../../user/snippets.md#versioned-snippets)                                             | [**Yes** (13.7)](https://gitlab.com/groups/gitlab-org/-/epics/2809)     | [**Yes** (14.2)](https://gitlab.com/groups/gitlab-org/-/epics/2810)            | No                                                                            | Verification was implemented behind the feature flag `geo_snippet_repository_verification` in 13.11, and the feature flag was removed in 14.2. |
 |[Server-side Git hooks](../../server_hooks.md)                                                                 | [No](https://gitlab.com/groups/gitlab-org/-/epics/1867)                 | No                                                                      | No                                                                            |       |
 |[Elasticsearch integration](../../../integration/elasticsearch.md)                                             | [No](https://gitlab.com/gitlab-org/gitlab/-/issues/1186)                | No                                                                      | No                                                                            |       |
-|[GitLab Pages](../../pages/index.md)                                                                           | [No](https://gitlab.com/groups/gitlab-org/-/epics/589)                  | No                                                                      | Via Object Storage provider if supported. **No** native Geo support (Beta).                                                                            |       |
+|[GitLab Pages](../../pages/index.md)                                                                           | [**Yes** (14.3)](https://gitlab.com/groups/gitlab-org/-/epics/589)      | No                                                                      | Via Object Storage provider if supported. Native Geo support (Beta).                                                                           | Behind feature flag `geo_pages_deployment_replication`, enabled by default. |
 |[Dependency proxy images](../../../user/packages/dependency_proxy/index.md)                                    | [No](https://gitlab.com/gitlab-org/gitlab/-/issues/259694)              | No                                                                      | No                                                                            | Blocked on [Geo: Secondary Mimicry](https://gitlab.com/groups/gitlab-org/-/epics/1528). Replication of this cache is not needed for Disaster Recovery purposes because it can be recreated from external sources. |
 |[Vulnerability Export](../../../user/application_security/vulnerability_report/#export-vulnerability-details)  | [Not planned](https://gitlab.com/groups/gitlab-org/-/epics/3111)        | No                                                                      |  | Not planned because they are ephemeral and sensitive. They can be regenerated on demand. |
 
diff --git a/doc/administration/geo/replication/disable_geo.md b/doc/administration/geo/replication/disable_geo.md
index 485a5ee1950..ae2597ad649 100644
--- a/doc/administration/geo/replication/disable_geo.md
+++ b/doc/administration/geo/replication/disable_geo.md
@@ -36,7 +36,7 @@ to do that.
 To remove the **primary** site:
 
 1. [Remove all secondary Geo sites](remove_geo_site.md)
-1. On the top bar, select **Menu >** **{admin}** **Admin**.
+1. On the top bar, select **Menu > Admin**.
 1. On the left sidebar, select **Geo > Nodes**.
 1. Select **Remove** for the **primary** node.
 1. Confirm by selecting **Remove** when the prompt appears.
diff --git a/doc/administration/geo/replication/docker_registry.md b/doc/administration/geo/replication/docker_registry.md
index 5cc4f66017b..4004ef3c17f 100644
--- a/doc/administration/geo/replication/docker_registry.md
+++ b/doc/administration/geo/replication/docker_registry.md
@@ -130,7 +130,7 @@ For each application and Sidekiq node on the **secondary** site:
 
 To verify Container Registry replication is working, on the **secondary** site:
 
-1. On the top bar, select **Menu >** **{admin}** **Admin**.
+1. On the top bar, select **Menu > Admin**.
 1. On the left sidebar, select **Geo > Nodes**.
    The initial replication, or "backfill", is probably still in progress.
 
diff --git a/doc/administration/geo/replication/faq.md b/doc/administration/geo/replication/faq.md
index 28030dccb3b..70a6e506c28 100644
--- a/doc/administration/geo/replication/faq.md
+++ b/doc/administration/geo/replication/faq.md
@@ -52,7 +52,7 @@ query.
 
 ## Can I `git push` to a **secondary** site?
 
-Yes! Pushing directly to a **secondary** site (for both HTTP and SSH, including Git LFS) was [introduced](https://about.gitlab.com/releases/2018/09/22/gitlab-11-3-released/) in [GitLab Premium](https://about.gitlab.com/pricing/#self-managed) 11.3.
+Yes! Pushing directly to a **secondary** site (for both HTTP and SSH, including Git LFS) was [introduced](https://about.gitlab.com/releases/2018/09/22/gitlab-11-3-released/) in GitLab 11.3.
 
 ## How long does it take to have a commit replicated to a **secondary** site?
 
diff --git a/doc/administration/geo/replication/object_storage.md b/doc/administration/geo/replication/object_storage.md
index d3931c0ba80..1f799b30125 100644
--- a/doc/administration/geo/replication/object_storage.md
+++ b/doc/administration/geo/replication/object_storage.md
@@ -9,15 +9,19 @@ type: howto
 
 Geo can be used in combination with Object Storage (AWS S3, or other compatible object storage).
 
-The storage method for files is recorded in the database, and the database is replicated
-from the **primary** Geo site to the **secondary** Geo site, so the **secondary** Geo site
-must match the storage method of the **primary** Geo site.
-Therefore, if the **primary** Geo site uses object storage, the **secondary** Geo site must use it too.
-
 Currently, **secondary** sites can use either:
 
 - The same storage bucket as the **primary** site.
 - A replicated storage bucket.
+- Local storage, if the primary uses local storage.
+
+The storage method (local or object storage) for files is recorded in the database, and the database
+is replicated from the **primary** Geo site to the **secondary** Geo site.
+
+When accessing an uploaded object, we get its storage method (local or object storage) from the
+database, so the **secondary** Geo site must match the storage method of the **primary** Geo site.
+
+Therefore, if the **primary** Geo site uses object storage, the **secondary** Geo site must use it too.
 
 To have:
 
@@ -38,7 +42,7 @@ whether they are stored on the local file system or in object storage.
 
 To enable GitLab replication:
 
-1. On the top bar, select **Menu >** **{admin}** **Admin**.
+1. On the top bar, select **Menu > Admin**.
 1. On the left sidebar, select **Geo > Nodes**.
 1. Select **Edit** on the **secondary** site.
 1. In the **Synchronization Settings** section, find the **Allow this secondary node to replicate content on Object Storage**
diff --git a/doc/administration/geo/replication/remove_geo_site.md b/doc/administration/geo/replication/remove_geo_site.md
index 274eb28dbc9..b69dfe2e723 100644
--- a/doc/administration/geo/replication/remove_geo_site.md
+++ b/doc/administration/geo/replication/remove_geo_site.md
@@ -9,7 +9,7 @@ type: howto
 
 **Secondary** sites can be removed from the Geo cluster using the Geo administration page of the **primary** site. To remove a **secondary** site:
 
-1. On the top bar, select **Menu >** **{admin}** **Admin**.
+1. On the top bar, select **Menu > Admin**.
 1. On the left sidebar, select **Geo > Nodes**.
 1. Select the **Remove** button for the **secondary** site you want to remove.
 1. Confirm by selecting **Remove** when the prompt appears.
diff --git a/doc/administration/geo/replication/troubleshooting.md b/doc/administration/geo/replication/troubleshooting.md
index e072696b37c..7b82d742bd5 100644
--- a/doc/administration/geo/replication/troubleshooting.md
+++ b/doc/administration/geo/replication/troubleshooting.md
@@ -27,7 +27,7 @@ Before attempting more advanced troubleshooting:
 
 On the **primary** node:
 
-1. On the top bar, select **Menu >** **{admin}** **Admin**.
+1. On the top bar, select **Menu > Admin**.
 1. On the left sidebar, select **Geo > Nodes**.
 
 We perform the following health checks on each **secondary** node
@@ -610,7 +610,7 @@ to start again from scratch, there are a few steps that can help you:
 
 ### Design repository failures on mirrored projects and project imports
 
-On the top bar, under **Menu >** **{admin}** **Admin > Geo > Nodes**,
+On the top bar, under **Menu > Admin > Geo > Nodes**,
 if the Design repositories progress bar shows
 `Synced` and `Failed` greater than 100%, and negative `Queued`, then the instance
 is likely affected by
@@ -836,7 +836,7 @@ node's URL matches its external URL.
 
 On the **primary** node:
 
-1. On the top bar, select **Menu >** **{admin}** **Admin**.
+1. On the top bar, select **Menu > Admin**.
 1. On the left sidebar, select **Geo > Nodes**.
 1. Find the affected **secondary** site and select **Edit**.
 1. Ensure the **URL** field matches the value found in `/etc/gitlab/gitlab.rb`
diff --git a/doc/administration/geo/replication/tuning.md b/doc/administration/geo/replication/tuning.md
index 9807f3e6444..bcff6181296 100644
--- a/doc/administration/geo/replication/tuning.md
+++ b/doc/administration/geo/replication/tuning.md
@@ -14,7 +14,7 @@ in the background.
 
 On the **primary** site:
 
-1. On the top bar, select **Menu >** **{admin}** **Admin**.
+1. On the top bar, select **Menu > Admin**.
 1. On the left sidebar, select **Geo > Nodes**.
 1. Select **Edit** of the secondary node you want to tune.
 1. Under **Tuning settings**, there are several variables that can be tuned to
diff --git a/doc/administration/geo/replication/updating_the_geo_nodes.md b/doc/administration/geo/replication/updating_the_geo_nodes.md
index 03570048071..f07c8d547a4 100644
--- a/doc/administration/geo/replication/updating_the_geo_nodes.md
+++ b/doc/administration/geo/replication/updating_the_geo_nodes.md
@@ -1,52 +1,9 @@
 ---
-stage: Enablement
-group: Geo
-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
-type: howto
+redirect_to: 'updating_the_geo_sites.md'
+remove_date: '2021-11-23'
 ---
 
-# Updating the Geo nodes **(PREMIUM SELF)**
+This file was moved to [another location](updating_the_geo_sites.md).
 
-WARNING:
-Read these sections carefully before updating your Geo nodes. Not following
-version-specific update steps may result in unexpected downtime. If you have
-any specific questions, [contact Support](https://about.gitlab.com/support/#contact-support).
-
-Updating Geo nodes involves performing:
-
-1. [Version-specific update steps](version_specific_updates.md), depending on the
-   version being updated to or from.
-1. [General update steps](#general-update-steps), for all updates.
-
-## General update steps
-
-NOTE:
-These general update steps are not intended for [high-availability deployments](https://docs.gitlab.com/omnibus/update/README.html#multi-node--ha-deployment), and will cause downtime. If you want to avoid downtime, consider using [zero downtime updates](https://docs.gitlab.com/omnibus/update/README.html#zero-downtime-updates).
-
-To update the Geo nodes when a new GitLab version is released, update **primary**
-and all **secondary** nodes:
-
-1. **Optional:** [Pause replication on each **secondary** node.](../index.md#pausing-and-resuming-replication)
-1. Log into the **primary** node.
-1. [Update GitLab on the **primary** node using Omnibus](https://docs.gitlab.com/omnibus/update/#update-using-the-official-repositories).
-1. Log into each **secondary** node.
-1. [Update GitLab on each **secondary** node using Omnibus](https://docs.gitlab.com/omnibus/update/#update-using-the-official-repositories).
-1. If you paused replication in step 1, [resume replication on each **secondary**](../index.md#pausing-and-resuming-replication)
-1. [Test](#check-status-after-updating) **primary** and **secondary** nodes, and check version in each.
-
-### Check status after updating
-
-Now that the update process is complete, you may want to check whether
-everything is working correctly:
-
-1. Run the Geo Rake task on all nodes, everything should be green:
-
-   ```shell
-   sudo gitlab-rake gitlab:geo:check
-   ```
-
-1. Check the **primary** node's Geo dashboard for any errors.
-1. Test the data replication by pushing code to the **primary** node and see if it
-   is received by **secondary** nodes.
-
-If you encounter any issues, see the [Geo troubleshooting guide](troubleshooting.md).
+<!-- This redirect file can be deleted after <2021-11-23>. -->
+<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/#move-or-rename-a-page -->
diff --git a/doc/administration/geo/replication/updating_the_geo_sites.md b/doc/administration/geo/replication/updating_the_geo_sites.md
new file mode 100644
index 00000000000..e82afe5f0d4
--- /dev/null
+++ b/doc/administration/geo/replication/updating_the_geo_sites.md
@@ -0,0 +1,54 @@
+---
+stage: Enablement
+group: Geo
+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
+type: howto
+---
+
+# Updating the Geo sites **(PREMIUM SELF)**
+
+WARNING:
+Read these sections carefully before updating your Geo sites. Not following
+version-specific update steps may result in unexpected downtime. If you have
+any specific questions, [contact Support](https://about.gitlab.com/support/#contact-support).
+
+Updating Geo sites involves performing:
+
+1. [Version-specific update steps](version_specific_updates.md), depending on the
+   version being updated to or from.
+1. [General update steps](#general-update-steps), for all updates.
+
+## General update steps
+
+NOTE:
+These general update steps are not intended for multi-site deployments,
+and will cause downtime. If you want to avoid downtime, consider using
+[zero downtime upgrades](../../../update/zero_downtime.md#multi-node--ha-deployment-with-geo).
+
+To update the Geo sites when a new GitLab version is released, update **primary**
+and all **secondary** sites:
+
+1. **Optional:** [Pause replication on each **secondary** sites.](../index.md#pausing-and-resuming-replication)
+1. SSH into each node of the **primary** site.
+1. [Upgrade GitLab on the **primary** site](../../../update/package/index.md#upgrade-using-the-official-repositories).
+1. SSH into each node of **secondary** sites.
+1. [Upgrade GitLab on each **secondary** site](../../../update/package/index.md#upgrade-using-the-official-repositories).
+1. If you paused replication in step 1, [resume replication on each **secondary**](../index.md#pausing-and-resuming-replication)
+1. [Test](#check-status-after-updating) **primary** and **secondary** sites, and check version in each.
+
+### Check status after updating
+
+Now that the update process is complete, you may want to check whether
+everything is working correctly:
+
+1. Run the Geo Rake task on an application node for the primary and secondary sites. Everything should be green:
+
+   ```shell
+   sudo gitlab-rake gitlab:geo:check
+   ```
+
+1. Check the **primary** site's Geo dashboard for any errors.
+1. Test the data replication by pushing code to the **primary** site and see if it
+   is received by **secondary** sites.
+
+If you encounter any issues, see the [Geo troubleshooting guide](troubleshooting.md).
diff --git a/doc/administration/geo/replication/usage.md b/doc/administration/geo/replication/usage.md
index 7fe8eec467e..f3c8f6ac759 100644
--- a/doc/administration/geo/replication/usage.md
+++ b/doc/administration/geo/replication/usage.md
@@ -11,7 +11,7 @@ type: howto
 
 After you set up the [database replication and configure the Geo nodes](../index.md#setup-instructions), use your closest GitLab site as you would do with the primary one.
 
-You can push directly to a **secondary** site (for both HTTP, SSH including Git LFS), and the request will be proxied to the primary site instead ([introduced](https://about.gitlab.com/releases/2018/09/22/gitlab-11-3-released/) in [GitLab Premium](https://about.gitlab.com/pricing/#self-managed) 11.3).
+You can push directly to a **secondary** site (for both HTTP, SSH including Git LFS), and the request will be proxied to the primary site instead ([introduced](https://about.gitlab.com/releases/2018/09/22/gitlab-11-3-released/) in GitLab 11.3).
 
 Example of the output you will see when pushing to a **secondary** site:
 
@@ -33,3 +33,13 @@ you can't store credentials in the URL like `user:password@URL`. Instead, you ca
 for Unix-like operating systems or `_netrc` for Windows. In that case, the credentials
 will be stored as a plain text. If you're looking for a more secure way to store credentials,
 you can use [Git Credential Storage](https://git-scm.com/book/en/v2/Git-Tools-Credential-Storage).
+
+## Fetch Go modules from Geo secondary sites
+
+Go modules can be pulled from secondary sites, with a number of limitations:
+
+- Git configuration (using `insteadOf`) is needed to fetch data from the Geo secondary site.
+- For private projects, authentication details need to be specified in `~/.netrc`.
+
+Read more in the
+[working with projects `go get` documentation](../../../user/project/working_with_projects.md#fetch-go-modules-from-geo-secondary-sites).
diff --git a/doc/administration/geo/replication/version_specific_updates.md b/doc/administration/geo/replication/version_specific_updates.md
index 155c06f90b8..84193e6baac 100644
--- a/doc/administration/geo/replication/version_specific_updates.md
+++ b/doc/administration/geo/replication/version_specific_updates.md
@@ -8,9 +8,44 @@ type: howto
 # Version-specific update instructions **(PREMIUM SELF)**
 
 Review this page for update instructions for your version. These steps
-accompany the [general steps](updating_the_geo_nodes.md#general-update-steps)
+accompany the [general steps](updating_the_geo_sites.md#general-update-steps)
 for updating Geo nodes.
 
+## Updating to 14.1, 14.2, 14.3
+
+We found an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/336013) where the Container Registry replication wasn't fully working if you used multi-arch images. In case of a multi-arch image, only the primary architecture (for example `amd64`) would be replicated to the secondary node. This has been [fixed in GitLab 14.3](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/67624) and was backported to 14.2 and 14.1, but manual steps are required to force a re-sync.
+
+You can check if you are affected by running:
+
+```shell
+docker manifest inspect <SECONDARY_IMAGE_LOCATION> | jq '.mediaType'
+```
+
+Where `<SECONDARY_IMAGE_LOCATION>` is a container image on your secondary node.
+If the output matches `application/vnd.docker.distribution.manifest.list.v2+json`
+(there can be a `mediaType` entry at several levels, we only care about the top level entry),
+then you don't need to do anything.
+
+Otherwise, on all your **secondary** nodes, in a [Rails console](../../operations/rails_console.md), run the following:
+
+ ```ruby
+ list_type = 'application/vnd.docker.distribution.manifest.list.v2+json'
+
+ Geo::ContainerRepositoryRegistry.synced.each do |gcr|
+   cr = gcr.container_repository
+   primary = Geo::ContainerRepositorySync.new(cr)
+   cr.tags.each do |tag|
+     primary_manifest = JSON.parse(primary.send(:client).repository_raw_manifest(cr.path, tag.name))
+     next unless primary_manifest['mediaType'].eql?(list_type)
+
+     cr.delete_tag_by_name(tag.name)
+   end
+   primary.execute
+ end
+ ```
+
+If you are running a version prior to 14.1 and are using Geo and multi-arch containers in your Container Registry, we recommend [upgrading](updating_the_geo_sites.md) to at least GitLab 14.1.
+
 ## Updating to GitLab 14.0/14.1
 
 We found an issue where [Primary sites can not be removed from the UI](https://gitlab.com/gitlab-org/gitlab/-/issues/338231).
@@ -277,7 +312,7 @@ GitLab 12.2 includes the following minor PostgreSQL updates:
 
 This update occurs even if major PostgreSQL updates are disabled.
 
-Before [refreshing Foreign Data Wrapper during a Geo upgrade](https://docs.gitlab.com/omnibus/update/README.html#run-post-deployment-migrations-and-checks),
+Before [refreshing Foreign Data Wrapper during a Geo upgrade](../../../update/zero_downtime.md#step-4-run-post-deployment-migrations-and-checks),
 restart the Geo tracking database:
 
 ```shell
diff --git a/doc/administration/geo/setup/database.md b/doc/administration/geo/setup/database.md
index fa343f7eb40..d72bb0737ae 100644
--- a/doc/administration/geo/setup/database.md
+++ b/doc/administration/geo/setup/database.md
@@ -501,6 +501,79 @@ two other clusters of nodes supporting a Geo **secondary** site. One for the
 main database and the other for the tracking database. For more information,
 see [High Availability with Omnibus GitLab](../../postgresql/replication_and_failover.md).
 
+### Changing the replication password
+
+To change the password for the [replication user](https://wiki.postgresql.org/wiki/Streaming_Replication)
+when using Omnibus-managed PostgreSQL instances:
+
+On the GitLab Geo **primary** server:
+
+1. The default value for the replication user is `gitlab_replicator`, but if you've set a custom replication
+   user in your `/etc/gitlab/gitlab.rb` under the `postgresql['sql_replication_user']` setting, make sure to
+   adapt the following instructions for your own user.
+
+   Generate an MD5 hash of the desired password:
+
+   ```shell
+   sudo gitlab-ctl pg-password-md5 gitlab_replicator
+   # Enter password: <your_password_here>
+   # Confirm password: <your_password_here>
+   # 950233c0dfc2f39c64cf30457c3b7f1e
+   ```
+
+   Edit `/etc/gitlab/gitlab.rb`:
+
+   ```ruby
+   # Fill with the hash generated by `gitlab-ctl pg-password-md5 gitlab_replicator`
+   postgresql['sql_replication_password'] = '<md5_hash_of_your_password>'
+   ```
+
+1. Save the file and reconfigure GitLab to change the replication user's password in PostgreSQL:
+
+   ```shell
+   sudo gitlab-ctl reconfigure
+   ```
+
+1. Restart PostgreSQL for the replication password change to take effect:
+
+   ```shell
+   sudo gitlab-ctl restart postgresql
+   ```
+
+Until the password is updated on any **secondary** servers, the [PostgreSQL log](../../logs.md#postgresql-logs) on
+the secondaries will report the following error message:
+
+```console
+FATAL:  could not connect to the primary server: FATAL:  password authentication failed for user "gitlab_replicator"
+```
+
+On all GitLab Geo **secondary** servers:
+
+1. The first step isn't necessary from a configuration perspective, since the hashed `'sql_replication_password'`
+   is not used on the GitLab Geo **secondary**. However in the event that **secondary** needs to be promoted
+   to the GitLab Geo **primary**, make sure to match the `'sql_replication_password'` in the secondary
+   server configuration.
+
+   Edit `/etc/gitlab/gitlab.rb`:
+
+   ```ruby
+   # Fill with the hash generated by `gitlab-ctl pg-password-md5 gitlab_replicator` on the Geo primary
+   postgresql['sql_replication_password'] = '<md5_hash_of_your_password>'
+   ```
+
+1. During the initial replication setup, the `gitlab-ctl replicate-geo-database` command writes the plaintext
+   password for the replication user account to two locations:
+
+   - `gitlab-geo.conf`: Used by the PostgreSQL replication process, written to the PostgreSQL data
+      directory, by default at `/var/opt/gitlab/postgresql/data/gitlab-geo.conf`.
+   - `.pgpass`: Used by the `gitlab-psql` user, located by default at `/var/opt/gitlab/postgresql/.pgpass`.
+
+   Update the plaintext password in both of these files, and restart PostgreSQL:
+
+   ```shell
+   sudo gitlab-ctl restart postgresql
+   ```
+
 ## Multi-node database replication
 
 In GitLab 14.0, Patroni replaced `repmgr` as the supported
@@ -521,7 +594,7 @@ For instructions about how to set up Patroni on the primary site, see the
 
 #### Configuring Patroni cluster for a Geo secondary site
 
-In a Geo secondary site, the main PostgreSQL database is a read-only replica of the primary site’s PostgreSQL database.
+In a Geo secondary site, the main PostgreSQL database is a read-only replica of the primary site's PostgreSQL database.
 
 If you are currently using `repmgr` on your Geo primary site, see [these instructions](#migrating-from-repmgr-to-patroni)
 for migrating from `repmgr` to Patroni.
@@ -651,7 +724,7 @@ Refer to your preferred Load Balancer's documentation for further guidance.
 ##### Step 3. Configure a PgBouncer node on the secondary site
 
 A production-ready and highly available configuration requires at least
-three Consul nodes, a minimum of one PgBouncer node, but it’s recommended to have
+three Consul nodes, a minimum of one PgBouncer node, but it's recommended to have
 one per database node. An internal load balancer (TCP) is required when there is
 more than one PgBouncer service nodes. The internal load balancer provides a single
 endpoint for connecting to the PgBouncer cluster. For more information,
diff --git a/doc/administration/geo/setup/external_database.md b/doc/administration/geo/setup/external_database.md
index 56d196b54ec..13dbf9d1434 100644
--- a/doc/administration/geo/setup/external_database.md
+++ b/doc/administration/geo/setup/external_database.md
@@ -249,7 +249,7 @@ the tracking database on port 5432.
    gitlab-rake geo:db:create
    ```
 
-1. The reconfigure should automatically migrate the database. You can migrate the database manually if needed, for example if `gitlab_rails['auto_migrate'] = false`:
+1. The reconfigure should automatically migrate the database. You can migrate the database manually if needed, for example if `geo_secondary['auto_migrate'] = false`:
 
    ```shell
    gitlab-rake geo:db:migrate