Add latest changes from gitlab-org/gitlab@master

9 files changed, 117 insertions, 64 deletions

diff --git a/doc/administration/geo/replication/troubleshooting.md b/doc/administration/geo/replication/troubleshooting.md
index c80fc0d67d0..068e631f62a 100644
--- a/doc/administration/geo/replication/troubleshooting.md
+++ b/doc/administration/geo/replication/troubleshooting.md
@@ -1323,6 +1323,34 @@ To fix this issue, set the primary site's internal URL to a URL that is:
    GeoNode.where(primary: true).first.update!(internal_url: "https://unique.url.for.primary.site")
    ```
 
+### Secondary site returns `Received HTTP code 403 from proxy after CONNECT`
+
+If you have installed GitLab using the Linux package (Omnibus) and have configured the `no_proxy` [custom environment variable](https://docs.gitlab.com/omnibus/settings/environment-variables.html) for Gitaly, you may experience this issue. Affected versions:
+
+- `15.4.6`
+- `15.5.0`-`15.5.6`
+- `15.6.0`-`15.6.3`
+- `15.7.0`-`15.7.1`
+
+This is due to [a bug introduced in the included version of cURL](https://github.com/curl/curl/issues/10122) shipped with Omnibus GitLab 15.4.6 and later. You are encouraged to upgrade to a later version where this has been [fixed](https://about.gitlab.com/releases/2023/01/09/security-release-gitlab-15-7-2-released/). 
+
+The bug causes all wildcard domains (`.example.com`) to be ignored except for the last on in the `no_proxy` environment variable list. Therefore, if for any reason you cannot upgrade to a newer version, you can work around the issue by moving your wildcard domain to the end of the list:
+
+1. Edit `/etc/gitlab/gitlab.rb`:
+
+   ```ruby
+   gitaly['env'] = {
+     "no_proxy" => "sever.yourdomain.org, .yourdomain.com",
+   }
+
+1. Reconfigure GitLab:
+
+   ```shell
+   sudo gitlab-ctl reconfigure
+   ``` 
+
+You can have only one wildcard domain in the `no_proxy` list.
+
 ## Fixing non-PostgreSQL replication failures
 
 If you notice replication failures in `Admin > Geo > Sites` or the [Sync status Rake task](#sync-status-rake-task), you can try to resolve the failures with the following general steps:
diff --git a/doc/administration/geo/secondary_proxy/index.md b/doc/administration/geo/secondary_proxy/index.md
index ef3ce9237e4..addf894f0a5 100644
--- a/doc/administration/geo/secondary_proxy/index.md
+++ b/doc/administration/geo/secondary_proxy/index.md
@@ -32,6 +32,9 @@ Use secondary proxying for use-cases including:
 - Having all Geo sites behind a single URL.
 - Geographically load-balancing traffic without worrying about write access.
 
+NOTE:
+Geo proxying for secondary sites is separate from Geo proxying/redirecting for Git push operations.
+
 <i class="fa fa-youtube-play youtube" aria-hidden="true"></i>
 For an overview, see: [Secondary proxying using geographic load-balancer and AWS Route53](https://www.youtube.com/watch?v=TALLy7__Na8).
 
diff --git a/doc/administration/reference_architectures/10k_users.md b/doc/administration/reference_architectures/10k_users.md
index bcf106b9d14..dcba034b381 100644
--- a/doc/administration/reference_architectures/10k_users.md
+++ b/doc/administration/reference_architectures/10k_users.md
@@ -1152,15 +1152,19 @@ are supported and can be added if needed.
 
 ## Configure Gitaly Cluster
 
-[Gitaly Cluster](../gitaly/praefect.md) is a GitLab provided and recommended fault tolerant solution for storing Git repositories.
-In this configuration, every Git repository is stored on every Gitaly node in the cluster, with one being designated the primary, and failover occurs automatically if the primary node goes down.
+[Gitaly Cluster](../gitaly/praefect.md) is a GitLab-provided and recommended fault tolerant solution for storing Git
+repositories. In this configuration, every Git repository is stored on every Gitaly node in the cluster, with one being
+designated the primary, and failover occurs automatically if the primary node goes down.
 
-NOTE:
-Gitaly Cluster provides the benefits of fault tolerance, but comes with additional complexity of setup and management. Review the existing [technical limitations and considerations before deploying Gitaly Cluster](../gitaly/index.md#before-deploying-gitaly-cluster).
-For implementations with sharded Gitaly, use the same Gitaly specs. Follow the [separate Gitaly documentation](../gitaly/configure_gitaly.md) instead of this section.
+Gitaly Cluster provides the benefits of fault tolerance, but comes with additional complexity of setup and management.
+Review the existing [technical limitations and considerations before deploying Gitaly Cluster](../gitaly/index.md#before-deploying-gitaly-cluster).
 
-NOTE:
-For guidance on how to migrate existing repositories from NFS to Gitaly Cluster, [follow the main documentation](../gitaly/index.md#migrate-to-gitaly-cluster).
+For guidance on:
+
+- Implementing sharded Gitaly instead, follow the [separate Gitaly documentation](../gitaly/configure_gitaly.md)
+  instead of this section. Use the same Gitaly specs.
+- Migrating existing repositories that aren't managed by Gitaly Cluster, see
+  [migrate to Gitaly Cluster](../gitaly/index.md#migrate-to-gitaly-cluster).
 
 NOTE:
 Gitaly has been designed and tested with repositories of varying sizes that follow best practices.
@@ -1168,10 +1172,6 @@ However, large repositories or monorepos not following these practices can signi
 impact Gitaly performance and requirements.
 Refer to [Large repositories](index.md#large-repositories) for more information.
 
-NOTE:
-This architecture uses [Gitaly Cluster](../gitaly/praefect.md). If you have existing repositories that aren't already managed by Gitaly Cluster, you must first
-[migrate to Gitaly Cluster](../gitaly/index.md#migrate-to-gitaly-cluster).
-
 The recommended cluster setup includes the following components:
 
 - 3 Gitaly nodes: Replicated storage of Git repositories.
@@ -1179,9 +1179,9 @@ The recommended cluster setup includes the following components:
 - 1 Praefect PostgreSQL node: Database server for Praefect. A third-party solution
   is required for Praefect database connections to be made highly available.
 - 1 load balancer: A load balancer is required for Praefect. The
-  [internal load balancer](#configure-the-internal-load-balancer) will be used.
+  [internal load balancer](#configure-the-internal-load-balancer) is used.
 
-This section will detail how to configure the recommended standard setup in order.
+This section details how to configure the recommended standard setup in order.
 For more advanced setups refer to the [standalone Gitaly Cluster documentation](../gitaly/praefect.md).
 
 ### Configure Praefect PostgreSQL
diff --git a/doc/administration/reference_architectures/25k_users.md b/doc/administration/reference_architectures/25k_users.md
index 37bb6455347..48e6d01a2e5 100644
--- a/doc/administration/reference_architectures/25k_users.md
+++ b/doc/administration/reference_architectures/25k_users.md
@@ -1171,16 +1171,19 @@ are supported and can be added if needed.
 
 ## Configure Gitaly Cluster
 
-[Gitaly Cluster](../gitaly/praefect.md) is a GitLab-provided and recommended
-fault tolerant solution for storing Git repositories.
-In this configuration, every Git repository is stored on every Gitaly node in the cluster, with one being designated the primary, and failover occurs automatically if the primary node goes down.
+[Gitaly Cluster](../gitaly/praefect.md) is a GitLab-provided and recommended fault tolerant solution for storing Git
+repositories. In this configuration, every Git repository is stored on every Gitaly node in the cluster, with one being
+designated the primary, and failover occurs automatically if the primary node goes down.
 
-NOTE:
-Gitaly Cluster provides the benefits of fault tolerance, but comes with additional complexity of setup and management. Review the existing [technical limitations and considerations before deploying Gitaly Cluster](../gitaly/index.md#before-deploying-gitaly-cluster).
-For implementations with sharded Gitaly, use the same Gitaly specs. Follow the [separate Gitaly documentation](../gitaly/configure_gitaly.md) instead of this section.
+Gitaly Cluster provides the benefits of fault tolerance, but comes with additional complexity of setup and management.
+Review the existing [technical limitations and considerations before deploying Gitaly Cluster](../gitaly/index.md#before-deploying-gitaly-cluster).
 
-NOTE:
-For guidance on how to migrate existing repositories from NFS to Gitaly Cluster, [follow the main documentation](../gitaly/index.md#migrate-to-gitaly-cluster).
+For guidance on:
+
+- Implementing sharded Gitaly instead, follow the [separate Gitaly documentation](../gitaly/configure_gitaly.md)
+  instead of this section. Use the same Gitaly specs.
+- Migrating existing repositories that aren't managed by Gitaly Cluster, see
+  [migrate to Gitaly Cluster](../gitaly/index.md#migrate-to-gitaly-cluster).
 
 NOTE:
 Gitaly has been designed and tested with repositories of varying sizes that follow best practices.
@@ -1188,10 +1191,6 @@ However, large repositories or monorepos not following these practices can signi
 impact Gitaly performance and requirements.
 Refer to [Large repositories](index.md#large-repositories) for more information.
 
-NOTE:
-This architecture uses [Gitaly Cluster](../gitaly/praefect.md). If you have existing repositories that aren't already managed by Gitaly Cluster, you must first
-[migrate to Gitaly Cluster](../gitaly/index.md#migrate-to-gitaly-cluster).
-
 The recommended cluster setup includes the following components:
 
 - 3 Gitaly nodes: Replicated storage of Git repositories.
@@ -1199,9 +1198,9 @@ The recommended cluster setup includes the following components:
 - 1 Praefect PostgreSQL node: Database server for Praefect. A third-party solution
   is required for Praefect database connections to be made highly available.
 - 1 load balancer: A load balancer is required for Praefect. The
-  [internal load balancer](#configure-the-internal-load-balancer) will be used.
+  [internal load balancer](#configure-the-internal-load-balancer) is used.
 
-This section will detail how to configure the recommended standard setup in order.
+This section details how to configure the recommended standard setup in order.
 For more advanced setups refer to the [standalone Gitaly Cluster documentation](../gitaly/praefect.md).
 
 ### Configure Praefect PostgreSQL
diff --git a/doc/administration/reference_architectures/3k_users.md b/doc/administration/reference_architectures/3k_users.md
index b4aeba6e855..2f65f3ba2e1 100644
--- a/doc/administration/reference_architectures/3k_users.md
+++ b/doc/administration/reference_architectures/3k_users.md
@@ -1107,15 +1107,19 @@ The following IPs will be used as an example:
 
 ## Configure Gitaly Cluster
 
-[Gitaly Cluster](../gitaly/praefect.md) is a GitLab provided and recommended fault tolerant solution for storing Git repositories.
-In this configuration, every Git repository is stored on every Gitaly node in the cluster, with one being designated the primary, and failover occurs automatically if the primary node goes down.
+[Gitaly Cluster](../gitaly/praefect.md) is a GitLab-provided and recommended fault tolerant solution for storing Git
+repositories. In this configuration, every Git repository is stored on every Gitaly node in the cluster, with one being
+designated the primary, and failover occurs automatically if the primary node goes down.
 
-NOTE:
-Gitaly Cluster provides the benefits of fault tolerance, but comes with additional complexity of setup and management. Review the existing [technical limitations and considerations before deploying Gitaly Cluster](../gitaly/index.md#before-deploying-gitaly-cluster).
-For implementations with sharded Gitaly, use the same Gitaly specs. Follow the [separate Gitaly documentation](../gitaly/configure_gitaly.md) instead of this section.
+Gitaly Cluster provides the benefits of fault tolerance, but comes with additional complexity of setup and management.
+Review the existing [technical limitations and considerations before deploying Gitaly Cluster](../gitaly/index.md#before-deploying-gitaly-cluster).
 
-NOTE:
-For guidance on how to migrate existing repositories from NFS to Gitaly Cluster, [follow the main documentation](../gitaly/index.md#migrate-to-gitaly-cluster).
+For guidance on:
+
+- Implementing sharded Gitaly instead, follow the [separate Gitaly documentation](../gitaly/configure_gitaly.md)
+  instead of this section. Use the same Gitaly specs.
+- Migrating existing repositories that aren't managed by Gitaly Cluster, see
+  [migrate to Gitaly Cluster](../gitaly/index.md#migrate-to-gitaly-cluster).
 
 NOTE:
 Gitaly has been designed and tested with repositories of varying sizes that follow best practices.
@@ -1123,10 +1127,6 @@ However, large repositories or monorepos not following these practices can signi
 impact Gitaly performance and requirements.
 Refer to [Large repositories](index.md#large-repositories) for more information.
 
-NOTE:
-This architecture uses [Gitaly Cluster](../gitaly/praefect.md). If you have existing repositories that aren't already managed by Gitaly Cluster, you must first
-[migrate to Gitaly Cluster](../gitaly/index.md#migrate-to-gitaly-cluster).
-
 The recommended cluster setup includes the following components:
 
 - 3 Gitaly nodes: Replicated storage of Git repositories.
@@ -1134,9 +1134,9 @@ The recommended cluster setup includes the following components:
 - 1 Praefect PostgreSQL node: Database server for Praefect. A third-party solution
   is required for Praefect database connections to be made highly available.
 - 1 load balancer: A load balancer is required for Praefect. The
-  [internal load balancer](#configure-the-internal-load-balancer) will be used.
+  [internal load balancer](#configure-the-internal-load-balancer) is used.
 
-This section will detail how to configure the recommended standard setup in order.
+This section details how to configure the recommended standard setup in order.
 For more advanced setups refer to the [standalone Gitaly Cluster documentation](../gitaly/praefect.md).
 
 ### Configure Praefect PostgreSQL
diff --git a/doc/administration/reference_architectures/50k_users.md b/doc/administration/reference_architectures/50k_users.md
index df70233c80e..e12f40b734e 100644
--- a/doc/administration/reference_architectures/50k_users.md
+++ b/doc/administration/reference_architectures/50k_users.md
@@ -1165,15 +1165,19 @@ Advanced [configuration options](https://docs.gitlab.com/omnibus/settings/redis.
 
 ## Configure Gitaly Cluster
 
-[Gitaly Cluster](../gitaly/praefect.md) is a GitLab provided and recommended fault tolerant solution for storing Git repositories.
-In this configuration, every Git repository is stored on every Gitaly node in the cluster, with one being designated the primary, and failover occurs automatically if the primary node goes down.
+[Gitaly Cluster](../gitaly/praefect.md) is a GitLab-provided and recommended fault tolerant solution for storing Git
+repositories. In this configuration, every Git repository is stored on every Gitaly node in the cluster, with one being
+designated the primary, and failover occurs automatically if the primary node goes down.
 
-NOTE:
-Gitaly Cluster provides the benefits of fault tolerance, but comes with additional complexity of setup and management. Review the existing [technical limitations and considerations before deploying Gitaly Cluster](../gitaly/index.md#before-deploying-gitaly-cluster).
-For implementations with sharded Gitaly, use the same Gitaly specs. Follow the [separate Gitaly documentation](../gitaly/configure_gitaly.md) instead of this section.
+Gitaly Cluster provides the benefits of fault tolerance, but comes with additional complexity of setup and management.
+Review the existing [technical limitations and considerations before deploying Gitaly Cluster](../gitaly/index.md#before-deploying-gitaly-cluster).
 
-NOTE:
-For guidance on how to migrate existing repositories from NFS to Gitaly Cluster, [follow the main documentation](../gitaly/index.md#migrate-to-gitaly-cluster).
+For guidance on:
+
+- Implementing sharded Gitaly instead, follow the [separate Gitaly documentation](../gitaly/configure_gitaly.md)
+  instead of this section. Use the same Gitaly specs.
+- Migrating existing repositories that aren't managed by Gitaly Cluster, see
+  [migrate to Gitaly Cluster](../gitaly/index.md#migrate-to-gitaly-cluster).
 
 NOTE:
 Gitaly has been designed and tested with repositories of varying sizes that follow best practices.
@@ -1181,10 +1185,6 @@ However, large repositories or monorepos not following these practices can signi
 impact Gitaly performance and requirements.
 Refer to [Large repositories](index.md#large-repositories) for more information.
 
-NOTE:
-This architecture uses [Gitaly Cluster](../gitaly/praefect.md). If you have existing repositories that aren't already managed by Gitaly Cluster, you must first
-[migrate to Gitaly Cluster](../gitaly/index.md#migrate-to-gitaly-cluster).
-
 The recommended cluster setup includes the following components:
 
 - 3 Gitaly nodes: Replicated storage of Git repositories.
@@ -1192,9 +1192,9 @@ The recommended cluster setup includes the following components:
 - 1 Praefect PostgreSQL node: Database server for Praefect. A third-party solution
   is required for Praefect database connections to be made highly available.
 - 1 load balancer: A load balancer is required for Praefect. The
-  [internal load balancer](#configure-the-internal-load-balancer) will be used.
+  [internal load balancer](#configure-the-internal-load-balancer) is used.
 
-This section will detail how to configure the recommended standard setup in order.
+This section details how to configure the recommended standard setup in order.
 For more advanced setups refer to the [standalone Gitaly Cluster documentation](../gitaly/praefect.md).
 
 ### Configure Praefect PostgreSQL
diff --git a/doc/administration/reference_architectures/5k_users.md b/doc/administration/reference_architectures/5k_users.md
index 37a765ab0a8..113e9a26a54 100644
--- a/doc/administration/reference_architectures/5k_users.md
+++ b/doc/administration/reference_architectures/5k_users.md
@@ -1103,15 +1103,19 @@ The following IPs are used as an example:
 
 ## Configure Gitaly Cluster
 
-[Gitaly Cluster](../gitaly/praefect.md) is a GitLab provided and recommended fault tolerant solution for storing Git repositories.
-In this configuration, every Git repository is stored on every Gitaly node in the cluster, with one being designated the primary, and failover occurs automatically if the primary node goes down.
+[Gitaly Cluster](../gitaly/praefect.md) is a GitLab-provided and recommended fault tolerant solution for storing Git
+repositories. In this configuration, every Git repository is stored on every Gitaly node in the cluster, with one being
+designated the primary, and failover occurs automatically if the primary node goes down.
 
-NOTE:
-Gitaly Cluster provides the benefits of fault tolerance, but comes with additional complexity of setup and management. Review the existing [technical limitations and considerations before deploying Gitaly Cluster](../gitaly/index.md#before-deploying-gitaly-cluster).
-For implementations with sharded Gitaly, use the same Gitaly specs. Follow the [separate Gitaly documentation](../gitaly/configure_gitaly.md) instead of this section.
+Gitaly Cluster provides the benefits of fault tolerance, but comes with additional complexity of setup and management.
+Review the existing [technical limitations and considerations before deploying Gitaly Cluster](../gitaly/index.md#before-deploying-gitaly-cluster).
 
-NOTE:
-For guidance on how to migrate existing repositories from NFS to Gitaly Cluster, [follow the main documentation](../gitaly/index.md#migrate-to-gitaly-cluster).
+For guidance on:
+
+- Implementing sharded Gitaly instead, follow the [separate Gitaly documentation](../gitaly/configure_gitaly.md)
+  instead of this section. Use the same Gitaly specs.
+- Migrating existing repositories that aren't managed by Gitaly Cluster, see
+  [migrate to Gitaly Cluster](../gitaly/index.md#migrate-to-gitaly-cluster).
 
 NOTE:
 Gitaly has been designed and tested with repositories of varying sizes that follow best practices.
@@ -1119,10 +1123,6 @@ However, large repositories or monorepos not following these practices can signi
 impact Gitaly performance and requirements.
 Refer to [Large repositories](index.md#large-repositories) for more information.
 
-NOTE:
-This architecture uses [Gitaly Cluster](../gitaly/praefect.md). If you have existing repositories that aren't already managed by Gitaly Cluster, you must first
-[migrate to Gitaly Cluster](../gitaly/index.md#migrate-to-gitaly-cluster).
-
 The recommended cluster setup includes the following components:
 
 - 3 Gitaly nodes: Replicated storage of Git repositories.
diff --git a/doc/api/remote_mirrors.md b/doc/api/remote_mirrors.md
index 00dc34e261a..93dffe69ef5 100644
--- a/doc/api/remote_mirrors.md
+++ b/doc/api/remote_mirrors.md
@@ -14,6 +14,11 @@ can query and modify the state of these mirrors with the remote mirror API.
 For security reasons, the `url` attribute in the API response is always scrubbed of username
 and password information.
 
+NOTE:
+[Pull mirrors](../user/project/repository/mirror/pull.md) use
+[a different API endpoint](projects.md#configure-pull-mirroring-for-a-project) to
+display and update them.
+
 ## List a project's remote mirrors
 
 Returns an array of remote mirrors and their statuses:
diff --git a/doc/update/deprecations.md b/doc/update/deprecations.md
index 63c87abdf93..772d0f213b8 100644
--- a/doc/update/deprecations.md
+++ b/doc/update/deprecations.md
@@ -107,6 +107,24 @@ Review the details carefully before upgrading.
 Due to low customer usage, Load Performance Testing is deprecated and will be removed. There is no planned replacement and users should stop using Load Performance Testing before GitLab 17.0.
 
 </div>
+
+<div class="deprecation removal-160 breaking-change">
+
+### Option to delete projects immediately is deprecated from deletion protection settings
+
+Planned removal: GitLab <span class="removal-milestone">16.0</span> <span class="removal-date"></span>
+
+WARNING:
+This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
+Review the details carefully before upgrading.
+
+The project deletion protection setting in the Admin Area had an option to delete projects immediately. Starting with 16.0, this option will no longer be available, and delayed project deletion will become the default behavior.
+
+The option will no longer appear as a group setting. Self-managed users will still have the option to define the deletion delay period, and SaaS users have a non-adjustable default retention period of 7 days. Users can still delete the project immediately from the project settings.
+
+The option to delete projects immediately by default was deprecated to prevent users from accidentally taking this action and permanently losing projects.
+
+</div>
 </div>
 
 <div class="announcement-milestone">