Add latest changes from gitlab-org/gitlab@master

7 files changed, 55 insertions, 31 deletions

diff --git a/doc/administration/gitaly/praefect.md b/doc/administration/gitaly/praefect.md
index 3d09291d9b5..b552f7d88af 100644
--- a/doc/administration/gitaly/praefect.md
+++ b/doc/administration/gitaly/praefect.md
@@ -1,17 +1,26 @@
-# Praefect: High Availability
+---
+type: reference
+---
 
-NOTE: **Note:** Praefect is a
-[beta](https://about.gitlab.com/handbook/product/#alpha-beta-ga) component that
-allows Gitaly to be run in a highly available configuration. While unexpected
-data loss is not likely, Praefect is not yet ready for production environments.
+# Gitaly Cluster
 
-[Gitaly](index.md) is the service that provides storage for Git repositories in
-the GitLab application. Praefect is an optional reverse proxy for Gitaly to
-manage multiple Gitaly nodes for high availability.
+[Gitaly](index.md), the service that provides storage for Git repositories, can
+be run in a clustered configuration to increase fault tolerance. In this
+configuration, every Git repository is stored on every Gitaly node in the
+cluster. Multiple clusters (or shards), can be configured.
 
-High availability is currently implemented through **asynchronous replication**.
-If a Gitaly node becomes unavailable, Praefect will automatically route traffic
-to a warm Gitaly replica.
+Praefect is a router and transaction manager for Gitaly, and a required
+component for running a Gitaly Cluster.
+
+![Architecture diagram](img/praefect_architecture_v12_10.png)
+
+Using a Gitaly Cluster increase fault tolerance by:
+
+- Replicating write operations to warm standby Gitaly nodes.
+- Detecting Gitaly node failures.
+- Automatically routing Git requests to an available Gitaly node.
+
+The availability objectives for Gitaly clusters are:
 
 - **Recovery Point Objective (RPO):** Less than 1 minute.
 
@@ -35,22 +44,22 @@ The current version supports:
 - Eventual consistency of the secondary replicas.
 - Automatic failover from the primary to the secondary.
 - Reporting of possible data loss if replication queue is non empty.
+- Marking the newly promoted primary read only if possible data loss is
+  detected.
 
 Follow the [HA Gitaly epic](https://gitlab.com/groups/gitlab-org/-/epics/1489)
 for improvements including
 [horizontally distributing reads](https://gitlab.com/groups/gitlab-org/-/epics/2013).
 
-## Requirements for configuring Gitaly for High Availability
+## Requirements for configuring a Gitaly Cluster
 
-A minimum highly available configuration requires:
+The minimum recommended configuration for a Gitaly Cluster requires:
 
 - 1 highly available load balancer
 - 1 highly available PostgreSQL server (PostgreSQL 9.6 or newer)
 - 3 Praefect nodes
 - 3 Gitaly nodes (1 primary, 2 secondary)
 
-![Architecture diagram](img/praefect_architecture_v12_10.png)
-
 See the [design
 document](https://gitlab.com/gitlab-org/gitaly/-/blob/master/doc/design_ha.md)
 for implementation details.
diff --git a/doc/administration/high_availability/gitaly.md b/doc/administration/high_availability/gitaly.md
index f1ebc730e5b..2e6bcabeb06 100644
--- a/doc/administration/high_availability/gitaly.md
+++ b/doc/administration/high_availability/gitaly.md
@@ -4,12 +4,8 @@ type: reference
 
 # Configuring Gitaly for Scaled and High Availability
 
-Gitaly does not yet support full high availability. However, Gitaly is quite
-stable and is in use on GitLab.com. Scaled and highly available GitLab environments
-should consider using Gitaly on a separate node.
-
-See the [Gitaly HA Epic](https://gitlab.com/groups/gitlab-org/-/epics/289) to
-track plans and progress toward high availability support.
+A [Gitaly Cluster](../gitaly/praefect.md) can be used to increase the fault
+tolerance of Gitaly in high availability configurations.
 
 This document is relevant for [scalable and highly available setups](../reference_architectures/index.md).
 
diff --git a/doc/administration/high_availability/nfs.md b/doc/administration/high_availability/nfs.md
index a91f3d64a4c..c2fa99e67f4 100644
--- a/doc/administration/high_availability/nfs.md
+++ b/doc/administration/high_availability/nfs.md
@@ -12,9 +12,6 @@ performance, especially for actions that read or write to Git repositories. See
 [Filesystem Performance Benchmarking](../operations/filesystem_benchmarking.md)
 for steps to test filesystem performance.
 
-NOTE: **Note:** [Cloud Object Storage service](object_storage.md) with [Gitaly](gitaly.md)
-is recommended over NFS wherever possible for improved performance.
-
 ## NFS Server features
 
 ### Required features
diff --git a/doc/api/deploy_tokens.md b/doc/api/deploy_tokens.md
index 461957847df..6e732a43da0 100644
--- a/doc/api/deploy_tokens.md
+++ b/doc/api/deploy_tokens.md
@@ -92,7 +92,7 @@ POST /projects/:id/deploy_tokens
 | `name`            | string    | yes | New deploy token's name |
 | `expires_at`      | datetime  | no  | Expiration date for the deploy token. Does not expire if no value is provided. |
 | `username`        | string    | no  | Username for deploy token. Default is `gitlab+deploy-token-{n}` |
-| `scopes`   | array of strings | yes | Indicates the deploy token scopes. Must be at least one of `read_repository`, `read_registry`, or `write_registry`. |
+| `scopes`   | array of strings | yes | Indicates the deploy token scopes. Must be at least one of `read_repository`, `read_registry`, `write_registry`, `read_package_registry`, or `write_package_registry`. |
 
 ```shell
 curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" --header "Content-Type: application/json" --data '{"name": "My deploy token", "expires_at": "2021-01-01", "username": "custom-user", "scopes": ["read_repository"]}' "https://gitlab.example.com/api/v4/projects/5/deploy_tokens/"
@@ -193,7 +193,7 @@ POST /groups/:id/deploy_tokens
 | `name`            | string    | yes | New deploy token's name |
 | `expires_at`      | datetime  | no  | Expiration date for the deploy token. Does not expire if no value is provided. |
 | `username`        | string    | no  | Username for deploy token. Default is `gitlab+deploy-token-{n}` |
-| `scopes`   | array of strings | yes | Indicates the deploy token scopes. Must be at least one of `read_repository`, `read_registry`, or `write_registry`. |
+| `scopes`   | array of strings | yes | Indicates the deploy token scopes. Must be at least one of `read_repository`, `read_registry`, `write_registry`, `read_package_registry`, or `write_package_registry`. |
 
 Example request:
 
diff --git a/doc/topics/git/partial_clone.md b/doc/topics/git/partial_clone.md
index c776824f433..46318a7f30d 100644
--- a/doc/topics/git/partial_clone.md
+++ b/doc/topics/git/partial_clone.md
@@ -9,6 +9,8 @@ is a performance optimization that "allows Git to function without having a
 complete copy of the repository. The goal of this work is to allow Git better
 handle extremely large repositories."
 
+Git 2.22.0 or later is required.
+
 ## Filter by file size
 
 > [Introduced](https://gitlab.com/gitlab-org/gitaly/-/issues/2553) in GitLab 12.10.
@@ -118,7 +120,7 @@ enabled on the Git server:
    many applications, each in a different subdirectory in the root. Create a file
    `shiny-app/.filterspec` using the GitLab web interface:
 
-   ```.gitignore
+   ```plaintext
    # Only the paths listed in the file will be downloaded when performing a
    # partial clone using `--filter=sparse:oid=shiny-app/.gitfilterspec`
 
@@ -136,7 +138,7 @@ enabled on the Git server:
    shared-component-b/
    ```
 
-1. *Create a new Git repository and fetch.* Support for `--filter=sparse:oid`
+1. **Create a new Git repository and fetch.** Support for `--filter=sparse:oid`
    using the clone command is incomplete, so we will emulate the clone command
    by hand, using `git init` and `git fetch`. Follow
    [issue tracking support for `--filter=sparse:oid`](https://gitlab.com/gitlab-org/git/issues/4)
diff --git a/doc/user/group/settings/import_export.md b/doc/user/group/settings/import_export.md
index d50327f2a90..a8aec841072 100644
--- a/doc/user/group/settings/import_export.md
+++ b/doc/user/group/settings/import_export.md
@@ -63,8 +63,11 @@ For more details on the specific data persisted in a group export, see the
 
    ![Export group panel](img/export_panel.png)
 
-1. Once the export is generated, you can click **Download export** to download the [exported contents](#exported-contents)
-in a compressed tar archive, with contents in JSON format. You can also return to this page to regenerate the export data.
+1. Once the export is generated, you should receive an e-mail with a link to the [exported contents](#exported-contents)
+   in a compressed tar archive, with contents in JSON format.
+
+1. Alternatively, you can come back to the project settings and download the
+   file from there by clicking **Download export**, or generate a new file by clicking **Regenerate export**.
 
 ## Rate Limits
 
diff --git a/doc/user/project/deploy_tokens/index.md b/doc/user/project/deploy_tokens/index.md
index 44e2d210910..2d42debed68 100644
--- a/doc/user/project/deploy_tokens/index.md
+++ b/doc/user/project/deploy_tokens/index.md
@@ -4,8 +4,9 @@
 > - [Moved](https://gitlab.com/gitlab-org/gitlab/issues/199370) from **Settings > Repository** in GitLab 12.9.
 > - [Added `write_registry` scope](https://gitlab.com/gitlab-org/gitlab/-/issues/22743) in GitLab 12.10.
 > - [Moved](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/29280) from **Settings > CI / CD** in GitLab 12.10.1.
+> - [Added package registry scopes](https://gitlab.com/gitlab-org/gitlab/-/issues/213566) from **Settings > CI / CD** in GitLab 13.0.
 
-Deploy tokens allow you to download (`git clone`) or push and pull the container registry images of a project without having a user and a password.
+Deploy tokens allow you to download (`git clone`) or push and pull packages and container registry images of a project without having a user and a password.
 
 Deploy tokens can be managed by [maintainers only](../../permissions.md).
 
@@ -101,6 +102,22 @@ To push the container registry images, you'll need to:
 Just replace `<username>` and `<deploy_token>` with the proper values. Then you can simply
 push images to your Container Registry.
 
+### Read or pull packages
+
+To pull packages in the GitLab package registry, you'll need to:
+
+1. Create a Deploy Token with `read_package_registry` as a scope.
+1. Take note of your `username` and `token`.
+1. For the [package type of your choice](./../../packages/index.md), follow the authentication instructions for deploy tokens.
+
+### Push or upload packages
+
+To upload packages in the GitLab package registry, you'll need to:
+
+1. Create a Deploy Token with `write_package_registry` as a scope.
+1. Take note of your `username` and `token`.
+1. For the [package type of your choice](./../../packages/index.md), follow the authentication instructions for deploy tokens.
+
 ### Group Deploy Token
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/21765) in GitLab 12.9.