Add latest changes from gitlab-org/gitlab@master

8 files changed, 124 insertions, 9 deletions

diff --git a/doc/architecture/blueprints/activity_pub/index.md b/doc/architecture/blueprints/activity_pub/index.md
index 99942895573..63977f9db8a 100644
--- a/doc/architecture/blueprints/activity_pub/index.md
+++ b/doc/architecture/blueprints/activity_pub/index.md
@@ -346,7 +346,7 @@ enum in the Subscription model with a single table is because we needs
 specific associations and validations for each (an
 `ActivityPub::ProjectSubscription` belongs to a Project, an
 `ActivityPub::UserSubscription` does not). It also gives us more room for
-extensibility in the future. 
+extensibility in the future.
 
 #### Unfollow
 
@@ -386,7 +386,7 @@ Actually, GitLab already implements the Webfinger protocol endpoint through
 Doorkeeper
 ([this is the action that maps to its route](https://github.com/doorkeeper-gem/doorkeeper-openid_connect/blob/5987683ccc22262beb6e44c76ca4b65288d6067a/app/controllers/doorkeeper/openid_connect/discovery_controller.rb#L14-L16)),
 implemented in GitLab
-[in JwksController](https://gitlab.com/gitlab-org/gitlab/-/blob/efa76816bd0603ba3acdb8a0f92f54abfbf5cc02/app/controllers/jwks_controller.rb). 
+[in JwksController](https://gitlab.com/gitlab-org/gitlab/-/blob/efa76816bd0603ba3acdb8a0f92f54abfbf5cc02/app/controllers/jwks_controller.rb).
 
 There is no incompatibility here, we can just extend this controller.
 Although, we'll probably have to rename it, as it won't be related to Jwks
diff --git a/doc/architecture/blueprints/capacity_planning/index.md b/doc/architecture/blueprints/capacity_planning/index.md
index dd3efbb14c7..ed014f545f9 100644
--- a/doc/architecture/blueprints/capacity_planning/index.md
+++ b/doc/architecture/blueprints/capacity_planning/index.md
@@ -97,7 +97,7 @@ There is no need for a persistent state across Tamland runs aside from the S3 bu
 
 ### Benefits of executing inside tenant environments
 
-Each Tamland run for a single environment (tenant) can take a few hours to execute. With the number of tenants expected to increase significantly, we need to consider scaling the execution environment for Tamland. 
+Each Tamland run for a single environment (tenant) can take a few hours to execute. With the number of tenants expected to increase significantly, we need to consider scaling the execution environment for Tamland.
 
 In this design, Tamland becomes a part of the Dedicated stack and a component of the individual tenant environment. As such, scaling the execution environment for Tamland is solved by design, because tenant forecasts execute inherently parallel in their respective environments.
 
@@ -109,7 +109,7 @@ Tamland is released as a Docker image, see [Tamland's README](https://gitlab.com
 
 The manifest contains information about which saturation metrics to forecast on (see this [manifest example](https://gitlab.com/gitlab-com/gl-infra/tamland/-/blob/62854e1afbc2ed3160a55a738ea587e0cf7f994f/saturation.json) for GitLab.com). This will be generated from the metrics catalog and will be the same for all tenants for starters.
 
-In order to generate the manifest from the metrics catalog, we setup dedicated GitLab project `tamland-dedicated` . On a regular basis, a scheduled pipeline grabs the metrics catalog, generates the JSON manifest from it and commits this to the project. 
+In order to generate the manifest from the metrics catalog, we setup dedicated GitLab project `tamland-dedicated` . On a regular basis, a scheduled pipeline grabs the metrics catalog, generates the JSON manifest from it and commits this to the project.
 
 On the Dedicated tenants, we download the latest version of the committed JSON manifest from `tamland-dedicated` and use this as input to execute Tamland.
 
@@ -125,7 +125,7 @@ An alternative design, we don't consider an option at this point, is to setup Ta
 
 ![tamland-as-a-service](images/tamland-as-a-service.png)
 
-In this design, a central Prometheus/Thanos instance is needed to provide the metrics data for Tamland. Dedicated tenants use remote-write to push their Prometheus data to the central Thanos instance. 
+In this design, a central Prometheus/Thanos instance is needed to provide the metrics data for Tamland. Dedicated tenants use remote-write to push their Prometheus data to the central Thanos instance.
 
 Tamland is set up to run on a regular basis and consume metrics data from the single Thanos instance. It stores its results and cache in S3, similar to the other design.
 
@@ -136,4 +136,4 @@ This design **has not been chosen** because of both technical and organisational
 1. Our central Thanos instance currently doesn't have metrics data for Dedicated tenants as of the start of FY24Q3.
 1. Extra work required to set up scalable execution environment.
 1. Thanos is considered a bottleneck as it provides data for all tenants and this poses a risk of overloading it when we execute the forecasting for a high number of tenants.
-1. We strive to build out Tamland into a tool of more general use. We expect a better outcome in terms of design, documentation and process efficiency by building it as a tool for other teams to use and not offering it as a service. In the long run, we might be able to integrate Tamland (as a tool) inside self-managed environments or publish Tamland as an open source forecasting tool. This would not be feasible if we were hosting it as a service. 
+1. We strive to build out Tamland into a tool of more general use. We expect a better outcome in terms of design, documentation and process efficiency by building it as a tool for other teams to use and not offering it as a service. In the long run, we might be able to integrate Tamland (as a tool) inside self-managed environments or publish Tamland as an open source forecasting tool. This would not be feasible if we were hosting it as a service.
diff --git a/doc/architecture/blueprints/cells/impacted_features/group-transfer.md b/doc/architecture/blueprints/cells/impacted_features/group-transfer.md
new file mode 100644
index 00000000000..3b361a1459f
--- /dev/null
+++ b/doc/architecture/blueprints/cells/impacted_features/group-transfer.md
@@ -0,0 +1,28 @@
+---
+stage: enablement
+group: Tenant Scale
+description: 'Cells: Group Transfer'
+---
+
+<!-- vale gitlab.FutureTense = NO -->
+
+This document is a work-in-progress and represents a very early state of the Cells design.
+Significant aspects are not documented, though we expect to add them in the future.
+This is one possible architecture for Cells, and we intend to contrast this with alternatives before deciding which approach to implement.
+This documentation will be kept even if we decide not to implement this so that we can document the reasons for not choosing this approach.
+
+# Cells: Group Transfer
+
+> TL;DR
+
+## 1. Definition
+
+## 2. Data flow
+
+## 3. Proposal
+
+## 4. Evaluation
+
+## 4.1. Pros
+
+## 4.2. Cons
diff --git a/doc/architecture/blueprints/cells/impacted_features/issues.md b/doc/architecture/blueprints/cells/impacted_features/issues.md
new file mode 100644
index 00000000000..3ae5056240f
--- /dev/null
+++ b/doc/architecture/blueprints/cells/impacted_features/issues.md
@@ -0,0 +1,28 @@
+---
+stage: enablement
+group: Tenant Scale
+description: 'Cells: Issues'
+---
+
+<!-- vale gitlab.FutureTense = NO -->
+
+This document is a work-in-progress and represents a very early state of the Cells design.
+Significant aspects are not documented, though we expect to add them in the future.
+This is one possible architecture for Cells, and we intend to contrast this with alternatives before deciding which approach to implement.
+This documentation will be kept even if we decide not to implement this so that we can document the reasons for not choosing this approach.
+
+# Cells: Issues
+
+> TL;DR
+
+## 1. Definition
+
+## 2. Data flow
+
+## 3. Proposal
+
+## 4. Evaluation
+
+## 4.1. Pros
+
+## 4.2. Cons
diff --git a/doc/architecture/blueprints/cells/impacted_features/merge-requests.md b/doc/architecture/blueprints/cells/impacted_features/merge-requests.md
new file mode 100644
index 00000000000..4cbc1134feb
--- /dev/null
+++ b/doc/architecture/blueprints/cells/impacted_features/merge-requests.md
@@ -0,0 +1,28 @@
+---
+stage: enablement
+group: Tenant Scale
+description: 'Cells: Merge Requests'
+---
+
+<!-- vale gitlab.FutureTense = NO -->
+
+This document is a work-in-progress and represents a very early state of the Cells design.
+Significant aspects are not documented, though we expect to add them in the future.
+This is one possible architecture for Cells, and we intend to contrast this with alternatives before deciding which approach to implement.
+This documentation will be kept even if we decide not to implement this so that we can document the reasons for not choosing this approach.
+
+# Cells: Merge Requests
+
+> TL;DR
+
+## 1. Definition
+
+## 2. Data flow
+
+## 3. Proposal
+
+## 4. Evaluation
+
+## 4.1. Pros
+
+## 4.2. Cons
diff --git a/doc/architecture/blueprints/cells/impacted_features/project-transfer.md b/doc/architecture/blueprints/cells/impacted_features/project-transfer.md
new file mode 100644
index 00000000000..e5fb11c21a9
--- /dev/null
+++ b/doc/architecture/blueprints/cells/impacted_features/project-transfer.md
@@ -0,0 +1,28 @@
+---
+stage: enablement
+group: Tenant Scale
+description: 'Cells: Project Transfer'
+---
+
+<!-- vale gitlab.FutureTense = NO -->
+
+This document is a work-in-progress and represents a very early state of the Cells design.
+Significant aspects are not documented, though we expect to add them in the future.
+This is one possible architecture for Cells, and we intend to contrast this with alternatives before deciding which approach to implement.
+This documentation will be kept even if we decide not to implement this so that we can document the reasons for not choosing this approach.
+
+# Cells: Project Transfer
+
+> TL;DR
+
+## 1. Definition
+
+## 2. Data flow
+
+## 3. Proposal
+
+## 4. Evaluation
+
+## 4.1. Pros
+
+## 4.2. Cons
diff --git a/doc/architecture/blueprints/cells/index.md b/doc/architecture/blueprints/cells/index.md
index bac41a4d903..83e2bad8d09 100644
--- a/doc/architecture/blueprints/cells/index.md
+++ b/doc/architecture/blueprints/cells/index.md
@@ -347,7 +347,11 @@ The following list of impacted features only represents placeholders that still
 - [Cells: Agent for Kubernetes](impacted_features/agent-for-kubernetes.md)
 - [Cells: Data pipeline ingestion](impacted_features/data-pipeline-ingestion.md)
 - [Cells: GitLab Pages](impacted_features/gitlab-pages.md)
+- [Cells: Group Transfer](impacted_features/group-transfer.md)
+- [Cells: Issues](impacted_features/issues.md)
+- [Cells: Merge Requests](impacted_features/merge-requests.md)
 - [Cells: Personal Access Tokens](impacted_features/personal-access-tokens.md)
+- [Cells: Project Transfer](impacted_features/project-transfer.md)
 - [Cells: Router Endpoints Classification](impacted_features/router-endpoints-classification.md)
 - [Cells: Schema changes (Postgres and Elasticsearch migrations)](impacted_features/schema-changes.md)
 - [Cells: Uploads](impacted_features/uploads.md)
@@ -413,7 +417,7 @@ The design goals of the Cells architecture describe that [all Cells are under a
 
 - Cell-local features should be limited to those related to managing the Cell, but never be a feature where the Cell semantic is exposed to the customer.
 - The Cells architecture wants to freely control the distribution of Organization and customer data across Cells without impacting users when data is migrated.
- 
+
 Cluster-wide features are strongly discouraged because:
 
 - They might require storing a substantial amount of data cluster-wide which decreases [scalability headroom](goals.md#provides-100x-headroom).
diff --git a/doc/architecture/blueprints/modular_monolith/packages_extraction.md b/doc/architecture/blueprints/modular_monolith/packages_extraction.md
index 606b8376cc3..2b9a64e0631 100644
--- a/doc/architecture/blueprints/modular_monolith/packages_extraction.md
+++ b/doc/architecture/blueprints/modular_monolith/packages_extraction.md
@@ -14,7 +14,7 @@ The general steps of refactoring existing code to modularization could be:
 1. Use the same namespace for all classes and modules related to the same [bounded context](bounded_contexts.md).
 
     - **Why?** Without even a rough understanding of the domains at play in the codebase it is difficult to draw a plan.
-      Having well namespaced code that everyone else can follow is also the pre-requisite for modularization. 
+      Having well namespaced code that everyone else can follow is also the pre-requisite for modularization.
     - If a domain is already well namespaced and no similar or related namespaces exist, we can move directly to the
       next step.
 1. Prepare Rails development for Packwerk packages. This is a **once off step** with maybe some improvements
@@ -50,4 +50,3 @@ The general steps of refactoring existing code to modularization could be:
 
 Once we have Packwerk configured for the Rails application (step 2 above), emerging domains could be directly implemented
 as Packwerk packages, benefiting from isolation and clear interface immediately.
-   
\ No newline at end of file