Add latest changes from gitlab-org/gitlab@master

7 files changed, 63 insertions, 64 deletions

diff --git a/doc/development/api_graphql_styleguide.md b/doc/development/api_graphql_styleguide.md
index 40cc8f5ec45..3c8d07610f0 100644
--- a/doc/development/api_graphql_styleguide.md
+++ b/doc/development/api_graphql_styleguide.md
@@ -940,7 +940,9 @@ class PostResolver < BaseResolver
 end
 ```
 
-You should never re-use resolvers directly. Resolvers have a complex life-cycle, with
+While you can use the same resolver class in two different places,
+such as in two different fields where the same object is exposed, 
+you should never re-use resolver objects directly. Resolvers have a complex life-cycle, with
 authorization, readiness and resolution orchestrated by the framework, and at
 each stage [lazy values](#laziness) can be returned to take advantage of batching
 opportunities. Never instantiate a resolver or a mutation in application code.
diff --git a/doc/development/code_review.md b/doc/development/code_review.md
index bbde7f4d976..28d02524dc7 100644
--- a/doc/development/code_review.md
+++ b/doc/development/code_review.md
@@ -10,7 +10,7 @@ This guide contains advice and best practices for performing code review, and
 having your code reviewed.
 
 All merge requests for GitLab CE and EE, whether written by a GitLab team member
-or a volunteer contributor, must go through a code review process to ensure the
+or a wider community member, must go through a code review process to ensure the
 code is effective, understandable, maintainable, and secure.
 
 ## Getting your merge request reviewed, approved, and merged
@@ -35,7 +35,7 @@ If you need assistance with security scans or comments, feel free to include the
 Application Security Team (`@gitlab-com/gl-security/appsec`) in the review.
 
 Depending on the areas your merge request touches, it must be **approved** by one
-or more [maintainers](https://about.gitlab.com/handbook/engineering/workflow/code-review/#maintainer):
+or more [maintainers](https://about.gitlab.com/handbook/engineering/workflow/code-review/#maintainer).
 
 For approvals, we use the approval functionality found in the merge request
 widget. For reviewers, we use the [reviewer functionality](../user/project/merge_requests/getting_started.md#reviewer) in the sidebar.
@@ -46,9 +46,11 @@ more than one approval, the last maintainer to review and approve merges it.
 
 ### Domain experts
 
-Domain experts are team members who have substantial experience with a specific technology, product feature or area of the codebase. Team members are encouraged to self-identify as domain experts and add it to their [team profile](https://gitlab.com/gitlab-com/www-gitlab-com/-/blob/master/data/team.yml).
+Domain experts are team members who have substantial experience with a specific technology,
+product feature, or area of the codebase. Team members are encouraged to self-identify as
+domain experts and add it to their [team profiles](https://gitlab.com/gitlab-com/www-gitlab-com/-/blob/master/data/team_members/person/README.md).
 
-When self-identifying as a domain expert, it is recommended to assign the MR changing the `team.yml` to be merged by an already established Domain Expert or a corresponding Engineering Manager.
+When self-identifying as a domain expert, it is recommended to assign the MR changing the `.yml` file to be merged by an already established Domain Expert or a corresponding Engineering Manager.
 
 We make the following assumption with regards to automatically being considered a domain expert:
 
@@ -117,11 +119,12 @@ with [domain expertise](#domain-experts).
 1. If your merge request includes documentation changes, it must be **approved
    by a [Technical writer](https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments)**,
    based on assignments in the appropriate [DevOps stage group](https://about.gitlab.com/handbook/product/categories/#devops-stages).
+1. If your merge request includes changes to development guidelines, follow the [review process](index.md#development-guidelines-review) and get the approvals accordingly.
 1. If your merge request includes end-to-end **and** non-end-to-end changes (*4*), it must be **approved
    by a [Software Engineer in Test](https://about.gitlab.com/handbook/engineering/quality/#individual-contributors)**.
 1. If your merge request only includes end-to-end changes (*4*) **or** if the MR author is a [Software Engineer in Test](https://about.gitlab.com/handbook/engineering/quality/#individual-contributors), it must be **approved by a [Quality maintainer](https://about.gitlab.com/handbook/engineering/projects/#gitlab_maintainers_qa)**
 1. If your merge request includes a new or updated [application limit](https://about.gitlab.com/handbook/product/product-processes/#introducing-application-limits), it must be **approved by a [product manager](https://about.gitlab.com/company/team/)**.
-1. If your merge request includes Product Intelligence (telemetry or analytics) changes, it should be reviewed and approved by a [Product Intelligence engineer](https://gitlab.com/gitlab-org/growth/product_intelligence/engineers).
+1. If your merge request includes Product Intelligence (telemetry or analytics) changes, it should be reviewed and approved by a [Product Intelligence engineer](https://gitlab.com/gitlab-org/growth/product-intelligence/engineers).
 1. If your merge request includes an addition of, or changes to a [Feature spec](testing_guide/testing_levels.md#frontend-feature-tests), it must be **approved by a [Quality maintainer](https://about.gitlab.com/handbook/engineering/projects/#gitlab_maintainers_qa) or [Quality reviewer](https://about.gitlab.com/handbook/engineering/projects/#gitlab_reviewers_qa)**.
 1. If your merge request introduces a new service to GitLab (Puma, Sidekiq, Gitaly are examples), it must be **approved by a [product manager](https://about.gitlab.com/company/team/)**. See the [process for adding a service component to GitLab](adding_service_component.md) for details.
 
@@ -142,7 +145,7 @@ View the updated documentation regarding [internal application security reviews]
 
 The responsibility to find the best solution and implement it lies with the
 merge request author. The author or [directly responsible individual](https://about.gitlab.com/handbook/people-group/directly-responsible-individuals/)
-will stay assigned to the merge request as the assignee throughout
+(DRI) stays assigned to the merge request as the assignee throughout
 the code review lifecycle. If you are unable to set yourself as an assignee, ask a [reviewer](https://about.gitlab.com/handbook/engineering/workflow/code-review/#reviewer) to do this for you.
 
 Before requesting a review from a maintainer to approve and merge, they
@@ -169,7 +172,7 @@ database specialists to get input on the data model or specific queries, or to
 any other developer to get an in-depth review of the solution.
 
 If an author is unsure if a merge request needs a [domain expert's](#domain-experts) opinion,
-that indicates it does. Without it it's unlikely they have the required level of confidence in their
+then that indicates it does. Without it, it's unlikely they have the required level of confidence in their
 solution.
 
 Before the review, the author is requested to submit comments on the merge
@@ -249,7 +252,7 @@ without duly verifying them.
 
 Note that certain Merge Requests may target a stable branch. These are rare
 events. These types of Merge Requests cannot be merged by the Maintainer.
-Instead these should be sent to the [Release Manager](https://about.gitlab.com/community/release-managers/).
+Instead, these should be sent to the [Release Manager](https://about.gitlab.com/community/release-managers/).
 
 After merging, a maintainer should stay as the reviewer listed on the merge request.
 
@@ -305,8 +308,8 @@ first time.
   codebase. Thorough descriptions help all reviewers understand your request
   and test effectively.
 - If you know your change depends on another being merged first, note it in the
-  description and set an [merge request dependency](../user/project/merge_requests/merge_request_dependencies.md).
-- Be grateful for the reviewer's suggestions. (`Good call. I'll make that change.`)
+  description and set a [merge request dependency](../user/project/merge_requests/merge_request_dependencies.md).
+- Be grateful for the reviewer's suggestions. ("Good call. I'll make that change.")
 - Don't take it personally. The review is of the code, not of you.
 - Explain why the code exists. ("It's like that because of these reasons. Would
   it be more clear if I rename this class/file/method/variable?")
@@ -425,13 +428,13 @@ WARNING:
 - Start a new merge request pipeline with the `Run pipeline` button in the merge
   request's "Pipelines" tab, and enable "Merge When Pipeline Succeeds" (MWPS).
   Note that:
-  - If **[main is broken](https://about.gitlab.com/handbook/engineering/workflow/#broken-master),
+  - If **[the default branch is broken](https://about.gitlab.com/handbook/engineering/workflow/#broken-master),
     do not merge the merge request** except for
     [very specific cases](https://about.gitlab.com/handbook/engineering/workflow/#criteria-for-merging-during-broken-master).
     For other cases, follow these [handbook instructions](https://about.gitlab.com/handbook/engineering/workflow/#merging-during-broken-master).
   - If the latest pipeline was created before the merge request was approved, start a new pipeline to ensure that full RSpec suite has been run. You may skip this step only if the merge request does not contain any backend change.
   - If the **latest [Pipeline for Merged Results](../ci/pipelines/pipelines_for_merged_results.md)** finished less than 2 hours ago, you
-    might merge without starting a new pipeline as the merge request is close
+    may merge without starting a new pipeline as the merge request is close
     enough to `main`.
 - When you set the MR to "Merge When Pipeline Succeeds", you should take over
   subsequent revisions for anything that would be spotted after that.
@@ -650,7 +653,3 @@ A good example of collaboration on an MR touching multiple parts of the codebase
 ### Credits
 
 Largely based on the [`thoughtbot` code review guide](https://github.com/thoughtbot/guides/tree/master/code-review).
-
----
-
-[Return to Development documentation](index.md)
diff --git a/doc/install/aws/gitlab_hybrid_on_aws.md b/doc/install/aws/gitlab_hybrid_on_aws.md
index f35f942c613..94365575d31 100644
--- a/doc/install/aws/gitlab_hybrid_on_aws.md
+++ b/doc/install/aws/gitlab_hybrid_on_aws.md
@@ -148,11 +148,11 @@ If EKS node autoscaling is employed, it is likely that your average loading will
 | **Bastion Host (Quick Start)**                               | 1 HA instance in ASG                                         | **t2.micro** for prod, **m4.2xlarge** for perf. testing |                                 |                                                      |
 | **PostgreSQL**<br />AWS Aurora RDS Nodes Configuration (GPT tested) | 2vCPU, 7.5 GB<br />Tested with Graviton ARM                  | **db.r6g.large** x 3 nodes <br />(6vCPU, 48 GB)         | 3 nodes x $0.26 = $0.78/hr      | 3 nodes x $0.26 = $0.78/hr<br />(Aurora is always 3) |
 | **Redis**                                                    | 1vCPU, 3.75GB<br />(across 12 nodes for Redis Cache, Redis Queues/Shared State, Sentinel Cache, Sentinel Queues/Shared State) | **cache.m6g.large** x 3 nodes<br />(6vCPU, 19GB)        | 3 nodes x $0.15 = $0.45/hr      | 2 nodes x $0.15 = $0.30/hr                           |
-| **<u>Gitaly Cluster</u>** [Details](gitaly_on_aws.md)        | [Gitaly & Praefect Must Have an Uneven Node Count for HA](gitaly_on_aws.md#gitaly-and-praefect-elections) |                                                         |                                 |                                                      |
+| **<u>Gitaly Cluster</u>** [Details](gitlab_sre_for_aws.md#gitaly-sre-considerations) | [Gitaly & Praefect Must Have an Uneven Node Count for HA](gitlab_sre_for_aws.md#gitaly-and-praefect-elections) |                                                         |                                 |                                                      |
 | Gitaly Instances (in ASG)                                    | 12 vCPU, 45GB<br />(across 3 nodes)                          | **m5.xlarge** x 3 nodes<br />(48 vCPU, 180 GB)          | $0.192 x 3 = $0.58/hr           | $0.192 x 3 = $0.58/hr                                |
 |                                                              | The GitLab Reference architecture for 2K is not Highly Available and therefore has a single Gitaly no Praefect. AWS Quick Starts MUST be HA, so it implements Prafect from the 3K Ref Architecture to meet that requirement |                                                         |                                 |                                                      |
-| Praefect (Instances in ASG with load balancer)               | 6 vCPU, 10 GB<br />(across 3 nodes)                          | **c5.large** x 3 nodes<br />(6 vCPU, 12 GB)             | $0.09 x 3 = $0.21/hr            | $0.09 x 3 = $0.21/hr                                 |
-| Praefect PostgreSQL(1) (AWS RDS)                             | 6 vCPU, 5.4 GB<br />(across 3 nodes)                         | N/A Reuses GitLab PostgreSQL                            | $0                              | $0                                                   |
+| Praefect (Instances in ASG with load balancer)               | 6 vCPU, 10 GB<br />([across 3 nodes](gitlab_sre_for_aws.md#gitaly-and-praefect-elections)) | **c5.large** x 3 nodes<br />(6 vCPU, 12 GB)             | $0.09 x 3 = $0.21/hr            | $0.09 x 3 = $0.21/hr                                 |
+| Praefect PostgreSQL(1) (AWS RDS)                             | 6 vCPU, 5.4 GB<br />([across 3 nodes](gitlab_sre_for_aws.md#gitaly-and-praefect-elections)) | N/A Reuses GitLab PostgreSQL                            | $0                              | $0                                                   |
 | Internal Load Balancing Node                                 | 2 vCPU, 1.8 GB                                               | AWS ELB                                                 | $0.10/hr                        | $0.10/hr                                             |
 
 ### 3K Cloud Native Hybrid on EKS
@@ -200,10 +200,10 @@ If EKS node autoscaling is employed, it is likely that your average loading will
 | **Bastion Host (Quick Start)**                               | 1 HA instance in ASG                                         | **t2.micro** for prod, **m4.2xlarge** for perf. testing |                                 |                                                              |
 | **PostgreSQL**<br />AWS Aurora RDS Nodes Configuration (GPT tested) | 18vCPU, 36 GB <br />(across 9 nodes for PostgreSQL, PgBouncer, Consul)<br />Tested with Graviton ARM | **db.r6g.xlarge** x 3 nodes <br />(12vCPU, 96 GB)       | 3 nodes x $0.52 = $1.56/hr      | 3 nodes x $0.52 = $1.56/hr<br />(Aurora is always 3)         |
 | **Redis**                                                    | 6vCPU, 18GB<br />(across 6 nodes for Redis Cache, Sentinel)  | **cache.m6g.large** x 3 nodes<br />(6vCPU, 19GB)        | 3 nodes x $0.15 = $0.45/hr      | 2 nodes x $0.15 = $0.30/hr                                   |
-| **<u>Gitaly Cluster</u>** [Details](gitaly_on_aws.md)        |                                                              |                                                         |                                 |                                                              |
-| Gitaly Instances (in ASG)                                    | 12 vCPU, 45GB<br />(across 3 nodes)                          | **m5.large** x 3 nodes<br />(12 vCPU, 48 GB)            | $0.192 x 3 = $0.58/hr           | [Gitaly & Praefect Must Have an Uneven Node Count for HA](gitaly_on_aws.md#gitaly-and-praefect-elections) |
-| Praefect (Instances in ASG with load balancer)               | 6 vCPU, 5.4 GB<br />(across 3 nodes)                         | **c5.large** x 3 nodes<br />(6 vCPU, 12 GB)             | $0.09 x 3 = $0.21/hr            | [Gitaly & Praefect Must Have an Uneven Node Count for HA](gitaly_on_aws.md#gitaly-and-praefect-elections) |
-| Praefect PostgreSQL(1) (AWS RDS)                             | 6 vCPU, 5.4 GB<br />(across 3 nodes)                         | N/A Reuses GitLab PostgreSQL                            | $0                              |                                                              |
+| **<u>Gitaly Cluster</u>** [Details](gitlab_sre_for_aws.md#gitaly-sre-considerations)   |                                                              |                                                         |                                 |                                                              |
+| Gitaly Instances (in ASG)                                    | 12 vCPU, 45GB<br />([across 3 nodes](gitlab_sre_for_aws.md#gitaly-and-praefect-elections)) | **m5.large** x 3 nodes<br />(12 vCPU, 48 GB)            | $0.192 x 3 = $0.58/hr           | [Gitaly & Praefect Must Have an Uneven Node Count for HA](gitlab_sre_for_aws.md#gitaly-and-praefect-elections) |
+| Praefect (Instances in ASG with load balancer)               | 6 vCPU, 5.4 GB<br />([across 3 nodes](gitlab_sre_for_aws.md#gitaly-and-praefect-elections)) | **c5.large** x 3 nodes<br />(6 vCPU, 12 GB)             | $0.09 x 3 = $0.21/hr            | [Gitaly & Praefect Must Have an Uneven Node Count for HA](gitlab_sre_for_aws.md#gitaly-and-praefect-elections) |
+| Praefect PostgreSQL(1) (AWS RDS)                             | 6 vCPU, 5.4 GB<br />([across 3 nodes](gitlab_sre_for_aws.md#gitaly-and-praefect-elections)) | N/A Reuses GitLab PostgreSQL                            | $0                              |                                                              |
 | Internal Load Balancing Node                                 | 2 vCPU, 1.8 GB                                               | AWS ELB                                                 | $0.10/hr                        | $0.10/hr                                                     |
 
 ### 5K Cloud Native Hybrid on EKS
@@ -251,10 +251,10 @@ If EKS node autoscaling is employed, it is likely that your average loading will
 | **Bastion Host (Quick Start)**                               | 1 HA instance in ASG                                         | **t2.micro** for prod, **m4.2xlarge** for perf. testing |                                 |                                                              |
 | **PostgreSQL**<br />AWS Aurora RDS Nodes Configuration (GPT tested) | 21vCPU, 51 GB <br />(across 9 nodes for PostgreSQL, PgBouncer, Consul)<br />Tested with Graviton ARM | **db.r6g.2xlarge** x 3 nodes <br />(24vCPU, 192 GB)     | 3 nodes x $1.04 = $3.12/hr      | 3 nodes x $1.04 = $3.12/hr<br />(Aurora is always 3)         |
 | **Redis**                                                    | 9vCPU, 27GB<br />(across 6 nodes for Redis, Sentinel)        | **cache.m6g.xlarge** x 3 nodes<br />(12vCPU, 39GB)      | 3 nodes x $0.30 = $0.90/hr      | 2 nodes x $0.30 = $0.60/hr                                   |
-| **<u>Gitaly Cluster</u>** [Details](gitaly_on_aws.md)        |                                                              |                                                         |                                 |                                                              |
-| Gitaly Instances (in ASG)                                    | 24 vCPU, 90GB<br />(across 3 nodes)                          | **m5.2xlarge** x 3 nodes<br />(24 vCPU, 96GB)           | $0.384 x 3 = $1.15/hr           | [Gitaly & Praefect Must Have an Uneven Node Count for HA](gitaly_on_aws.md#gitaly-and-praefect-elections) |
-| Praefect (Instances in ASG with load balancer)               | 6 vCPU, 5.4 GB<br />(across 3 nodes)                         | **c5.large** x 3 nodes<br />(6 vCPU, 12 GB)             | $0.09 x 3 = $0.21/hr            | [Gitaly & Praefect Must Have an Uneven Node Count for HA](gitaly_on_aws.md#gitaly-and-praefect-elections) |
-| Praefect PostgreSQL(1) (AWS RDS)                             | 6 vCPU, 5.4 GB<br />(across 3 nodes)                         | N/A Reuses GitLab PostgreSQL                            | $0                              |                                                              |
+| **<u>Gitaly Cluster</u>** [Details](gitlab_sre_for_aws.md#gitaly-sre-considerations)   |                                                              |                                                         |                                 |                                                              |
+| Gitaly Instances (in ASG)                                    | 24 vCPU, 90GB<br />([across 3 nodes](gitlab_sre_for_aws.md#gitaly-and-praefect-elections)) | **m5.2xlarge** x 3 nodes<br />(24 vCPU, 96GB)           | $0.384 x 3 = $1.15/hr           | [Gitaly & Praefect Must Have an Uneven Node Count for HA](gitlab_sre_for_aws.md#gitaly-and-praefect-elections) |
+| Praefect (Instances in ASG with load balancer)               | 6 vCPU, 5.4 GB<br />([across 3 nodes](gitlab_sre_for_aws.md#gitaly-and-praefect-elections)) | **c5.large** x 3 nodes<br />(6 vCPU, 12 GB)             | $0.09 x 3 = $0.21/hr            | [Gitaly & Praefect Must Have an Uneven Node Count for HA](gitlab_sre_for_aws.md#gitaly-and-praefect-elections) |
+| Praefect PostgreSQL(1) (AWS RDS)                             | 6 vCPU, 5.4 GB<br />([across 3 nodes](gitlab_sre_for_aws.md#gitaly-and-praefect-elections)) | N/A Reuses GitLab PostgreSQL                            | $0                              |                                                              |
 | Internal Load Balancing Node                                 | 2 vCPU, 1.8 GB                                               | AWS ELB                                                 | $0.10/hr                        | $0.10/hr                                                     |
 
 ### 10K Cloud Native Hybrid on EKS
@@ -301,10 +301,10 @@ If EKS node autoscaling is employed, it is likely that your average loading will
 | **Bastion Host (Quick Start)** | 1 HA instance in ASG | **t2.micro** for prod, **m4.2xlarge** for perf. testing |  |  |
 | **PostgreSQL**<br />AWS Aurora RDS Nodes Configuration (GPT tested) | 36vCPU, 102 GB <br />(across 9 nodes for PostgreSQL, PgBouncer, Consul) | **db.r6g.2xlarge** x 3 nodes <br />(24vCPU, 192 GB) | 3 nodes x $1.04 = $3.12/hr | 3 nodes x $1.04 = $3.12/hr<br />(Aurora is always 3) |
 | **Redis** | 30vCPU, 114GB<br />(across 12 nodes for Redis Cache, Redis Queues/Shared State, Sentinel Cache, Sentinel Queues/Shared State) | **cache.m5.2xlarge** x 3 nodes<br />(24vCPU, 78GB) | 3 nodes x $0.62 = $1.86/hr | 2 nodes x $0.62 = $1.24/hr |
-| **<u>Gitaly Cluster</u>** [Details](gitaly_on_aws.md) |  |  |  |  |
-| Gitaly Instances (in ASG) | 48 vCPU, 180GB<br />(across 3 nodes) | **m5.4xlarge** x 3 nodes<br />(48 vCPU, 180 GB) | $0.77 x 3 = $2.31/hr | [Gitaly & Praefect Must Have an Uneven Node Count for HA](gitaly_on_aws.md#gitaly-and-praefect-elections) |
-| Praefect (Instances in ASG with load balancer) | 6 vCPU, 5.4 GB<br />(across 3 nodes) | **c5.large** x 3 nodes<br />(6 vCPU, 12 GB) | $0.09 x 3 = $0.21/hr | [Gitaly & Praefect Must Have an Uneven Node Count for HA](gitaly_on_aws.md#gitaly-and-praefect-elections) |
-| Praefect PostgreSQL(1) (AWS RDS) | 6 vCPU, 5.4 GB<br />(across 3 nodes) | N/A Reuses GitLab PostgreSQL | $0 |  |
+| **<u>Gitaly Cluster</u>** [Details](gitlab_sre_for_aws.md#gitaly-sre-considerations) |  |  |  |  |
+| Gitaly Instances (in ASG) | 48 vCPU, 180GB<br />([across 3 nodes](gitlab_sre_for_aws.md#gitaly-and-praefect-elections)) | **m5.4xlarge** x 3 nodes<br />(48 vCPU, 180 GB) | $0.77 x 3 = $2.31/hr | [Gitaly & Praefect Must Have an Uneven Node Count for HA](gitlab_sre_for_aws.md#gitaly-and-praefect-elections) |
+| Praefect (Instances in ASG with load balancer) | 6 vCPU, 5.4 GB<br />([across 3 nodes](gitlab_sre_for_aws.md#gitaly-and-praefect-elections)) | **c5.large** x 3 nodes<br />(6 vCPU, 12 GB) | $0.09 x 3 = $0.21/hr | [Gitaly & Praefect Must Have an Uneven Node Count for HA](gitlab_sre_for_aws.md#gitaly-and-praefect-elections) |
+| Praefect PostgreSQL(1) (AWS RDS) | 6 vCPU, 5.4 GB<br />([across 3 nodes](gitlab_sre_for_aws.md#gitaly-and-praefect-elections)) | N/A Reuses GitLab PostgreSQL | $0 |  |
 | Internal Load Balancing Node | 2 vCPU, 1.8 GB | AWS ELB | $0.10/hr | $0.10/hr |
 
 ### 50K Cloud Native Hybrid on EKS
@@ -351,10 +351,10 @@ If EKS node autoscaling is employed, it is likely that your average loading will
 | **Bastion Host (Quick Start)**                               | 1 HA instance in ASG                                         | **t2.micro** for prod, **m4.2xlarge** for perf. testing   |                                 |                                                              |
 | **PostgreSQL**<br />AWS Aurora RDS Nodes Configuration (GPT tested) | 96vCPU, 360 GB <br />(across 3 nodes)                        | **db.r6g.8xlarge** x 3 nodes <br />(96vCPU, 768 GB total) | 3 nodes x $4.15 = $12.45/hr     | 3 nodes x $4.15 = $12.45/hr<br />(Aurora is always 3)        |
 | **Redis**                                                    | 30vCPU, 114GB<br />(across 12 nodes for Redis Cache, Redis Queues/Shared State, Sentinel Cache, Sentinel Queues/Shared State) | **cache.m6g.2xlarge** x 3 nodes<br />(24vCPU, 78GB total) | 3 nodes x $0.60 = $1.80/hr      | 2 nodes x $0.60 = $1.20/hr                                   |
-| **<u>Gitaly Cluster</u>** [Details](gitaly_on_aws.md)        |                                                              |                                                           |                                 |                                                              |
-| Gitaly Instances (in ASG)                                    | 64 vCPU, 240GB x 3 nodes                                     | **m5.16xlarge** x 3 nodes<br />(64 vCPU, 256 GB each)     | $3.07 x 3 = $9.21/hr            | [Gitaly & Praefect Must Have an Uneven Node Count for HA](gitaly_on_aws.md#gitaly-and-praefect-elections) |
-| Praefect (Instances in ASG with load balancer)               | 4 vCPU, 3.6 GB x 3 nodes                                     | **c5.xlarge** x 3 nodes<br />(4 vCPU, 8 GB each)          | $0.17 x 3 = $0.51/hr            | [Gitaly & Praefect Must Have an Uneven Node Count for HA](gitaly_on_aws.md#gitaly-and-praefect-elections) |
-| Praefect PostgreSQL(1) (AWS RDS)                             | 2 vCPU, 1.8 GB x 3 nodes                                     | N/A Reuses GitLab PostgreSQL                              | $0                              |                                                              |
+| **<u>Gitaly Cluster</u>** [Details](gitlab_sre_for_aws.md#gitaly-sre-considerations)   |                                                              |                                                           |                                 |                                                              |
+| Gitaly Instances (in ASG)                                    | 64 vCPU, 240GB x [3 nodes](gitlab_sre_for_aws.md#gitaly-and-praefect-elections) | **m5.16xlarge** x 3 nodes<br />(64 vCPU, 256 GB each)     | $3.07 x 3 = $9.21/hr            | [Gitaly & Praefect Must Have an Uneven Node Count for HA](gitlab_sre_for_aws.md#gitaly-and-praefect-elections) |
+| Praefect (Instances in ASG with load balancer)               | 4 vCPU, 3.6 GB x [3 nodes](gitlab_sre_for_aws.md#gitaly-and-praefect-elections) | **c5.xlarge** x 3 nodes<br />(4 vCPU, 8 GB each)          | $0.17 x 3 = $0.51/hr            | [Gitaly & Praefect Must Have an Uneven Node Count for HA](gitlab_sre_for_aws.md#gitaly-and-praefect-elections) |
+| Praefect PostgreSQL(1) (AWS RDS)                             | 2 vCPU, 1.8 GB x [3 nodes](gitlab_sre_for_aws.md#gitaly-and-praefect-elections) | N/A Reuses GitLab PostgreSQL                              | $0                              |                                                              |
 | Internal Load Balancing Node                                 | 2 vCPU, 1.8 GB                                               | AWS ELB                                                   | $0.10/hr                        | $0.10/hr                                                     |
 
 ## Helpful Resources
diff --git a/doc/install/aws/gitaly_on_aws.md b/doc/install/aws/gitlab_sre_for_aws.md
index c4b292d5abf..a3a70dde618 100644
--- a/doc/install/aws/gitaly_on_aws.md
+++ b/doc/install/aws/gitlab_sre_for_aws.md
@@ -1,15 +1,25 @@
 ---
-type: reference, concepts
 stage: Enablement
 group: Alliances
 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
+comments: false
+description: Doing SRE for GitLab instances and runners on AWS.
+type: index
 ---
 
-# Gitaly SRE Considerations
+# GitLab Site Reliability Engineering for AWS
+
+## Known issues list
+
+Known issues are gathered from within GitLab and from customer reported issues. Customers successfully implement GitLab with a variety of "as a Service" components that GitLab has not specifically been designed for, nor has ongoing testing for. While GitLab does take partner technologies very seriously, the highlighting of known issues here is a convenience for implementers and it does not imply that GitLab has targeted compatibility with, nor carries any type of guarantee of running on the partner technology where the issues occur. Please consult individual issues to understand GitLabs stance and plans on any given known issue.
+
+See the [GitLab AWS known issues list](https://gitlab.com/gitlab-com/alliances/aws/public-tracker/-/issues?label_name%5B%5D=AWS+Known+Issue) for a complete list.
+
+## Gitaly SRE considerations
 
 Gitaly and Gitaly Cluster have been engineered by GitLab to overcome fundamental challenges with horizontal scaling of the open source Git binaries. Here is indepth technical reading on the topic:
 
-## Why Gitaly was built
+### Why Gitaly was built
 
 Below are some links to better understand why Gitaly was built:
 
@@ -18,17 +28,17 @@ Below are some links to better understand why Gitaly was built:
 - [Affects on horizontal compute architecture](https://gitlab.com/gitlab-org/gitaly/-/blob/master/doc/DESIGN.md#affects-on-horizontal-compute-architecture)
 - [Evidence to back building a new horizontal layer to scale Git](https://gitlab.com/gitlab-org/gitaly/-/blob/master/doc/DESIGN.md#evidence-to-back-building-a-new-horizontal-layer-to-scale-git)
 
-## Gitaly and Praefect elections
+### Gitaly and Praefect elections
 
 As part of Gitaly cluster consistency, Praefect nodes will occasionally need to vote on what data copy is the most accurate. This requires an uneven number of Praefect nodes to avoid stalemates. This means that for HA, Gitaly and Praefect require a minimum of three nodes.
 
-## Gitaly performance monitoring
+### Gitaly performance monitoring
 
 Complete performance metrics should be collected for Gitaly instances for identification of bottlenecks, as they could have to do with disk IO, network IO or memory.
 
 Gitaly must be implemented on instance compute.
 
-## Gitaly EBS volume sizing guidelines
+### Gitaly EBS volume sizing guidelines
 
 Gitaly storage is expected to be local (not NFS of any type including EFS).
 Gitaly servers also need disk space for building and caching Git pack files.
@@ -40,10 +50,10 @@ Background:
 - Use Amazon Linux 2 to ensure the best disk and memory optimizations (for example, ENA network adapters and drivers).
 - If GitLab backup scripts are used, they need a temporary space location large enough to hold 2 times the current size of the Git File system. If that will be done on Gitaly servers, separate volumes should be used. 
 
-## Gitaly HA in EKS quick start
+### Gitaly HA in EKS quick start
 
-The AWS EKS quick start for GitLab Cloud Native implements Gitaly as a multi-zone, self-healing infrastructure. It has specific code for reestablishing a Gitaly node when one fails, including AZ failure.
+The [AWS GitLab Cloud Native Hybrid on EKS Quick Start](gitlab_hybrid_on_aws.md#available-infrastructure-as-code-for-gitlab-cloud-native-hybrid) for GitLab Cloud Native implements Gitaly as a multi-zone, self-healing infrastructure. It has specific code for reestablishing a Gitaly node when one fails, including AZ failure.
 
-## Gitaly long term management
+### Gitaly long term management
 
 Gitaly node disk sizes will need to be monitored and increased to accommodate Git repository growth and Gitaly temporary and caching storage needs. The storage configuration on all nodes should be kept identical.
diff --git a/doc/install/aws/index.md b/doc/install/aws/index.md
index fc5f16db965..4df8de39eb5 100644
--- a/doc/install/aws/index.md
+++ b/doc/install/aws/index.md
@@ -23,14 +23,18 @@ Implementation patterns are built on the foundational information and testing do
 
 [Omnibus GitLab on AWS EC2 (HA)](manual_install_aws.md) - instructions for installing GitLab on EC2 instances. Manual instructions from which you may build out a GitLab instance or create your own Infrastructure as Code (IaC).
 
-### Gitaly SRE considerations for AWS
+### GitLab Site Reliability Engineering (SRE) for AWS
 
-[Gitaly SRE Considerations for AWS](gitaly_on_aws.md) - important information for implementing and managing GitLab Gitaly on AWS.
+[GitLab SRE Considerations for AWS](gitlab_sre_for_aws.md) - important information and known issues for planning, implementing, upgrading and long term management of GitLab instances and runners on AWS.
 
 ### EKS cluster provisioning best practices
 
 [EKS Cluster Provisioning Patterns](eks_clusters_aws.md) - considerations for setting up EKS cluster for runners and for integrating.
 
+### Scaling HA GitLab Runner on AWS EC2 ASG
+
+The following repository is self-contained in regard to enabling this pattern: [GitLab HA Scaling Runner Vending Machine for AWS EC2 ASG](https://gitlab.com/guided-explorations/aws/gitlab-runner-autoscaling-aws-asg/). The [feature list for this implementation pattern](https://gitlab.com/guided-explorations/aws/gitlab-runner-autoscaling-aws-asg/-/blob/main/FEATURES.md) is good to review to understand the complete value it can deliver.
+
 ## Additional details on implementation patterns
 
 GitLab implementation patterns build upon [GitLab Reference Architectures](../../administration/reference_architectures/index.md) in the following ways.
diff --git a/doc/integration/jira/index.md b/doc/integration/jira/index.md
index febd9907028..4ad9ab9f637 100644
--- a/doc/integration/jira/index.md
+++ b/doc/integration/jira/index.md
@@ -42,7 +42,7 @@ To set up the Jira development panel integration:
 - *If your installation uses Jira Cloud,* use the
   [GitLab for Jira app](connect-app.md).
 - *If either your Jira or GitLab installation is self-managed,* use the
-  [Jira DVCS Connector](dvcs.md).
+  [Jira DVCS (distributed version control system) connector](dvcs.md).
 
 ### Direct feature comparison
 
diff --git a/doc/operations/error_tracking.md b/doc/operations/error_tracking.md
index 5400e92ce3c..009fb1dd3ae 100644
--- a/doc/operations/error_tracking.md
+++ b/doc/operations/error_tracking.md
@@ -123,22 +123,6 @@ settings. By using a GitLab-provided DSN, your application connects to GitLab to
 Those errors are stored in the GitLab database and rendered by the GitLab UI, in the same way as
 Sentry integration.
 
-### Feature flag
-
-The integrated error tracking feature is behind a feature flag that is disabled by default.
-
-To enable it:
-
-```ruby
-Feature.enable(:integrated_error_tracking)
-```
-
-To disable it:
-
-```ruby
-Feature.disable(:integrated_error_tracking)
-```
-
 ### Project settings
 
 The feature should be enabled on the project level. However, there is no UI to enable this feature yet.