Add latest changes from gitlab-org/gitlab@master

8 files changed, 103 insertions, 101 deletions

diff --git a/doc/administration/geo/index.md b/doc/administration/geo/index.md
index fc9df4c9039..685a0f6319d 100644
--- a/doc/administration/geo/index.md
+++ b/doc/administration/geo/index.md
@@ -53,8 +53,7 @@ Geo provides:
 ### Gitaly Cluster
 
 Geo should not be confused with [Gitaly Cluster](../gitaly/praefect.md). For more information about
-the difference between Geo and Gitaly Cluster, see
-[How does Gitaly Cluster compare to Geo?](../gitaly/faq.md#how-does-gitaly-cluster-compare-to-geo).
+the difference between Geo and Gitaly Cluster, see [Comparison to Geo](../gitaly/index.md#comparison-to-geo).
 
 ## How it works
 
diff --git a/doc/administration/gitaly/faq.md b/doc/administration/gitaly/faq.md
index a5c2c7d1469..f6571295200 100644
--- a/doc/administration/gitaly/faq.md
+++ b/doc/administration/gitaly/faq.md
@@ -1,90 +1,6 @@
 ---
-stage: Create
-group: Gitaly
-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: 'index.md'
+remove_date: '2022-08-24'
 ---
 
-# Frequently asked questions **(FREE SELF)**
-
-The following are answers to frequently asked questions about Gitaly and Gitaly Cluster. For
-troubleshooting information, see [Troubleshooting Gitaly and Gitaly Cluster](troubleshooting.md).
-
-## How does Gitaly Cluster compare to Geo?
-
-Gitaly Cluster and [Geo](../geo/index.md) both provide redundancy. However the redundancy of:
-
-- Gitaly Cluster provides fault tolerance for data storage and is invisible to the user. Users are
-  not aware when Gitaly Cluster is used.
-- Geo provides [replication](../geo/index.md) and [disaster recovery](../geo/disaster_recovery/index.md) for
-  an entire instance of GitLab. Users know when they are using Geo for
-  [replication](../geo/index.md). Geo [replicates multiple data types](../geo/replication/datatypes.md#limitations-on-replicationverification),
-  including Git data.
-
-The following table outlines the major differences between Gitaly Cluster and Geo:
-
-| Tool           | Nodes    | Locations | Latency tolerance                                                                                     | Failover                                                                    | Consistency                           | Provides redundancy for |
-|:---------------|:---------|:----------|:------------------------------------------------------------------------------------------------------|:----------------------------------------------------------------------------|:--------------------------------------|:------------------------|
-| Gitaly Cluster | Multiple | Single    | [Less than 1 second, ideally single-digit milliseconds](praefect.md#network-latency-and-connectivity) | [Automatic](praefect.md#automatic-failover-and-primary-election-strategies) | [Strong](index.md#strong-consistency) | Data storage in Git     |
-| Geo            | Multiple | Multiple  | Up to one minute                                                                                      | [Manual](../geo/disaster_recovery/index.md)                                 | Eventual                              | Entire GitLab instance  |
-
-For more information, see:
-
-- Geo [use cases](../geo/index.md#use-cases).
-- Geo [architecture](../geo/index.md#architecture).
-
-## Are there instructions for migrating to Gitaly Cluster?
-
-Yes! For more information, see [Migrating to Gitaly Cluster](index.md#migrating-to-gitaly-cluster).
-
-## What are some repository storage recommendations?
-
-The size of the required storage can vary between instances and depends on the set
-[replication factor](index.md#replication-factor). You might want to include implementing
-repository storage redundancy.
-
-For a replication factor:
-
-- Of `1`: NFS, Gitaly, and Gitaly Cluster have roughly the same storage requirements.
-- More than `1`: The amount of required storage is `used space * replication factor`. `used space`
-  should include any planned future growth.
-
-## What are some Praefect database storage requirements?
-
-The requirements are relatively low because the database contains only metadata of:
-
-- Where repositories are located.
-- Some queued work.
-
-It depends on the number of repositories, but a useful minimum is 5-10 GB, similar to the main
-GitLab application database.
-
-## Can the GitLab application database and the Praefect database be on the same servers?
-
-Yes, however Praefect should have it's own database server when using Omnibus GitLab PostgreSQL. If
-there is a failover, Praefect isn't aware and starts to fail as the database it's trying to use would
-either:
-
-- Be unavailable.
-- In read-only mode.
-
-A future solution may allow for Praefect and Omnibus GitLab databases on the same PostgreSQL server.
-For more information, see the relevant:
-
-- [Omnibus GitLab issue](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/5919).
-- [Gitaly issue](https://gitlab.com/gitlab-org/gitaly/-/issues/3398).
-
-## Is PgBouncer required for the Praefect database?
-
-No, because the number of connections Praefect makes is low. You can use the same PgBouncer instance
-for both the GitLab application database and the Praefect database if you wish.
-
-## Are there any special considerations for Gitaly Cluster when PostgreSQL is upgraded?
-
-There are no special requirements. Gitaly Cluster requires PostgreSQL version 11 or later.
-
-## Praefect database tables are empty?
-
-These tables are created per the [specific configuration section](praefect.md#postgresql).
-
-If you find you have an empty Praefect database table, see the
-[relevant troubleshooting section](troubleshooting.md#relation-does-not-exist-errors).
+This document was moved to [another location](index.md).
diff --git a/doc/administration/gitaly/index.md b/doc/administration/gitaly/index.md
index ee6224dc5ea..401b37dcd5a 100644
--- a/doc/administration/gitaly/index.md
+++ b/doc/administration/gitaly/index.md
@@ -206,6 +206,29 @@ WARNING:
 If complete cluster failure occurs, disaster recovery plans should be executed. These can affect the
 RPO and RTO discussed above.
 
+### Comparison to Geo
+
+Gitaly Cluster and [Geo](../geo/index.md) both provide redundancy. However the redundancy of:
+
+- Gitaly Cluster provides fault tolerance for data storage and is invisible to the user. Users are
+  not aware when Gitaly Cluster is used.
+- Geo provides [replication](../geo/index.md) and [disaster recovery](../geo/disaster_recovery/index.md) for
+  an entire instance of GitLab. Users know when they are using Geo for
+  [replication](../geo/index.md). Geo [replicates multiple data types](../geo/replication/datatypes.md#limitations-on-replicationverification),
+  including Git data.
+
+The following table outlines the major differences between Gitaly Cluster and Geo:
+
+| Tool           | Nodes    | Locations | Latency tolerance                                                                                     | Failover                                                                    | Consistency                           | Provides redundancy for |
+|:---------------|:---------|:----------|:------------------------------------------------------------------------------------------------------|:----------------------------------------------------------------------------|:--------------------------------------|:------------------------|
+| Gitaly Cluster | Multiple | Single    | [Less than 1 second, ideally single-digit milliseconds](praefect.md#network-latency-and-connectivity) | [Automatic](praefect.md#automatic-failover-and-primary-election-strategies) | [Strong](index.md#strong-consistency) | Data storage in Git     |
+| Geo            | Multiple | Multiple  | Up to one minute                                                                                      | [Manual](../geo/disaster_recovery/index.md)                                 | Eventual                              | Entire GitLab instance  |
+
+For more information, see:
+
+- Geo [use cases](../geo/index.md#use-cases).
+- Geo [architecture](../geo/index.md#architecture).
+
 ### Virtual storage
 
 Virtual storage makes it viable to have a single repository storage in GitLab to simplify repository
@@ -501,7 +524,7 @@ See the [Before deploying Gitaly Cluster](#before-deploying-gitaly-cluster) sect
 for migrating to Gitaly Cluster involves:
 
 1. Create the required storage. Refer to
-   [repository storage recommendations](faq.md#what-are-some-repository-storage-recommendations).
+   [repository storage recommendations](praefect.md#repository-storage-recommendations).
 1. Create and configure [Gitaly Cluster](praefect.md).
 1. [Move the repositories](../operations/moving_repositories.md#move-repositories). To migrate to
    Gitaly Cluster, existing repositories stored outside Gitaly Cluster must be moved. There is no
diff --git a/doc/administration/gitaly/praefect.md b/doc/administration/gitaly/praefect.md
index ccbaceca2f3..395b6c161e2 100644
--- a/doc/administration/gitaly/praefect.md
+++ b/doc/administration/gitaly/praefect.md
@@ -54,7 +54,7 @@ Achieving acceptable latency between Gitaly nodes:
   are designed for this type of synchronization. Latency of less than 2ms should be sufficient for Gitaly Cluster.
 
 If you can't provide low network latencies for replication (for example, between distant locations), consider Geo. For
-more information, see [How does Gitaly Cluster compare to Geo](faq.md#how-does-gitaly-cluster-compare-to-geo).
+more information, see [Comparison to Geo](index.md#comparison-to-geo).
 
 Gitaly Cluster [components](index.md#components) communicate with each other over many routes. Your firewall rules must
 allow the following for Gitaly Cluster to function properly:
@@ -74,6 +74,16 @@ Gitaly does not directly connect to Praefect. However, requests from Gitaly to t
 load balancer may still be blocked unless firewalls on the Praefect nodes allow traffic from
 the Gitaly nodes.
 
+### Praefect database storage
+
+The requirements are relatively low because the database contains only metadata of:
+
+- Where repositories are located.
+- Some queued work.
+
+It depends on the number of repositories, but a useful minimum is 5-10 GB, similar to the main
+GitLab application database.
+
 ## Setup Instructions
 
 If you [installed](https://about.gitlab.com/install/) GitLab using the Omnibus GitLab package
@@ -168,6 +178,18 @@ The following options are available:
   - Use a cloud-managed PostgreSQL service. AWS
      [Relational Database Service](https://aws.amazon.com/rds/) is recommended.
 
+Setting up PostgreSQL creates empty Praefect tables. For more information, see the
+[relevant troubleshooting section](troubleshooting.md#relation-does-not-exist-errors).
+
+#### Running GitLab and Praefect databases on the same server
+
+The GitLab application database and the Praefect database can be run on the same server. However, Praefect should have
+its own database server when using Omnibus GitLab PostgreSQL. If there is a failover, Praefect isn't aware and starts to
+fail as the database it's trying to use would either:
+
+- Be unavailable.
+- In read-only mode.
+
 #### Manual database setup
 
 To complete this section you need:
@@ -278,8 +300,12 @@ reads distribution caching is enabled by configuration
 #### Use PgBouncer
 
 To reduce PostgreSQL resource consumption, we recommend setting up and configuring
-[PgBouncer](https://www.pgbouncer.org/) in front of the PostgreSQL instance. To do
-this, you must point Praefect to PgBouncer by setting database parameters on Praefect configuration:
+[PgBouncer](https://www.pgbouncer.org/) in front of the PostgreSQL instance. However, PgBouncer isn't required because
+Praefect makes a low number of connections. If you choose to use PgBouncer, you can use the same PgBouncer instance for
+both the GitLab application database and the Praefect database.
+
+To configure PgBouncer in front of the PostgreSQL instance, you must point Praefect to PgBouncer by setting database
+parameters on Praefect configuration:
 
 ```ruby
 praefect['database_host'] = PGBOUNCER_HOST
@@ -1221,6 +1247,18 @@ You can configure:
 If `default_replication_factor` is unset, the repositories are always replicated on every node defined in `virtual_storages`. If a new
 node is introduced to the virtual storage, both new and existing repositories are replicated to the node automatically.
 
+### Repository storage recommendations
+
+The size of the required storage can vary between instances and depends on the set
+[replication factor](index.md#replication-factor). You might want to include implementing
+repository storage redundancy.
+
+For a replication factor:
+
+- Of `1`: NFS, Gitaly, and Gitaly Cluster have roughly the same storage requirements.
+- More than `1`: The amount of required storage is `used space * replication factor`. `used space`
+  should include any planned future growth.
+
 ## Repository verification
 
 > [Introduced](https://gitlab.com/gitlab-org/gitaly/-/issues/4080) in GitLab 15.0.
diff --git a/doc/administration/gitaly/troubleshooting.md b/doc/administration/gitaly/troubleshooting.md
index c79ed1d1707..da3882658e5 100644
--- a/doc/administration/gitaly/troubleshooting.md
+++ b/doc/administration/gitaly/troubleshooting.md
@@ -8,9 +8,6 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 Refer to the information below when troubleshooting Gitaly and Gitaly Cluster.
 
-Before troubleshooting, see the Gitaly and Gitaly Cluster
-[frequently asked questions](faq.md).
-
 ## Troubleshoot Gitaly
 
 The following sections provide possible solutions to Gitaly errors.
diff --git a/doc/api/graphql/reference/index.md b/doc/api/graphql/reference/index.md
index 6c260036931..0d957ed2d53 100644
--- a/doc/api/graphql/reference/index.md
+++ b/doc/api/graphql/reference/index.md
@@ -17868,6 +17868,7 @@ Represents vulnerability letter grades with associated projects.
 | <a id="workitemtitle"></a>`title` | [`String!`](#string) | Title of the work item. |
 | <a id="workitemtitlehtml"></a>`titleHtml` | [`String`](#string) | The GitLab Flavored Markdown rendering of `title`. |
 | <a id="workitemuserpermissions"></a>`userPermissions` | [`WorkItemPermissions!`](#workitempermissions) | Permissions for the current user on the resource. |
+| <a id="workitemwidgets"></a>`widgets` | [`[WorkItemWidget!]`](#workitemwidget) | Collection of widgets that belong to the work item. |
 | <a id="workitemworkitemtype"></a>`workItemType` | [`WorkItemType!`](#workitemtype) | Type assigned to the work item. |
 
 ### `WorkItemPermissions`
@@ -17892,6 +17893,18 @@ Check permissions for the current user on a work item.
 | <a id="workitemtypeid"></a>`id` | [`WorkItemsTypeID!`](#workitemstypeid) | Global ID of the work item type. |
 | <a id="workitemtypename"></a>`name` | [`String!`](#string) | Name of the work item type. |
 
+### `WorkItemWidgetDescription`
+
+Represents a description widget.
+
+#### Fields
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="workitemwidgetdescriptiondescription"></a>`description` | [`String`](#string) | Description of the work item. |
+| <a id="workitemwidgetdescriptiondescriptionhtml"></a>`descriptionHtml` | [`String`](#string) | The GitLab Flavored Markdown rendering of `description`. |
+| <a id="workitemwidgetdescriptiontype"></a>`type` | [`WorkItemWidgetType`](#workitemwidgettype) | Widget type. |
+
 ## Enumeration types
 
 Also called _Enums_, enumeration types are a special kind of scalar that
@@ -19636,6 +19649,14 @@ Values for work item state events.
 | <a id="workitemstateeventclose"></a>`CLOSE` | Closes the work item. |
 | <a id="workitemstateeventreopen"></a>`REOPEN` | Reopens the work item. |
 
+### `WorkItemWidgetType`
+
+Type of a work item widget.
+
+| Value | Description |
+| ----- | ----------- |
+| <a id="workitemwidgettypedescription"></a>`DESCRIPTION` | Description widget. |
+
 ## Scalar types
 
 Scalar values are atomic values, and do not have fields of their own.
@@ -20831,6 +20852,18 @@ four standard [pagination arguments](#connection-pagination-arguments):
 | <a id="usertodosstate"></a>`state` | [`[TodoStateEnum!]`](#todostateenum) | State of the todo. |
 | <a id="usertodostype"></a>`type` | [`[TodoTargetEnum!]`](#todotargetenum) | Type of the todo. |
 
+#### `WorkItemWidget`
+
+Implementations:
+
+- [`WorkItemWidgetDescription`](#workitemwidgetdescription)
+
+##### Fields
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="workitemwidgettype"></a>`type` | [`WorkItemWidgetType`](#workitemwidgettype) | Widget type. |
+
 ## Input types
 
 Types that may be used as arguments (all scalar types may also
diff --git a/doc/development/database/migrations_for_multiple_databases.md b/doc/development/database/migrations_for_multiple_databases.md
index 68410535d57..023b28ce6a6 100644
--- a/doc/development/database/migrations_for_multiple_databases.md
+++ b/doc/development/database/migrations_for_multiple_databases.md
@@ -13,11 +13,6 @@ for [the decomposed GitLab application using multiple databases](https://gitlab.
 
 Learn more about general multiple databases support in a [separate document](multiple_databases.md).
 
-WARNING:
-If you experience any issues using `Gitlab::Database::Migration[2.0]`,
-you can temporarily revert back to the previous behavior by changing the version to `Gitlab::Database::Migration[1.0]`.
-Please report any issues with `Gitlab::Database::Migration[2.0]` in [this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/358430).
-
 The design for multiple databases (except for the Geo database) assumes
 that all decomposed databases have **the same structure** (for example, schema), but **the data is different** in each database. This means that some tables do not contain data on each database.
 
diff --git a/doc/user/search/index.md b/doc/user/search/index.md
index 9cec9cb3316..41e33583a9a 100644
--- a/doc/user/search/index.md
+++ b/doc/user/search/index.md
@@ -42,6 +42,7 @@ in the search field in the upper right corner:
 > - Filtering by iterations was moved from GitLab Ultimate to GitLab Premium in 13.9.
 > - Filtering by type was [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/322755) in GitLab 13.10 [with a flag](../../administration/feature_flags.md) named `vue_issues_list`. Disabled by default.
 > - Filtering by type was [enabled on self-managed](https://gitlab.com/gitlab-org/gitlab/-/issues/322755) in GitLab 14.10.
+> - Filtering by type is generally available in GitLab 15.1. [Feature flag `vue_issues_list`](https://gitlab.com/gitlab-org/gitlab/-/issues/359966) removed.
 > - Filtering by attention request was [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/343528) in GitLab 14.10 [with a flag](../../administration/feature_flags.md) named `mr_attention_requests`. Disabled by default.
 
 Follow these steps to filter the **Issues** and **Merge requests** list pages in projects and