Add latest changes from gitlab-org/gitlab@master

9 files changed, 153 insertions, 159 deletions

diff --git a/doc/administration/geo/replication/troubleshooting.md b/doc/administration/geo/replication/troubleshooting.md
index fa2a92428a6..ac013439f27 100644
--- a/doc/administration/geo/replication/troubleshooting.md
+++ b/doc/administration/geo/replication/troubleshooting.md
@@ -183,7 +183,7 @@ This machine's Geo node name matches a database record ... no
 ```
 
 Learn more about recommended site names in the description of the Name field in
-[Geo Admin Area Common Settings](../../../user/admin_area/geo_nodes.md#common-settings).
+[Geo Admin Area Common Settings](../../../user/admin_area/geo_sites.md#common-settings).
 
 ### Message: `WARNING: oldest xmin is far in the past` and `pg_wal` size growing
 
diff --git a/doc/ci/review_apps/index.md b/doc/ci/review_apps/index.md
index 3ebd38df8db..6dd03033926 100644
--- a/doc/ci/review_apps/index.md
+++ b/doc/ci/review_apps/index.md
@@ -287,6 +287,9 @@ can supply the ID by either:
 - Dynamically adding the `data-merge-request-id` value during the build of the app.
 - Supplying it manually through the visual review form in the app.
 
+If the ID is missing from the `script`, the visual review tool prompts you to enter the
+merge request ID before you can provide feedback.
+
 ### Authentication for Visual Reviews
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/42750#note_317271120) in GitLab 12.10.
diff --git a/doc/development/database/multiple_databases.md b/doc/development/database/multiple_databases.md
index 7badd7f76fa..7991043625e 100644
--- a/doc/development/database/multiple_databases.md
+++ b/doc/development/database/multiple_databases.md
@@ -6,8 +6,11 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # Multiple Databases
 
-To scale GitLab, the we are
-[decomposing the GitLab application database into multiple databases](https://gitlab.com/groups/gitlab-org/-/epics/6168).
+To allow GitLab to scale further we
+[decomposed the GitLab application database into multiple
+databases](https://gitlab.com/groups/gitlab-org/-/epics/6168). The two databases
+are `main` and `ci`. GitLab supports being run with either one database or two databases.
+On GitLab.com we are using two separate databases.
 
 ## GitLab Schema
 
@@ -40,7 +43,7 @@ The `gitlab_schema` primary purpose is to introduce a barrier between different
 
 This is used as a primary source of classification for:
 
-- [Discovering cross-joins across tables from different schemas](#removing-joins-between-ci_-and-non-ci_-tables)
+- [Discovering cross-joins across tables from different schemas](#removing-joins-between-ci-and-non-ci-tables)
 - [Discovering cross-database transactions across tables from different schemas](#removing-cross-database-transactions)
 
 ### The special purpose of `gitlab_shared`
@@ -72,10 +75,6 @@ Read [Migrations for Multiple Databases](migrations_for_multiple_databases.md).
 
 ## CI/CD Database
 
-> Support for configuring the GitLab Rails application to use a distinct
-database for CI/CD tables was [introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/64289)
-in GitLab 14.1. This feature is still under development, and is not ready for production use.
-
 ### Configure single database
 
 By default, GDK is configured to run with multiple databases.
@@ -107,32 +106,14 @@ NOTE: The `validate_cross_joins!` method in `spec/support/database/prevent_cross
       the corresponding documentation URL used in `spec/support/database/prevent_cross_joins.rb`.
 -->
 
-### Removing joins between `ci_*` and non `ci_*` tables
+### Removing joins between `ci` and non `ci` tables
 
 Queries that join across databases raise an error. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/68620)
 in GitLab 14.3, for new queries only. Pre-existing queries do not raise an error.
 
-We are planning on moving all the `ci_*` tables to a separate database, so
-referencing `ci_*` tables with other tables will not be possible. This means,
-that using any kind of `JOIN` in SQL queries will not work. We have identified
-already many such examples that need to be fixed in
-<https://gitlab.com/groups/gitlab-org/-/epics/6289> .
-
-#### Path to removing cross-database joins
-
-The following steps are the process to remove cross-database joins between
-`ci_*` and non `ci_*` tables:
-
-1. **{check-circle}** Add all failing specs to the [`cross-join-allowlist.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/spec/support/database/cross-join-allowlist.yml)
-   file.
-1. **{check-circle}** Find the code that caused the spec failure and wrap the isolated code
-   in [`allow_cross_joins_across_databases`](#allowlist-for-existing-cross-joins).
-   Link to a new issue assigned to the correct team to remove the specs from the
-   `cross-join-allowlist.yml` file.
-1. **{dotted-circle}** Remove the `cross-join-allowlist.yml` file and stop allowing
-   whole test files.
-1. **{dotted-circle}** Fix the problem and remove the `allow_cross_joins_across_databases` call.
-1. **{dotted-circle}** Fix all the cross-joins and remove the `allow_cross_joins_across_databases` method.
+Because GitLab can be run with multiple separate databases, referencing `ci`
+tables with non `ci` tables in a single query is not possible. Therefore,
+using any kind of `JOIN` in SQL queries will not work.
 
 #### Suggestions for removing cross-database joins
 
@@ -416,13 +397,10 @@ query or look at other patterns described above for removing cross-joins.
 
 #### How to validate you have correctly removed a cross-join
 
-Using RSpec tests, you can validate all SQL queries within a code block to
-ensure that none of them are joining across the two databases. This is a useful
-tool to confirm you have correctly fixed an existing cross-join.
-
-At some point in the future we will have fixed all cross-joins and this tool
-will run by default in all tests. For now, the tool needs to be explicitly enabled
-for your test.
+RSpec is configured to automatically validate all SQL queries do not join
+across databases. If this validation is disabled in
+`spec/support/database/cross-join-allowlist.yml` then you can still validate an
+isolated code block using `with_cross_joins_prevented`.
 
 You can use this method like so:
 
@@ -553,12 +531,11 @@ The `MyAsyncConsistencyJob` would also attempt to update the timestamp if they d
 
 At this point, we don't have the tooling (we might not even need it) to ensure similar consistency
 characteristics as we had with one database. If you think that the code you're working on requires
-these properties, then you can disable the cross-database modification check by wrapping to
-offending database queries with a block and create a follow-up issue mentioning the sharding group
-(`gitlab-org/sharding-group`).
+these properties, then you can disable the cross-database modification check in your tests by wrapping the
+offending test code with a block and create a follow-up issue.
 
 ```ruby
-Gitlab::Database.allow_cross_joins_across_databases(url: 'gitlab issue URL') do
+allow_cross_database_modification_within_transaction(url: 'gitlab issue URL') do
   ApplicationRecord.transaction do
     ci_build.update!(updated_at: Time.current) # UPDATE on CI DB
     ci_build.project.update!(updated_at: Time.current) # UPDATE on Main DB
@@ -567,7 +544,7 @@ end
 ```
 
 Don't hesitate to reach out to the
-[sharding group](https://about.gitlab.com/handbook/engineering/development/enablement/sharding/)
+[pods group](https://about.gitlab.com/handbook/engineering/development/enablement/data_stores/pods/)
 for advice.
 
 ##### Avoid `dependent: :nullify` and `dependent: :destroy` across databases
diff --git a/doc/development/geo.md b/doc/development/geo.md
index 0120548e50b..fffcc4a3190 100644
--- a/doc/development/geo.md
+++ b/doc/development/geo.md
@@ -97,7 +97,7 @@ projects that need updating. Those projects can be:
   timestamp that is more recent than the `last_repository_successful_sync_at`
   timestamp in the `Geo::ProjectRegistry` model.
 - Manual: The administrator can manually flag a repository to resync in the
-  [Geo Admin Area](../user/admin_area/geo_nodes.md).
+  [Geo Admin Area](../user/admin_area/geo_sites.md).
 
 When we fail to fetch a repository on the secondary `RETRIES_BEFORE_REDOWNLOAD`
 times, Geo does a so-called _re-download_. It will do a clean clone
@@ -437,7 +437,7 @@ basically hashes all Git refs together and stores that hash in the
 The **secondary** site does the same to calculate the hash of its
 clone, and compares the hash with the value the **primary** site
 calculated. If there is a mismatch, Geo will mark this as a mismatch
-and the administrator can see this in the [Geo Admin Area](../user/admin_area/geo_nodes.md).
+and the administrator can see this in the [Geo Admin Area](../user/admin_area/geo_sites.md).
 
 ## Glossary
 
diff --git a/doc/security/two_factor_authentication.md b/doc/security/two_factor_authentication.md
index 32dae99be5a..4f03063e0e0 100644
--- a/doc/security/two_factor_authentication.md
+++ b/doc/security/two_factor_authentication.md
@@ -83,6 +83,8 @@ The following are important notes about 2FA:
   1. Uncheck the **Allow subgroups to set up their own two-factor authentication rule** field.
 
   This action causes all subgroups with 2FA requirements to stop requiring that from their members.
+- Access tokens are not required to provide a second factor for authentication because they are API-based.
+  Tokens generated before 2FA is enforced remain valid.
 
 ## Disable 2FA
 
diff --git a/doc/user/admin_area/geo_nodes.md b/doc/user/admin_area/geo_nodes.md
index 3c33578b88f..710f37bb344 100644
--- a/doc/user/admin_area/geo_nodes.md
+++ b/doc/user/admin_area/geo_nodes.md
@@ -1,117 +1,11 @@
 ---
-stage: Systems
-group: Geo
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
+redirect_to: 'geo_sites.md'
+remove_date: '2022-10-05'
 ---
 
-# Geo sites Admin Area **(PREMIUM SELF)**
+This document was moved to [another location](geo_sites.md).
 
-You can configure various settings for GitLab Geo sites. For more information, see
-[Geo documentation](../../administration/geo/index.md).
-
-On either the primary or secondary site:
-
-1. On the top bar, select **Menu > Admin**.
-1. On the left sidebar, select **Geo > Sites**.
-
-## Common settings
-
-All Geo sites have the following settings:
-
-| Setting | Description |
-| --------| ----------- |
-| Primary | This marks a Geo site as **primary** site. There can be only one **primary** site. |
-| Name    | The unique identifier for the Geo site. It's highly recommended to use a physical location as a name. Good examples are "London Office" or "us-east-1". Avoid words like "primary", "secondary", "Geo", or "DR". This makes the failover process easier because the physical location does not change, but the Geo site role can. All nodes in a single Geo site use the same site name. Nodes use the `gitlab_rails['geo_node_name']` setting in `/etc/gitlab/gitlab.rb` to lookup their Geo site record in the PostgreSQL database. If `gitlab_rails['geo_node_name']` is not set, the node's `external_url` with trailing slash is used as fallback. The value of `Name` is case-sensitive, and most characters are allowed. |
-| URL     | The instance's user-facing URL. |
-
-The site you're currently browsing is indicated with a blue `Current` label, and
-the **primary** node is listed first as `Primary site`.
-
-## Secondary site settings
-
-**Secondary** sites have a number of additional settings available:
-
-| Setting                   | Description |
-|---------------------------|-------------|
-| Selective synchronization | Enable Geo [selective sync](../../administration/geo/replication/configuration.md#selective-synchronization) for this **secondary** site. |
-| Repository sync capacity  | Number of concurrent requests this **secondary** site makes to the **primary** site when backfilling repositories. |
-| File sync capacity        | Number of concurrent requests this **secondary** site makes to the **primary** site when backfilling files. |
-
-## Geo backfill
-
-**Secondary** sites are notified of changes to repositories and files by the **primary** site,
-and always attempt to synchronize those changes as quickly as possible.
-
-Backfill is the act of populating the **secondary** site with repositories and files that
-existed *before* the **secondary** site was added to the database. Because there may be
-extremely large numbers of repositories and files, it's not feasible to attempt to
-download them all at once; so, GitLab places an upper limit on the concurrency of
-these operations.
-
-How long the backfill takes is dependent on the maximum concurrency, but higher
-values place more strain on the **primary** site. The limits are configurable.
-If your **primary** site has lots of surplus capacity,
-you can increase the values to complete backfill in a shorter time. If it's
-under heavy load and backfill reduces its availability for normal requests,
-you can decrease them.
-
-## Set up the internal URLs
-
-> Setting up internal URLs in secondary sites was [introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/77179) in GitLab 14.7.
-
-You can set up a different URL for synchronization between the primary and secondary site.
-
-The **primary** site's Internal URL is used by **secondary** sites to contact it
-(to sync repositories, for example). The name Internal URL distinguishes it from
-[External URL](https://docs.gitlab.com/omnibus/settings/configuration.html#configuring-the-external-url-for-gitlab),
-which is used by users. Internal URL does not need to be a private address.
-
-When [Geo secondary proxying](../../administration/geo/secondary_proxy/index.md) is enabled,
-the primary uses the secondary's internal URL to contact it directly.
-
-The internal URL defaults to external URL. To change it:
-
-1. On the top bar, select **Menu > Admin**.
-1. On the left sidebar, select **Geo > Nodes**.
-1. Select **Edit** on the site you want to customize.
-1. Edit the internal URL.
-1. Select **Save changes**.
-
-When enabled, the Admin Area for Geo shows replication details for each site directly
-from the primary site's UI, and through the Geo secondary proxy, if enabled.
-
-WARNING:
-We recommend using an HTTPS connection while configuring the Geo sites. To avoid
-breaking communication between **primary** and **secondary** sites when using
-HTTPS, customize your Internal URL to point to a load balancer with TLS
-terminated at the load balancer.
-
-WARNING:
-Starting with GitLab 13.3 and [until 13.11](https://gitlab.com/gitlab-org/gitlab/-/issues/325522),
-if you use an internal URL that is not accessible to the users, the
-OAuth authorization flow does not work properly, because users are redirected
-to the internal URL instead of the external one.
-
-## Multiple secondary sites behind a load balancer
-
-**Secondary** sites can use identical external URLs if
-a unique `name` is set for each Geo site. The `gitlab.rb` setting
-`gitlab_rails['geo_node_name']` must:
-
-- Be set for each GitLab instance that runs `puma`, `sidekiq`, or `geo_logcursor`.
-- Match a Geo site name.
-
-The load balancer must use sticky sessions to avoid authentication
-failures and cross-site request errors.
-
-<!-- ## Troubleshooting
-
-Include any troubleshooting steps that you can foresee. If you know beforehand what issues
-one might have when setting this up, or when something is changed, or on upgrading, it's
-important to describe those, too. Think of things that may go wrong and include them here.
-This is important to minimize requests for support, and to avoid doc comments with
-questions that you know someone might ask.
-
-Each scenario can be a third-level heading, e.g. `### Getting error message X`.
-If you have none to add when creating a doc, leave this section in place
-but commented out to help encourage others to add to it in the future. -->
+<!-- This redirect file can be deleted after <2022-10-05>. -->
+<!-- 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 (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/user/admin_area/geo_sites.md b/doc/user/admin_area/geo_sites.md
new file mode 100644
index 00000000000..e577fdf60f1
--- /dev/null
+++ b/doc/user/admin_area/geo_sites.md
@@ -0,0 +1,117 @@
+---
+stage: Systems
+group: Geo
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
+---
+
+# Geo sites Admin Area **(PREMIUM SELF)**
+
+You can configure various settings for GitLab Geo sites. For more information, see
+[Geo documentation](../../administration/geo/index.md).
+
+On either the primary or secondary site:
+
+1. On the top bar, select **Menu > Admin**.
+1. On the left sidebar, select **Geo > Sites**.
+
+## Common settings
+
+All Geo sites have the following settings:
+
+| Setting | Description |
+| --------| ----------- |
+| Primary | This marks a Geo site as **primary** site. There can be only one **primary** site. |
+| Name    | The unique identifier for the Geo site. It's highly recommended to use a physical location as a name. Good examples are "London Office" or "us-east-1". Avoid words like "primary", "secondary", "Geo", or "DR". This makes the failover process easier because the physical location does not change, but the Geo site role can. All nodes in a single Geo site use the same site name. Nodes use the `gitlab_rails['geo_node_name']` setting in `/etc/gitlab/gitlab.rb` to lookup their Geo site record in the PostgreSQL database. If `gitlab_rails['geo_node_name']` is not set, the node's `external_url` with trailing slash is used as fallback. The value of `Name` is case-sensitive, and most characters are allowed. |
+| URL     | The instance's user-facing URL. |
+
+The site you're currently browsing is indicated with a blue `Current` label, and
+the **primary** node is listed first as `Primary site`.
+
+## Secondary site settings
+
+**Secondary** sites have a number of additional settings available:
+
+| Setting                   | Description |
+|---------------------------|-------------|
+| Selective synchronization | Enable Geo [selective sync](../../administration/geo/replication/configuration.md#selective-synchronization) for this **secondary** site. |
+| Repository sync capacity  | Number of concurrent requests this **secondary** site makes to the **primary** site when backfilling repositories. |
+| File sync capacity        | Number of concurrent requests this **secondary** site makes to the **primary** site when backfilling files. |
+
+## Geo backfill
+
+**Secondary** sites are notified of changes to repositories and files by the **primary** site,
+and always attempt to synchronize those changes as quickly as possible.
+
+Backfill is the act of populating the **secondary** site with repositories and files that
+existed *before* the **secondary** site was added to the database. Because there may be
+extremely large numbers of repositories and files, it's not feasible to attempt to
+download them all at once; so, GitLab places an upper limit on the concurrency of
+these operations.
+
+How long the backfill takes is dependent on the maximum concurrency, but higher
+values place more strain on the **primary** site. The limits are configurable.
+If your **primary** site has lots of surplus capacity,
+you can increase the values to complete backfill in a shorter time. If it's
+under heavy load and backfill reduces its availability for normal requests,
+you can decrease them.
+
+## Set up the internal URLs
+
+> Setting up internal URLs in secondary sites was [introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/77179) in GitLab 14.7.
+
+You can set up a different URL for synchronization between the primary and secondary site.
+
+The **primary** site's Internal URL is used by **secondary** sites to contact it
+(to sync repositories, for example). The name Internal URL distinguishes it from
+[External URL](https://docs.gitlab.com/omnibus/settings/configuration.html#configuring-the-external-url-for-gitlab),
+which is used by users. Internal URL does not need to be a private address.
+
+When [Geo secondary proxying](../../administration/geo/secondary_proxy/index.md) is enabled,
+the primary uses the secondary's internal URL to contact it directly.
+
+The internal URL defaults to external URL. To change it:
+
+1. On the top bar, select **Menu > Admin**.
+1. On the left sidebar, select **Geo > Sites**.
+1. Select **Edit** on the site you want to customize.
+1. Edit the internal URL.
+1. Select **Save changes**.
+
+When enabled, the Admin Area for Geo shows replication details for each site directly
+from the primary site's UI, and through the Geo secondary proxy, if enabled.
+
+WARNING:
+We recommend using an HTTPS connection while configuring the Geo sites. To avoid
+breaking communication between **primary** and **secondary** sites when using
+HTTPS, customize your Internal URL to point to a load balancer with TLS
+terminated at the load balancer.
+
+WARNING:
+Starting with GitLab 13.3 and [until 13.11](https://gitlab.com/gitlab-org/gitlab/-/issues/325522),
+if you use an internal URL that is not accessible to the users, the
+OAuth authorization flow does not work properly, because users are redirected
+to the internal URL instead of the external one.
+
+## Multiple secondary sites behind a load balancer
+
+**Secondary** sites can use identical external URLs if
+a unique `name` is set for each Geo site. The `gitlab.rb` setting
+`gitlab_rails['geo_node_name']` must:
+
+- Be set for each GitLab instance that runs `puma`, `sidekiq`, or `geo_logcursor`.
+- Match a Geo site name.
+
+The load balancer must use sticky sessions to avoid authentication
+failures and cross-site request errors.
+
+<!-- ## Troubleshooting
+
+Include any troubleshooting steps that you can foresee. If you know beforehand what issues
+one might have when setting this up, or when something is changed, or on upgrading, it's
+important to describe those, too. Think of things that may go wrong and include them here.
+This is important to minimize requests for support, and to avoid doc comments with
+questions that you know someone might ask.
+
+Each scenario can be a third-level heading, e.g. `### Getting error message X`.
+If you have none to add when creating a doc, leave this section in place
+but commented out to help encourage others to add to it in the future. -->
diff --git a/doc/user/admin_area/index.md b/doc/user/admin_area/index.md
index 0480757f991..f8867638be1 100644
--- a/doc/user/admin_area/index.md
+++ b/doc/user/admin_area/index.md
@@ -33,7 +33,7 @@ The Admin Area is made up of the following sections:
 | **{license}** License                          | Add, display, and remove [licenses](license.md). |
 | **{cloud-gear}** Kubernetes                    | Create and manage instance-level [Kubernetes clusters](../instance/clusters/index.md). |
 | **{push-rules}** Push rules | Configure pre-defined Git [push rules](../project/repository/push_rules.md) for projects. Also, configure [merge requests approvers rules](merge_requests_approvals.md). |
-| **{location-dot}** Geo                         | Configure and maintain [Geo nodes](geo_nodes.md). |
+| **{location-dot}** Geo                         | Configure and maintain [Geo sites](geo_sites.md). |
 | **{key}** Deploy keys                          | Create instance-wide [SSH deploy keys](../project/deploy_keys/index.md). |
 | **{lock}** Credentials                         | View [credentials](credentials_inventory.md) that can be used to access your instance. |
 | **{template}** Integrations                    | Manage [instance-level default settings](settings/project_integration_management.md) for a project integration. |
diff --git a/doc/user/profile/account/two_factor_authentication.md b/doc/user/profile/account/two_factor_authentication.md
index 2dbeaae2267..4563cfe5648 100644
--- a/doc/user/profile/account/two_factor_authentication.md
+++ b/doc/user/profile/account/two_factor_authentication.md
@@ -59,11 +59,12 @@ To enable 2FA with a one-time password:
    1. Select **Enable Two-factor Authentication**.
 1. **On your device (usually your phone):**
    1. Install a compatible application. For example:
+      - [Aegis](https://getaegis.app/)
+      - [Raivo OTP](https://apps.apple.com/us/app/raivo-otp/id1459042137#platform=iphone)
       - [Authy](https://authy.com/)
       - [Duo Mobile](https://duo.com/product/multi-factor-authentication-mfa/duo-mobile-app)
       - [LastPass Authenticator](https://lastpass.com/auth/)
       - [Authenticator](https://mattrubin.me/authenticator/)
-      - [andOTP](https://github.com/andOTP/andOTP)
       - [Google Authenticator](https://support.google.com/accounts/answer/1066447?hl=en)
       - [Microsoft Authenticator](https://www.microsoft.com/en-us/security/mobile-authenticator-app)
       - [SailOTP](https://openrepos.net/content/seiichiro0185/sailotp)