Add latest changes from gitlab-org/gitlab@16-7-stable-eev16.7.0-rc42

17 files changed, 262 insertions, 111 deletions

diff --git a/doc/update/background_migrations.md b/doc/update/background_migrations.md
index 5a4b19016f8..8f7e4cc7b1d 100644
--- a/doc/update/background_migrations.md
+++ b/doc/update/background_migrations.md
@@ -1,7 +1,7 @@
 ---
 stage: Data Stores
 group: Database
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
 # Background migrations and upgrades **(FREE SELF)**
@@ -67,8 +67,7 @@ Prerequisites:
 
 To check the status of batched background migrations:
 
-1. On the left sidebar, select **Search or go to**.
-1. Select **Admin Area**.
+1. On the left sidebar, at the bottom, select **Admin Area**.
 1. Select **Monitoring > Background Migrations**.
 1. Select **Queued** or **Finalizing** to see incomplete migrations,
    and **Failed** for failed migrations.
@@ -96,6 +95,15 @@ To query the database directly for the status of batched background migrations:
    WHERE status <> 3;
    ```
 
+Alternatively, you can wrap the query with `gitlab-psql -c "<QUERY>"` to check the status of
+batched background migrations:
+
+```shell
+gitlab-psql -c "SELECT job_class_name, table_name, column_name, job_arguments FROM batched_background_migrations WHERE status <> 3;"
+```
+
+If the query returns zero rows, all batched background migrations are complete.
+
 ### Enable or disable advanced features
 
 Batched background migrations provide feature flags that enable you to customize
@@ -217,8 +225,7 @@ Prerequisites:
 
 - You must have administrator access to the instance.
 
-1. On the left sidebar, select **Search or go to**.
-1. Select **Admin Area**.
+1. On the left sidebar, at the bottom, select **Admin Area**.
 1. Select **Monitoring > Background Migrations**.
 1. Select the **Failed** tab. This displays a list of failed batched background migrations.
 1. Select the failed **Migration** to see the migration parameters and the jobs that failed.
@@ -233,8 +240,7 @@ Prerequisites:
 
 - You must have administrator access to the instance.
 
-1. On the left sidebar, select **Search or go to**.
-1. Select **Admin Area**.
+1. On the left sidebar, at the bottom, select **Admin Area**.
 1. Select **Monitoring > Background Migrations**.
 1. Select the **Failed** tab. This displays a list of failed batched background migrations.
 1. Select a failed batched background migration to retry by clicking on the retry button (**{retry}**).
diff --git a/doc/update/deprecations.md b/doc/update/deprecations.md
index 333dad86086..cba85b1acd9 100644
--- a/doc/update/deprecations.md
+++ b/doc/update/deprecations.md
@@ -1,7 +1,7 @@
 ---
 stage: none
 group: none
-info: "See the Technical Writers assigned to Development Guidelines: https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments-to-development-guidelines"
+info: "See the Technical Writers assigned to Development Guidelines: https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments-to-development-guidelines"
 toc: false
 ---
 
@@ -69,7 +69,7 @@ The configuration arguments disabled for authentication tokens are:
 - `--run-untagged`
 - `--tag-list`
 
-This change is a breaking change. You should use an [authentication token](../ci/runners/register_runner.md) in the `gitlab-runner register` command instead.
+This change is a breaking change. You should use an [authentication token](../ci/runners/runners_scope.html) in the `gitlab-runner register` command instead.
 
 </div>
 
@@ -96,7 +96,7 @@ The configuration arguments disabled for authentication tokens are:
 - `--tag-list`
 - `--maintenance-note`
 
-This change is a breaking change. You should [create a runner in the UI](../ci/runners/register_runner.md) to add configurations, and use the authentication token in the `gitlab-runner register` command instead.
+This change is a breaking change. You should [create a runner in the UI](../ci/runners/runners_scope.html) to add configurations, and use the authentication token in the `gitlab-runner register` command instead.
 
 </div>
 
@@ -259,7 +259,7 @@ the aliasing for the `CiRunnerUpgradeStatusType` type will be removed.
 
 <div class="deprecation breaking-change" data-milestone="17.0">
 
-### Container Registry support for the Swift and OSS storage drivers
+### Container registry support for the Swift and OSS storage drivers
 
 <div class="deprecation-notes">
 - Announced in GitLab <span class="milestone">16.6</span>
@@ -317,6 +317,38 @@ In 16.3, the names of these settings were changed to clarify their meanings: the
 
 <div class="deprecation breaking-change" data-milestone="17.0">
 
+### Dependency Proxy: Access tokens to have additional scope checks
+
+<div class="deprecation-notes">
+- Announced in GitLab <span class="milestone">16.7</span>
+- Removal in GitLab <span class="milestone">17.0</span> ([breaking change](https://docs.gitlab.com/ee/update/terminology.html#breaking-change))
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/431386).
+</div>
+
+When using the Dependency Proxy for containers with a group access token or personal access token, `docker login` and `docker pull` requests with insufficient scopes for Dependency Proxy are not rejected.
+
+GitLab 17.0 adds checks for group or personal access tokens authenticating with the dependency proxy for containers. This is a breaking change, because tokens without the required scopes will fail.
+
+To help avoid being impacted by this breaking change, create new access tokens with the [required scopes](https://docs.gitlab.com/ee/user/packages/dependency_proxy/#authenticate-with-the-dependency-proxy), and update your workflow variables and scripts with those new tokens.
+
+</div>
+
+<div class="deprecation " data-milestone="17.0">
+
+### Deprecate GraphQL fields related to the temporary storage increase
+
+<div class="deprecation-notes">
+- Announced in GitLab <span class="milestone">16.7</span>
+- Removal in GitLab <span class="milestone">17.0</span>
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/385720).
+</div>
+
+The GraphQL fields, `isTemporaryStorageIncreaseEnabled` and `temporaryStorageIncreaseEndsOn`, have been deprecated. These GraphQL fields are related to the temporary storage increase project. The project has been cancelled and the fields were not used.
+
+</div>
+
+<div class="deprecation breaking-change" data-milestone="17.0">
+
 ### Deprecate Windows CMD in GitLab Runner
 
 <div class="deprecation-notes">
@@ -685,7 +717,7 @@ In GitLab 16.0 and later:
 
 <div class="deprecation breaking-change" data-milestone="17.0">
 
-### Internal Container Registry API tag deletion endpoint
+### Internal container registry API tag deletion endpoint
 
 <div class="deprecation-notes">
 - Announced in GitLab <span class="milestone">16.4</span>
@@ -695,7 +727,7 @@ In GitLab 16.0 and later:
 
 The [Docker Registry HTTP API V2 Spec](https://docs.docker.com/registry/spec/api/), later replaced by the [OCI Distribution Spec](https://github.com/opencontainers/distribution-spec/blob/main/spec.md) did not include a tag delete operation, and an unsafe and slow workaround (involving deleting manifests, not tags) had to be used to achieve the same end.
 
-Tag deletion is an important function, so we added a tag deletion operation to the GitLab Container Registry, extending the V2 API beyond the scope of the Docker and OCI distribution spec.
+Tag deletion is an important function, so we added a tag deletion operation to the GitLab container registry, extending the V2 API beyond the scope of the Docker and OCI distribution spec.
 
 Since then, the OCI Distribution Spec has had some updates and it now has a tag delete operation, using the [`DELETE /v2/<name>/manifests/<tag>` endpoint](https://github.com/opencontainers/distribution-spec/blob/main/spec.md#deleting-tags).
 
@@ -703,7 +735,7 @@ This leaves the container registry with two endpoints that provide the exact sam
 
 Support for the custom GitLab tag delete endpoint is deprecated in GitLab 16.4, and it will be removed in GitLab 17.0.
 
-This endpoint is used by the **internal** Container Registry application API, not the public [GitLab Container Registry API](https://docs.gitlab.com/ee/api/container_registry.html). No action should be required by the majority of container registry users. All the GitLab UI and API functionality related to tag deletions will remain intact as we transition to the new OCI-compliant endpoint.
+This endpoint is used by the **internal** container registry application API, not the public [GitLab container registry API](https://docs.gitlab.com/ee/api/container_registry.html). No action should be required by the majority of container registry users. All the GitLab UI and API functionality related to tag deletions will remain intact as we transition to the new OCI-compliant endpoint.
 
 If you do access the internal container registry API and use the original tag deletion endpoint, you must update to the new endpoint.
 
@@ -711,6 +743,20 @@ If you do access the internal container registry API and use the original tag de
 
 <div class="deprecation breaking-change" data-milestone="17.0">
 
+### JWT `/-/jwks` instance endpoint is deprecated
+
+<div class="deprecation-notes">
+- Announced in GitLab <span class="milestone">16.7</span>
+- Removal in GitLab <span class="milestone">17.0</span> ([breaking change](https://docs.gitlab.com/ee/update/terminology.html#breaking-change))
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/221031).
+</div>
+
+With the [deprecation of old JSON web token versions](https://docs.gitlab.com/ee/update/deprecations.html?removal_milestone=17.0#old-versions-of-json-web-tokens-are-deprecated) in GitLab 17.0, the associated `/-/jwks` endpoint which is an alias for `/oauth/discovery/keys` is no longer necessary and will be removed. Please replace any uses of `/-/jwks` with `/oauth/discovery/keys`, for example change `https://gitlab.example.com/-/jwks` to `https://gitlab.example.com/oauth/discovery/keys`.
+
+</div>
+
+<div class="deprecation breaking-change" data-milestone="17.0">
+
 ### Legacy Geo Prometheus metrics
 
 <div class="deprecation-notes">
@@ -738,6 +784,23 @@ The table below lists the deprecated metrics and their respective replacements.
 
 <div class="deprecation breaking-change" data-milestone="17.0">
 
+### List repository directories Rake task
+
+<div class="deprecation-notes">
+- Announced in GitLab <span class="milestone">16.7</span>
+- Removal in GitLab <span class="milestone">17.0</span> ([breaking change](https://docs.gitlab.com/ee/update/terminology.html#breaking-change))
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/384361).
+</div>
+
+The `gitlab-rake gitlab:list_repos` Rake task does not work and will be removed in GitLab 17.0.
+If you're migrating GitLab, use
+[backup and restore](https://docs.gitlab.com/ee/administration/operations/moving_repositories.html#recommended-approach-in-all-cases)
+instead.
+
+</div>
+
+<div class="deprecation breaking-change" data-milestone="17.0">
+
 ### Maintainer role providing the ability to change Package settings using GraphQL API
 
 <div class="deprecation-notes">
@@ -936,7 +999,7 @@ The configuration arguments disabled for authentication tokens are:
 - `--tag-list`
 - `--maintenance-note`
 
-This change is a breaking change. You should [create a runner in the UI](../ci/runners/register_runner.md) to add configurations, and use the authentication token in the `gitlab-runner register` command instead.
+This change is a breaking change. You should [create a runner in the UI](../ci/runners/runners_scope.html) to add configurations, and use the authentication token in the `gitlab-runner register` command instead.
 
 </div>
 
@@ -1322,6 +1385,41 @@ To prepare for GitLab 15.8 and later, you should:
 </div>
 </div>
 
+<div class="milestone-wrapper" data-milestone="16.7">
+
+## GitLab 16.7
+
+<div class="deprecation breaking-change" data-milestone="16.7">
+
+### Shimo integration
+
+<div class="deprecation-notes">
+- Announced in GitLab <span class="milestone">15.7</span>
+- Removal in GitLab <span class="milestone">16.7</span> ([breaking change](https://docs.gitlab.com/ee/update/terminology.html#breaking-change))
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/377824).
+</div>
+
+The [Shimo Workspace integration](https://docs.gitlab.com/ee/user/project/integrations/shimo.html) has been deprecated
+and will be moved to the JiHu GitLab codebase.
+
+</div>
+
+<div class="deprecation breaking-change" data-milestone="16.7">
+
+### `user_email_lookup_limit` API field
+
+<div class="deprecation-notes">
+- Announced in GitLab <span class="milestone">14.9</span>
+- Removal in GitLab <span class="milestone">16.7</span> ([breaking change](https://docs.gitlab.com/ee/update/terminology.html#breaking-change))
+</div>
+
+The `user_email_lookup_limit` [API field](https://docs.gitlab.com/ee/api/settings.html) is deprecated in GitLab 14.9 and removed in GitLab 16.7. Until the feature is removed, `user_email_lookup_limit` is aliased to `search_rate_limit` and existing workflows still work.
+
+Any API calls to change the rate limits for `user_email_lookup_limit` must use `search_rate_limit` instead.
+
+</div>
+</div>
+
 <div class="milestone-wrapper" data-milestone="16.6">
 
 ## GitLab 16.6
@@ -1682,29 +1780,29 @@ config file locations instead, for example `config/redis.cache.yml` or
 
 <div class="deprecation breaking-change" data-milestone="16.0">
 
-### Container Registry pull-through cache
+### Container Scanning variables that reference Docker
 
 <div class="deprecation-notes">
-- Announced in GitLab <span class="milestone">15.8</span>
+- Announced in GitLab <span class="milestone">15.4</span>
 - Removal in GitLab <span class="milestone">16.0</span> ([breaking change](https://docs.gitlab.com/ee/update/terminology.html#breaking-change))
-- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/container-registry/-/issues/842).
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/371840).
 </div>
 
-The Container Registry [pull-through cache](https://docs.docker.com/registry/recipes/mirror/) is deprecated in GitLab 15.8 and will be removed in GitLab 16.0. The pull-through cache is part of the upstream [Docker Distribution project](https://github.com/distribution/distribution). However, we are removing the pull-through cache in favor of the GitLab Dependency Proxy, which allows you to proxy and cache container images from Docker Hub. Removing the pull-through cache allows us also to remove the upstream client code without sacrificing functionality.
+All Container Scanning variables that are prefixed by `DOCKER_` in variable name are deprecated. This includes the `DOCKER_IMAGE`, `DOCKER_PASSWORD`, `DOCKER_USER`, and `DOCKERFILE_PATH` variables. Support for these variables will be removed in the GitLab 16.0 release. Use the [new variable names](https://docs.gitlab.com/ee/user/application_security/container_scanning/#available-cicd-variables) `CS_IMAGE`, `CS_REGISTRY_PASSWORD`, `CS_REGISTRY_USER`, and `CS_DOCKERFILE_PATH` in place of the deprecated names.
 
 </div>
 
 <div class="deprecation breaking-change" data-milestone="16.0">
 
-### Container Scanning variables that reference Docker
+### Container registry pull-through cache
 
 <div class="deprecation-notes">
-- Announced in GitLab <span class="milestone">15.4</span>
+- Announced in GitLab <span class="milestone">15.8</span>
 - Removal in GitLab <span class="milestone">16.0</span> ([breaking change](https://docs.gitlab.com/ee/update/terminology.html#breaking-change))
-- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/371840).
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/container-registry/-/issues/842).
 </div>
 
-All Container Scanning variables that are prefixed by `DOCKER_` in variable name are deprecated. This includes the `DOCKER_IMAGE`, `DOCKER_PASSWORD`, `DOCKER_USER`, and `DOCKERFILE_PATH` variables. Support for these variables will be removed in the GitLab 16.0 release. Use the [new variable names](https://docs.gitlab.com/ee/user/application_security/container_scanning/#available-cicd-variables) `CS_IMAGE`, `CS_REGISTRY_PASSWORD`, `CS_REGISTRY_USER`, and `CS_DOCKERFILE_PATH` in place of the deprecated names.
+The container registry [pull-through cache](https://docs.docker.com/registry/recipes/mirror/) is deprecated in GitLab 15.8 and will be removed in GitLab 16.0. The pull-through cache is part of the upstream [Docker Distribution project](https://github.com/distribution/distribution). However, we are removing the pull-through cache in favor of the GitLab Dependency Proxy, which allows you to proxy and cache container images from Docker Hub. Removing the pull-through cache allows us also to remove the upstream client code without sacrificing functionality.
 
 </div>
 
@@ -2617,21 +2715,6 @@ For more information, refer to [security report validation](https://docs.gitlab.
 
 <div class="deprecation breaking-change" data-milestone="16.0">
 
-### Shimo integration
-
-<div class="deprecation-notes">
-- Announced in GitLab <span class="milestone">15.7</span>
-- Removal in GitLab <span class="milestone">16.0</span> ([breaking change](https://docs.gitlab.com/ee/update/terminology.html#breaking-change))
-- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/377824).
-</div>
-
-The [Shimo Workspace integration](https://docs.gitlab.com/ee/user/project/integrations/shimo.html) has been deprecated
-and will be moved to the JiHu GitLab codebase.
-
-</div>
-
-<div class="deprecation breaking-change" data-milestone="16.0">
-
 ### Starboard directive in the config for the GitLab Agent for Kubernetes
 
 <div class="deprecation-notes">
@@ -2820,13 +2903,13 @@ You can use the vulnerabilityFindingDismiss GraphQL mutation to set the status o
 
 Using third-party container registries with GitLab as an auth endpoint is deprecated in GitLab 15.8 and the [end of support](https://docs.gitlab.com/ee/development/deprecation_guidelines/#terminology) is scheduled for GitLab 16.0. This impacts self-managed customers that have connected their external registry to the GitLab user interface to find, view, and delete container images.
 
-Supporting both GitLab's Container Registry as well as third-party container registries is challenging for maintenance, code quality, and backward compatibility. This hinders our ability to stay [efficient](https://about.gitlab.com/handbook/values/#efficiency). As a result we will not support this functionality moving forward.
+Supporting both GitLab's container registry as well as third-party container registries is challenging for maintenance, code quality, and backward compatibility. This hinders our ability to stay [efficient](https://about.gitlab.com/handbook/values/#efficiency). As a result we will not support this functionality moving forward.
 
 This change will not impact your ability to pull and push container images to external registries using pipelines.
 
-Since we released the new [GitLab Container Registry](https://gitlab.com/groups/gitlab-org/-/epics/5523) version for GitLab.com, we've started to implement additional features that are not available in third-party container registries. These new features have allowed us to achieve significant performance improvements, such as [cleanup policies](https://gitlab.com/groups/gitlab-org/-/epics/8379). We are focusing on delivering [new features](https://gitlab.com/groups/gitlab-org/-/epics/5136), most of which will require functionalities only available on the GitLab Container Registry. This deprecation allows us to reduce fragmentation and user frustration in the long term by focusing on delivering a more robust integrated registry experience and feature set.
+Since we released the new [GitLab container registry](https://gitlab.com/groups/gitlab-org/-/epics/5523) version for GitLab.com, we've started to implement additional features that are not available in third-party container registries. These new features have allowed us to achieve significant performance improvements, such as [cleanup policies](https://gitlab.com/groups/gitlab-org/-/epics/8379). We are focusing on delivering [new features](https://gitlab.com/groups/gitlab-org/-/epics/5136), most of which will require functionalities only available on the GitLab container registry. This deprecation allows us to reduce fragmentation and user frustration in the long term by focusing on delivering a more robust integrated registry experience and feature set.
 
-Moving forward, we'll continue to invest in developing and releasing new features that will only be available in the GitLab Container Registry.
+Moving forward, we'll continue to invest in developing and releasing new features that will only be available in the GitLab container registry.
 
 </div>
 
@@ -3734,12 +3817,12 @@ an inline argument expression).
 - Removal in GitLab <span class="milestone">15.0</span> ([breaking change](https://docs.gitlab.com/ee/update/terminology.html#breaking-change))
 </div>
 
-The GitLab Package stage offers a Package Registry, Container Registry, and Dependency Proxy to help you manage all of your dependencies using GitLab. Each of these product categories has a variety of settings that can be adjusted using the API.
+The GitLab Package stage offers a Package Registry, container registry, and Dependency Proxy to help you manage all of your dependencies using GitLab. Each of these product categories has a variety of settings that can be adjusted using the API.
 
 The permissions model for GraphQL is being updated. After 15.0, users with the Guest, Reporter, and Developer role can no longer update these settings:
 
 - [Package Registry settings](https://docs.gitlab.com/ee/api/graphql/reference/#packagesettings)
-- [Container Registry cleanup policy](https://docs.gitlab.com/ee/api/graphql/reference/#containerexpirationpolicy)
+- [Container registry cleanup policy](https://docs.gitlab.com/ee/api/graphql/reference/#containerexpirationpolicy)
 - [Dependency Proxy time-to-live policy](https://docs.gitlab.com/ee/api/graphql/reference/#dependencyproxyimagettlgrouppolicy)
 - [Enabling the Dependency Proxy for your group](https://docs.gitlab.com/ee/api/graphql/reference/#dependencyproxysetting)
 
@@ -4335,7 +4418,7 @@ Tracing in GitLab is an integration with Jaeger, an open-source end-to-end distr
 
 <div class="deprecation breaking-change" data-milestone="15.0">
 
-### Update to the Container Registry group-level API
+### Update to the container registry group-level API
 
 <div class="deprecation-notes">
 - Announced in GitLab <span class="milestone">14.5</span>
@@ -4343,7 +4426,7 @@ Tracing in GitLab is an integration with Jaeger, an open-source end-to-end distr
 - To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/336912).
 </div>
 
-In milestone 15.0, support for the `tags` and `tags_count` parameters will be removed from the Container Registry API that [gets registry repositories from a group](../api/container_registry.md#within-a-group).
+In milestone 15.0, support for the `tags` and `tags_count` parameters will be removed from the container registry API that [gets registry repositories from a group](../api/container_registry.md#within-a-group).
 
 The `GET /groups/:id/registry/repositories` endpoint will remain, but won't return any info about tags. To get the info about tags, you can use the existing `GET /registry/repositories/:id` endpoint, which will continue to support the `tags` and `tag_count` options as it does today. The latter must be called once per image repository.
 
@@ -4558,33 +4641,18 @@ If you have explicitly excluded bundler-audit using DS_EXCLUDED_ANALYZERS you wi
 
 <div class="deprecation breaking-change" data-milestone="15.0">
 
-### htpasswd Authentication for the Container Registry
+### htpasswd Authentication for the container registry
 
 <div class="deprecation-notes">
 - Announced in GitLab <span class="milestone">14.9</span>
 - Removal in GitLab <span class="milestone">15.0</span> ([breaking change](https://docs.gitlab.com/ee/update/terminology.html#breaking-change))
 </div>
 
-The Container Registry supports [authentication](https://gitlab.com/gitlab-org/container-registry/-/blob/master/docs/configuration.md#auth) with `htpasswd`. It relies on an [Apache `htpasswd` file](https://httpd.apache.org/docs/2.4/programs/htpasswd.html), with passwords hashed using `bcrypt`.
+The container registry supports [authentication](https://gitlab.com/gitlab-org/container-registry/-/blob/master/docs/configuration.md#auth) with `htpasswd`. It relies on an [Apache `htpasswd` file](https://httpd.apache.org/docs/2.4/programs/htpasswd.html), with passwords hashed using `bcrypt`.
 
 Since it isn't used in the context of GitLab (the product), `htpasswd` authentication will be deprecated in GitLab 14.9 and removed in GitLab 15.0.
 
 </div>
-
-<div class="deprecation breaking-change" data-milestone="15.0">
-
-### user_email_lookup_limit API field
-
-<div class="deprecation-notes">
-- Announced in GitLab <span class="milestone">14.9</span>
-- Removal in GitLab <span class="milestone">15.0</span> ([breaking change](https://docs.gitlab.com/ee/update/terminology.html#breaking-change))
-</div>
-
-The `user_email_lookup_limit` [API field](https://docs.gitlab.com/ee/api/settings.html) is deprecated and will be removed in GitLab 15.0. Until GitLab 15.0, `user_email_lookup_limit` is aliased to `search_rate_limit` and existing workflows will continue to work.
-
-Any API calls attempting to change the rate limits for `user_email_lookup_limit` should use `search_rate_limit` instead.
-
-</div>
 </div>
 
 <div class="milestone-wrapper" data-milestone="14.10">
diff --git a/doc/update/index.md b/doc/update/index.md
index f7e3a0e3403..c0a6b64a1ac 100644
--- a/doc/update/index.md
+++ b/doc/update/index.md
@@ -1,7 +1,7 @@
 ---
 stage: Systems
 group: Distribution
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
 # Upgrading GitLab **(FREE SELF)**
@@ -195,7 +195,7 @@ When upgrading:
    - GitLab 16: [`16.0.x`](versions/gitlab_16_changes.md#1600) (only
      instances with [lots of users](versions/gitlab_16_changes.md#long-running-user-type-data-change) or
      [large pipeline variables history](versions/gitlab_16_changes.md#1610)) >
-     [`16.1`](versions/gitlab_16_changes.md#1610)(instances with NPM packages in their Package Registry) >
+     [`16.1`](versions/gitlab_16_changes.md#1610) (instances with NPM packages in their package registry) >
      [`16.2.x`](versions/gitlab_16_changes.md#1620) (only instances with [large pipeline variables history](versions/gitlab_16_changes.md#1630)) >
      [`16.3`](versions/gitlab_16_changes.md#1630) > [latest `16.Y.Z`](https://gitlab.com/gitlab-org/gitlab/-/releases).
 
@@ -218,7 +218,7 @@ upgrade stops allow required background migrations to finish.
 
 During GitLab 16.x, we are scheduling required upgrade stops beforehand so users can better plan out appropriate upgrade stops and downtime when necessary.
 
-The first scheduled required upgrade stop has been announced for 16.3.x. When planning upgrades, please take this into account.
+The first scheduled required upgrade stop has been announced for 16.3.x. When planning upgrades, take this into account.
 
 ### Earlier GitLab versions
 
diff --git a/doc/update/package/convert_to_ee.md b/doc/update/package/convert_to_ee.md
index 31de896349c..5a76c85e915 100644
--- a/doc/update/package/convert_to_ee.md
+++ b/doc/update/package/convert_to_ee.md
@@ -1,7 +1,7 @@
 ---
 stage: Systems
 group: Distribution
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
 # Convert Community Edition to Enterprise Edition **(FREE SELF)**
diff --git a/doc/update/package/downgrade.md b/doc/update/package/downgrade.md
index 0e01a1bfcd8..ee2ff4ea4bf 100644
--- a/doc/update/package/downgrade.md
+++ b/doc/update/package/downgrade.md
@@ -1,7 +1,7 @@
 ---
 stage: Systems
 group: Distribution
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
 # Downgrade **(FREE SELF)**
diff --git a/doc/update/package/index.md b/doc/update/package/index.md
index 19d308bce6b..93967a30660 100644
--- a/doc/update/package/index.md
+++ b/doc/update/package/index.md
@@ -1,7 +1,7 @@
 ---
 stage: Systems
 group: Distribution
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
 # Upgrade GitLab by using the GitLab package **(FREE SELF)**
diff --git a/doc/update/patch_versions.md b/doc/update/patch_versions.md
index e626764aee5..96a2654c579 100644
--- a/doc/update/patch_versions.md
+++ b/doc/update/patch_versions.md
@@ -1,7 +1,7 @@
 ---
 stage: Systems
 group: Distribution
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
 # Universal update guide for patch versions for self-compiled installations **(FREE SELF)**
@@ -10,7 +10,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 Make sure you view [this update guide](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/update/patch_versions.md) from the tag (version) of GitLab you would like to install.
 In most cases this should be the highest numbered production tag (without `rc` in it).
-You can select the tag in the version dropdown list in the upper-left corner of GitLab (below the menu bar).
+You can select the tag in the version dropdown list in the upper-left corner of GitLab.
 
 ### 0. Backup
 
diff --git a/doc/update/plan_your_upgrade.md b/doc/update/plan_your_upgrade.md
index 25578dbef59..00ee87ac96c 100644
--- a/doc/update/plan_your_upgrade.md
+++ b/doc/update/plan_your_upgrade.md
@@ -1,7 +1,7 @@
 ---
 stage: Systems
 group: Distribution
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
 # Create a GitLab upgrade plan **(FREE SELF)**
@@ -118,8 +118,7 @@ to your instance and then upgrade it for any relevant features you're using.
   [turning on maintenance mode](../administration/maintenance_mode/index.md) during the
   upgrade.
 - About PostgreSQL:
-  1. On the left sidebar, select **Search or go to**.
-  1. Select **Admin Area**.
+  1. On the left sidebar, at the bottom, select **Admin Area**..
   1. Look for the version of PostgreSQL you are using.
     If [a PostgreSQL upgrade is needed](../administration/package_information/postgresql_versions.md),
     account for the relevant
diff --git a/doc/update/removals.md b/doc/update/removals.md
deleted file mode 100644
index 56f8b34fd27..00000000000
--- a/doc/update/removals.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-redirect_to: 'deprecations.md'
-remove_date: '2023-09-28'
----
-
-This document was moved to [another location](deprecations.md).
-
-<!-- This redirect file can be deleted after <2023-09-28>. -->
-<!-- Redirects that point to other docs in the same project expire in three months. -->
-<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. -->
-<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->
diff --git a/doc/update/terminology.md b/doc/update/terminology.md
index 6babbdbc991..56d5b13461a 100644
--- a/doc/update/terminology.md
+++ b/doc/update/terminology.md
@@ -1,7 +1,7 @@
 ---
 stage: none
 group: unassigned
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
 # Deprecation terms
diff --git a/doc/update/upgrading_from_ce_to_ee.md b/doc/update/upgrading_from_ce_to_ee.md
index 6dabc078119..ad18c8cf818 100644
--- a/doc/update/upgrading_from_ce_to_ee.md
+++ b/doc/update/upgrading_from_ce_to_ee.md
@@ -1,7 +1,7 @@
 ---
 stage: Systems
 group: Distribution
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
 # Upgrading from Community Edition to Enterprise Edition for self-compiled installations **(FREE SELF)**
diff --git a/doc/update/upgrading_from_source.md b/doc/update/upgrading_from_source.md
index db735ef49a4..d705c43dc86 100644
--- a/doc/update/upgrading_from_source.md
+++ b/doc/update/upgrading_from_source.md
@@ -1,7 +1,7 @@
 ---
 stage: Systems
 group: Distribution
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
 # Upgrading self-compiled installations **(FREE SELF)**
@@ -61,7 +61,7 @@ sudo service gitlab stop
 
 ### 3. Update Ruby
 
-From GitLab 15.10, we only support Ruby 3.0.x and dropped support for Ruby 2.7. Be sure to upgrade if necessary.
+From GitLab 16.7, we only support Ruby 3.1.x and dropped support for Ruby 3.0. Be sure to upgrade if necessary.
 You can check which version you are running with `ruby -v`.
 
 [Install Ruby](https://www.ruby-lang.org/en/documentation/installation/).
diff --git a/doc/update/versions/gitlab_14_changes.md b/doc/update/versions/gitlab_14_changes.md
index de5e7f37835..3244e63df2d 100644
--- a/doc/update/versions/gitlab_14_changes.md
+++ b/doc/update/versions/gitlab_14_changes.md
@@ -1,7 +1,7 @@
 ---
 stage: Systems
 group: Distribution
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
 # GitLab 14 changes **(FREE SELF)**
@@ -565,7 +565,7 @@ that may remain stuck permanently in a **pending** state when the instance lacks
   For information on how to fix this, see
   [Troubleshooting - Failed syncs with GitLab-managed object storage replication](../../administration/geo/replication/troubleshooting.md#failed-syncs-with-gitlab-managed-object-storage-replication).
 
-- We found an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/336013) where the Container Registry replication
+- 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 site. 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.
 
@@ -598,7 +598,7 @@ that may remain stuck permanently in a **pending** state when the instance lacks
    end
    ```
 
-  If you are running a version prior to 14.1 and are using Geo and multi-arch containers in your Container Registry,
+  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](../../administration/geo/replication/upgrading_the_geo_sites.md) to at least GitLab 14.1.
 
 ## 14.2.0
@@ -666,7 +666,7 @@ that may remain stuck permanently in a **pending** state when the instance lacks
   For information on how to fix this, see
   [Troubleshooting - Failed syncs with GitLab-managed object storage replication](../../administration/geo/replication/troubleshooting.md#failed-syncs-with-gitlab-managed-object-storage-replication).
 
-- We found an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/336013) where the Container Registry replication
+- 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 site. 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.
 
@@ -699,7 +699,7 @@ that may remain stuck permanently in a **pending** state when the instance lacks
    end
    ```
 
-  If you are running a version prior to 14.1 and are using Geo and multi-arch containers in your Container Registry,
+  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](../../administration/geo/replication/upgrading_the_geo_sites.md) to at least GitLab 14.1.
 
 ## 14.1.0
@@ -733,7 +733,7 @@ that may remain stuck permanently in a **pending** state when the instance lacks
 
 ### Geo installations **(PREMIUM SELF)**
 
-- We found an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/336013) where the Container Registry replication
+- 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 site. 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.
 
@@ -766,7 +766,7 @@ that may remain stuck permanently in a **pending** state when the instance lacks
    end
    ```
 
-  If you are running a version prior to 14.1 and are using Geo and multi-arch containers in your Container Registry,
+  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](../../administration/geo/replication/upgrading_the_geo_sites.md) to at least GitLab 14.1.
 - We found an issue where [Primary sites cannot be removed from the UI](https://gitlab.com/gitlab-org/gitlab/-/issues/338231).
 
diff --git a/doc/update/versions/gitlab_15_changes.md b/doc/update/versions/gitlab_15_changes.md
index bd5efef8f1b..df00ca1b46c 100644
--- a/doc/update/versions/gitlab_15_changes.md
+++ b/doc/update/versions/gitlab_15_changes.md
@@ -1,7 +1,7 @@
 ---
 stage: Systems
 group: Distribution
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
 # GitLab 15 changes **(FREE SELF)**
diff --git a/doc/update/versions/gitlab_16_changes.md b/doc/update/versions/gitlab_16_changes.md
index 836f5d188c5..57f613dd073 100644
--- a/doc/update/versions/gitlab_16_changes.md
+++ b/doc/update/versions/gitlab_16_changes.md
@@ -1,7 +1,7 @@
 ---
 stage: Systems
 group: Distribution
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
 # GitLab 16 changes **(FREE SELF)**
@@ -16,6 +16,7 @@ For more information about upgrading GitLab Helm Chart, see [the release notes f
 
 ## Issues to be aware of when upgrading from 15.11
 
+- [PostgreSQL 12 is not supported starting from GitLab 16](../../update/deprecations.md#postgresql-12-deprecated). Upgrade PostgreSQL to at least version 13.6 before upgrading to GitLab 16.0 or later.
 - Some GitLab installations must upgrade to GitLab 16.0 before upgrading to any other version. For more information, see
   [Long-running user type data change](#long-running-user-type-data-change).
 - Other installations can skip 16.0, 16.1, and 16.2 as the first required stop on the upgrade path is 16.3. Review the notes for those intermediate
@@ -30,9 +31,57 @@ For more information about upgrading GitLab Helm Chart, see [the release notes f
   - [Praefect configuration structure change](#praefect-configuration-structure-change).
   - [Gitaly configuration structure change](#gitaly-configuration-structure-change).
 
+## 16.7.0
+
+### Linux package installations
+
+Specific information applies to Linux package installations:
+
+- As of GitLab 16.7, PostgreSQL 14 is the default version installed with the Linux package.
+  During a package upgrade, the database isn't upgraded to PostgreSQL 14.
+  If you want to upgrade to PostgreSQL 14, [you must do it manually](https://docs.gitlab.com/omnibus/settings/database.html#upgrade-packaged-postgresql-server).
+
+  PostgreSQL 14 isn't supported on Geo deployments and is [planned](https://gitlab.com/groups/gitlab-org/-/epics/9065)
+  for future releases.
+
+  If you want to use PostgreSQL 13, you must set `postgresql['version'] = 13` in `/etc/gitlab/gitlab.rb`.
+
+## 16.6.0
+
+- Old [CI Environment destroy jobs may be spawned](https://gitlab.com/gitlab-org/gitlab/-/issues/433264#) after upgrading to GitLab 16.6.
+
 ## 16.5.0
 
 - Git 2.42.0 and later is required by Gitaly. For self-compiled installations, you should use the [Git version provided by Gitaly](../../install/installation.md#git).
+- A regression may sometimes cause an [HTTP 500 error when navigating a group](https://gitlab.com/gitlab-org/gitlab/-/issues/431659). Upgrading to GitLab 16.6 or later resolves the issue.
+- A regression may cause [Unselected Advanced Search facets to not load](https://gitlab.com/gitlab-org/gitlab/-/issues/428246). Upgrading to 16.6 or later resolves the issue.
+
+### Linux package installations
+
+- SSH clone URLs can be customized by setting `gitlab_rails['gitlab_ssh_host']`
+  in `/etc/gitlab/gitlab.rb`. This setting must now be a
+  [valid hostname](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/132238).
+  Previously, it could be an arbitrary string that was used to show a
+  custom hostname and port in the repository clone URL.
+
+  For example, prior to GitLab 16.5, the following setting worked:
+
+  ```ruby
+  gitlab_rails['gitlab_ssh_host'] = "gitlab.example.com:2222"
+  ```
+
+  Starting with GitLab 16.5, the hostname and port must be specified separately:
+
+  ```ruby
+  gitlab_rails['gitlab_ssh_host'] = "gitlab.example.com"
+  gitlab_rails['gitlab_shell_ssh_port'] = 2222
+  ```
+
+  After you change the setting, make sure to reconfigure GitLab:
+
+  ```shell
+  sudo gitlab-ctl reconfigure
+  ```
 
 ### Geo installations
 
@@ -58,7 +107,7 @@ Specific information applies to installations using Geo:
 
   For more information, see [issue 429617](https://gitlab.com/gitlab-org/gitlab/-/issues/429617).
 
-- [Object storage verification](https://about.gitlab.com/releases/2023/09/22/gitlab-16-4-released/#geo-verifies-object-storage) was added in GitLab 16.4. Due to an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/429242) some Geo installations are reporting high memory usage which can lead to the GitLab application on the primary becoming unresponsive. 
+- [Object storage verification](https://about.gitlab.com/releases/2023/09/22/gitlab-16-4-released/#geo-verifies-object-storage) was added in GitLab 16.4. Due to an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/429242) some Geo installations are reporting high memory usage which can lead to the GitLab application on the primary becoming unresponsive.
 
   Your installation may be impacted if you have configured it to use [object storage](../../administration/object_storage.md) and have enabled [GitLab-managed object storage replication](../../administration/geo/replication/object_storage.md#enabling-gitlab-managed-object-storage-replication)
 
@@ -70,11 +119,23 @@ Specific information applies to installations using Geo:
   ```
 
   **Affected releases**:
- 
+
+  | Affected minor releases | Affected patch releases | Fixed in |
+  | ----------------------- | ----------------------- | -------- |
+  | 16.4                    | 16.4.0 - 16.4.2         | 16.4.3   |
+  | 16.5                    | 16.5.0 - 16.5.1         | 16.5.2   |
+
+- After [Group Wiki](../../user/project/wiki/group.md) verification was added in GitLab 16.3, missing Group Wiki repositories are being incorrectly flagged as failing verification. This issue is not a result of an actual replication/verification failure but an invalid internal state for these missing repositories inside Geo and results in errors in the logs and the verification progress reporting a failed state for these Group Wiki repositories.
+
+  See details of the problem and workaround in issue [#426571](https://gitlab.com/gitlab-org/gitlab/-/issues/426571)
+
+  **Affected releases**:
+
   | Affected minor releases | Affected patch releases | Fixed in |
   | ------ | ------ | ------ |
+  | 16.3   | All    | None   |
   | 16.4   | All    | None   |
-  | 16.5   | All    | None   |
+  | 16.5   | 16.5.0 - 16.5.1    | 16.5.2   |
 
 ## 16.4.0
 
@@ -119,7 +180,7 @@ Specific information applies to installations using Geo:
 
   To find out if a push rule belongs to a project, group, or instance, run this script
   in the [Rails console](../../administration/operations/rails_console.md#starting-a-rails-console-session):
-  
+
   ```ruby
   # replace `delete_branch_regex` with a name of the field used in constraint
   long_rules = PushRule.where("length(delete_branch_regex) > 511")
@@ -176,7 +237,7 @@ Specific information applies to installations using Geo:
 
   For more information, see [issue 429617](https://gitlab.com/gitlab-org/gitlab/-/issues/429617).
 
-- [Object storage verification](https://about.gitlab.com/releases/2023/09/22/gitlab-16-4-released/#geo-verifies-object-storage) was added in GitLab 16.4. Due to an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/429242) some Geo installations are reporting high memory usage which can lead to the GitLab application on the primary becoming unresponsive. 
+- [Object storage verification](https://about.gitlab.com/releases/2023/09/22/gitlab-16-4-released/#geo-verifies-object-storage) was added in GitLab 16.4. Due to an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/429242) some Geo installations are reporting high memory usage which can lead to the GitLab application on the primary becoming unresponsive.
 
   Your installation may be impacted if you have configured it to use [object storage](../../administration/object_storage.md) and have enabled [GitLab-managed object storage replication](../../administration/geo/replication/object_storage.md#enabling-gitlab-managed-object-storage-replication)
 
@@ -188,11 +249,11 @@ Specific information applies to installations using Geo:
   ```
 
   **Affected releases**:
- 
+
   | Affected minor releases | Affected patch releases | Fixed in |
-  | ------ | ------ | ------ |
-  | 16.4   | All    | None   |
-  | 16.5   | All    | None   |
+  | ----------------------- | ----------------------- | -------- |
+  | 16.4                    | 16.4.0 - 16.4.2         | 16.4.3   |
+  | 16.5                    | 16.5.0 - 16.5.1         | 16.5.2   |
 
 - An [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/419370) with sync states getting stuck in pending state results in replication being stuck indefinitely for impacted items leading to risk of data loss in the event of a failover. This mostly impact repository syncs but can also can also affect container registry syncs. You are advised to upgrade to a fixed version to avoid risk of data loss.
 
@@ -203,6 +264,18 @@ Specific information applies to installations using Geo:
   | 16.3   | 16.3.0 - 16.3.5    | 16.3.6   |
   | 16.4   | 16.4.0 - 16.4.1    | 16.4.2   |
 
+- After [Group Wiki](../../user/project/wiki/group.md) verification was added in GitLab 16.3, missing Group Wiki repositories are being incorrectly flagged as failing verification. This issue is not a result of an actual replication/verification failure but an invalid internal state for these missing repositories inside Geo and results in errors in the logs and the verification progress reporting a failed state for these Group Wiki repositories.
+
+  See details of the problem and workaround in issue [#426571](https://gitlab.com/gitlab-org/gitlab/-/issues/426571)
+
+  **Affected releases**:
+
+  | Affected minor releases | Affected patch releases | Fixed in |
+  | ------ | ------ | ------ |
+  | 16.3   | All    | None   |
+  | 16.4   | All    | None   |
+  | 16.5   | 16.5.0 - 16.5.1    | 16.5.2   |
+
 ## 16.3.0
 
 - **Update to GitLab 16.3.5 or later**. This avoids [issue 425971](https://gitlab.com/gitlab-org/gitlab/-/issues/425971) that causes an excessive use of database disk space for GitLab 16.3.3 and 16.3.4.
@@ -212,8 +285,8 @@ Specific information applies to installations using Geo:
 - For Go applications, [`crypto/tls`: verifying certificate chains containing large RSA keys is slow (CVE-2023-29409)](https://github.com/golang/go/issues/61460)
   introduced a hard limit of 8192 bits for RSA keys. In the context of Go applications at GitLab, RSA keys can be configured for:
 
-  - [Container Registry](../../administration/packages/container_registry.md)
-  - [Gitaly](../../administration/gitaly/configure_gitaly.md#enable-tls-support)
+  - [Container registry](../../administration/packages/container_registry.md)
+  - [Gitaly](../../administration/gitaly/tls_support.md)
   - [GitLab Pages](../../user/project/pages/custom_domains_ssl_tls_certification/index.md#manual-addition-of-ssltls-certificates)
   - [Workhorse](../../development/workhorse/configuration.md#tls-support)
 
@@ -299,6 +372,18 @@ Specific information applies to installations using Geo:
   | 16.3   | 16.3.0 - 16.3.5    | 16.3.6   |
   | 16.4   | 16.4.0 - 16.4.1    | 16.4.2   |
 
+- After [Group Wiki](../../user/project/wiki/group.md) verification was added in GitLab 16.3, missing Group Wiki repositories are being incorrectly flagged as failing verification. This issue is not a result of an actual replication/verification failure but an invalid internal state for these missing repositories inside Geo and results in errors in the logs and the verification progress reporting a failed state for these Group Wiki repositories.
+
+  See details of the problem and workaround in issue [#426571](https://gitlab.com/gitlab-org/gitlab/-/issues/426571)
+
+  **Affected releases**:
+
+  | Affected minor releases | Affected patch releases | Fixed in |
+  | ------ | ------ | ------ |
+  | 16.3   | All    | None   |
+  | 16.4   | All    | None   |
+  | 16.5   | 16.5.0 - 16.5.1    | 16.5.2   |
+
 ## 16.2.0
 
 - Legacy LDAP configuration settings may cause
@@ -471,7 +556,11 @@ by this issue.
   [throw errors on startup](../../install/docker.md#threaderror-cant-create-thread-operation-not-permitted).
 - Starting with 16.0, GitLab self-managed installations now have two database connections by default, instead of one. This change doubles the number of PostgreSQL connections. It makes self-managed versions of GitLab behave similarly to GitLab.com, and is a step toward enabling a separate database for CI features for self-managed versions of GitLab. Before upgrading to 16.0, determine if you need to [increase max connections for PostgreSQL](https://docs.gitlab.com/omnibus/settings/database.html#configuring-multiple-database-connections).
   - This change applies to installation methods with Linux packages (Omnibus), GitLab Helm chart, GitLab Operator, GitLab Docker images, and self-compiled installations.
-- Container registry using Azure storage might be empty with zero tags. You can fix this by following the [breaking change instructions](../deprecations.md#azure-storage-driver-defaults-to-the-correct-root-prefix). 
+  - The second database connection can be disabled:
+    - [Linux package and Docker installations](https://docs.gitlab.com/omnibus/settings/database.html#configuring-multiple-database-connections).
+    - [Helm chart and GitLab Operator installations](https://docs.gitlab.com/charts/charts/globals.html#configure-multiple-database-connections).
+    - [Self-compiled installations](../../install/installation.md#configure-gitlab-db-settings).
+- Container registry using Azure storage might be empty with zero tags. You can fix this by following the [breaking change instructions](../deprecations.md#azure-storage-driver-defaults-to-the-correct-root-prefix).
 
 ### Linux package installations
 
diff --git a/doc/update/with_downtime.md b/doc/update/with_downtime.md
index 9145003eff4..bd8c17fae50 100644
--- a/doc/update/with_downtime.md
+++ b/doc/update/with_downtime.md
@@ -1,7 +1,7 @@
 ---
 stage: Systems
 group: Distribution
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
 # Multi-node upgrades with downtime **(FREE SELF)**
diff --git a/doc/update/zero_downtime.md b/doc/update/zero_downtime.md
index 7a0f49b6fe7..6ecd23a0dc8 100644
--- a/doc/update/zero_downtime.md
+++ b/doc/update/zero_downtime.md
@@ -1,7 +1,7 @@
 ---
 stage: Systems
 group: Distribution
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
 # Zero downtime upgrades **(FREE SELF)**