Add latest changes from gitlab-org/gitlab@master

8 files changed, 22 insertions, 17 deletions

diff --git a/doc/administration/geo/replication/container_registry.md b/doc/administration/geo/replication/container_registry.md
index 66c67f29c1c..1c1d9074a04 100644
--- a/doc/administration/geo/replication/container_registry.md
+++ b/doc/administration/geo/replication/container_registry.md
@@ -73,12 +73,11 @@ To configure Container Registry replication:
 Make sure that you have Container Registry set up and working on
 the **primary** site before following the next steps.
 
-We need to make Container Registry send notification events to the
-**primary** site.
+To be able to replicate new container images, the Container Registry must send notification events to the
+**primary** site for every push. The token shared between the Container Registry and the web nodes on the
+**primary** is used to make communication more secure.
 
-For each application and Sidekiq node on the **primary** site:
-
-1. SSH into the node and login as the `root` user:
+1. SSH into your GitLab **primary** server and login as root (for GitLab HA, you only need a Registry node):
 
    ```shell
    sudo -i
@@ -107,15 +106,17 @@ For each application and Sidekiq node on the **primary** site:
    that starts with a letter. You can generate one with `< /dev/urandom tr -dc _A-Z-a-z-0-9 | head -c 32 | sed "s/^[0-9]*//"; echo`
 
    NOTE:
-   If you use an external Registry (not the one integrated with GitLab), you also have to specify
+   If you use an external Registry (not the one integrated with GitLab), you only need to specify
    the notification secret (`registry['notification_secret']`) in the
    `/etc/gitlab/gitlab.rb` file.
 
-   NOTE:
-   If you use GitLab HA, you also have to specify the notification secret (`registry['notification_secret']`) in
-   `/etc/gitlab/gitlab.rb` file for every web node.
+1. For GitLab HA only. Edit `/etc/gitlab/gitlab.rb` on every web node:
+
+   ```ruby
+   registry['notification_secret'] = '<replace_with_a_secret_token_generated_above>'
+   ```
 
-1. Reconfigure each node:
+1. Reconfigure each node you just updated:
 
    ```shell
    gitlab-ctl reconfigure
diff --git a/doc/administration/geo/replication/troubleshooting.md b/doc/administration/geo/replication/troubleshooting.md
index 9dcca8d0ac5..758d75ee294 100644
--- a/doc/administration/geo/replication/troubleshooting.md
+++ b/doc/administration/geo/replication/troubleshooting.md
@@ -120,7 +120,9 @@ The following environment variables are supported.
 #### Sync status Rake task
 
 Current sync information can be found manually by running this Rake task on any
-node running Rails (Puma, Sidekiq, or Geo Log Cursor) on the Geo **secondary** site:
+node running Rails (Puma, Sidekiq, or Geo Log Cursor) on the Geo **secondary** site.
+
+GitLab does **not** verify objects that are stored in Object Storage. If you are using Object Storage, you will see all of the "verified" checks showing 0 successes. This is expected and not a cause for concern.
 
 ```shell
 sudo gitlab-rake geo:status
diff --git a/doc/administration/geo/setup/index.md b/doc/administration/geo/setup/index.md
index 4dbd2ef6167..94df58cc9eb 100644
--- a/doc/administration/geo/setup/index.md
+++ b/doc/administration/geo/setup/index.md
@@ -30,11 +30,13 @@ a single-node Geo site or a multi-node Geo site.
 
 If both Geo sites are based on the [1K reference architecture](../../reference_architectures/1k_users.md):
 
-1. [Set up the database replication](database.md) (`primary (read-write) <-> secondary (read-only)` topology).
+1. Set up the database replication based on your choice of PostgreSQL instances (`primary (read-write) <-> secondary (read-only)` topology):
+   - [Using Omnibus PostgreSQL instances](database.md) .
+   - [Using external PostgreSQL instances](external_database.md)
 1. [Configure GitLab](../replication/configuration.md) to set the **primary** and **secondary** sites.
-1. Optional: [Configure Object storage](../../object_storage.md)
+1. Recommended: [Configure unified URLs](../secondary_proxy/index.md) to use a single, unified URL for all Geo sites.
+1. Optional: [Configure Object storage replication](../../object_storage.md)
 1. Optional: [Configure a secondary LDAP server](../../auth/ldap/index.md) for the **secondary** sites. See [notes on LDAP](../index.md#ldap).
-1. Optional: [Configure Geo secondary proxying](../secondary_proxy/index.md) to use a single, unified URL for all Geo sites. This step is recommended to accelerate most read requests while transparently proxying writes to the primary Geo site.
 1. Optional: [Configure Container Registry for the secondary site](../replication/container_registry.md).
 1. Follow the [Using a Geo Site](../replication/usage.md) guide.
 
diff --git a/doc/development/gitlab_shell/index.md b/doc/development/gitlab_shell/index.md
index 0663341f806..ef034761a1f 100644
--- a/doc/development/gitlab_shell/index.md
+++ b/doc/development/gitlab_shell/index.md
@@ -218,5 +218,5 @@ sequenceDiagram
 ## Related topics
 
 - [LICENSE](https://gitlab.com/gitlab-org/gitlab-shell/-/blob/main/LICENSE)
-- [PROCESS.md](https://gitlab.com/gitlab-org/gitlab-shell/-/blob/main/PROCESS.md)
+- [Processes](process.md)
 - [Using the GitLab Shell chart](https://docs.gitlab.com/charts/charts/gitlab/gitlab-shell/)
diff --git a/doc/raketasks/restore_gitlab.md b/doc/raketasks/restore_gitlab.md
index c7abc7ac562..b6e9824f9b4 100644
--- a/doc/raketasks/restore_gitlab.md
+++ b/doc/raketasks/restore_gitlab.md
@@ -14,7 +14,7 @@ information. Be sure to read and test the complete restore process at least
 once before attempting to perform it in a production environment.
 
 You can restore a backup only to _the exact same version and type (CE/EE)_ of
-GitLab that you created it on (for example CE 9.1.0).
+GitLab that you created it on (for example CE 15.1.4).
 
 If your backup is a different version than the current installation, you must
 [downgrade](../update/package/downgrade.md) or [upgrade](../update/package/index.md#upgrade-to-a-specific-version-using-the-official-repositories) your GitLab installation
diff --git a/doc/tutorials/left_sidebar/img/sidebar_bottom_v16_1.png b/doc/tutorials/left_sidebar/img/sidebar_bottom_v16_1.png
index 75e6f496c0c..dd2c7b82d40 100644
--- a/doc/tutorials/left_sidebar/img/sidebar_bottom_v16_1.png
+++ b/doc/tutorials/left_sidebar/img/sidebar_bottom_v16_1.png
diff --git a/doc/tutorials/left_sidebar/img/sidebar_middle_v16_1.png b/doc/tutorials/left_sidebar/img/sidebar_middle_v16_1.png
index 75fb1ae7ffe..67e89c2c0a4 100644
--- a/doc/tutorials/left_sidebar/img/sidebar_middle_v16_1.png
+++ b/doc/tutorials/left_sidebar/img/sidebar_middle_v16_1.png
diff --git a/doc/user/workspace/index.md b/doc/user/workspace/index.md
index 038b5e44af6..95174437703 100644
--- a/doc/user/workspace/index.md
+++ b/doc/user/workspace/index.md
@@ -154,6 +154,6 @@ If you already have running workspaces, an administrator must manually delete th
 ## Arbitrary user IDs
 
 You can provide your own container image, which can run as any Linux user ID. It's not possible for GitLab to predict the Linux user ID for a container image.
-GitLab uses the Linux root group ID permission to create, update, or delete files in the container. Depending on the container runtime used by the Kubernetes cluster, all containers might have a default group ID of `0`.
+GitLab uses the Linux root group ID permission to create, update, or delete files in a container. The container runtime used by the Kubernetes cluster must ensure all containers have a default Linux group ID of `0`.
 
 If you have a container image that does not support arbitrary user IDs, you cannot create, update, or delete files in a workspace. To create a container image that supports arbitrary user IDs, see the [OpenShift documentation](https://docs.openshift.com/container-platform/4.12/openshift_images/create-images.html#use-uid_create-images).