Add latest changes from gitlab-org/gitlab@14-5-stable-eev14.5.0-rc42

4 files changed, 55 insertions, 12 deletions

diff --git a/doc/architecture/blueprints/ci_scale/index.md b/doc/architecture/blueprints/ci_scale/index.md
index 6afa13bf207..3e9fbc534d5 100644
--- a/doc/architecture/blueprints/ci_scale/index.md
+++ b/doc/architecture/blueprints/ci_scale/index.md
@@ -60,6 +60,9 @@ that have the same problem.
 
 Primary keys problem will be tackled by our Database Team.
 
+Status: As of October 2021 the primary keys in CI tables have been migrated to
+big integers.
+
 ### The table is too large
 
 There is more than a billion rows in `ci_builds` table. We store more than 2
@@ -111,6 +114,12 @@ table that will accelerate SQL queries used to build
 queues](https://gitlab.com/gitlab-org/gitlab/-/issues/322766) and we want to
 explore them.
 
+Status: the new architecture [has been implemented on GitLab.com](https://gitlab.com/groups/gitlab-org/-/epics/5909#note_680407908).
+
+The following epic tracks making it generally available: [Make the new pending
+builds architecture generally available](
+https://gitlab.com/groups/gitlab-org/-/epics/6954).
+
 ### Moving big amounts of data is challenging
 
 We store a significant amount of data in `ci_builds` table. Some of the columns
@@ -127,6 +136,8 @@ columns, tables, partitions or database shards.
 
 Effort to improve background migrations will be owned by our Database Team.
 
+Status: In progress.
+
 ### Development velocity is negatively affected
 
 Team members and the wider community members are struggling to contribute the
@@ -168,7 +179,12 @@ target](https://gitlab.com/groups/gitlab-org/-/epics/5745) epic.
 
 ## Status
 
-In progress.
+|-------------|--------------|
+| Created at  | 21.01.2021   |
+| Approved at | 26.04.2021   |
+| Updated at  | 28.10.2021   |
+
+Status: In progress.
 
 ## Who
 
@@ -180,7 +196,7 @@ Proposal:
 |------------------------------|-------------------------|
 | Author                       | Grzegorz Bizon          |
 | Architecture Evolution Coach | Kamil Trzciński         |
-| Engineering Leader           | Darby Frey              |
+| Engineering Leader           | Cheryl Li               |
 | Product Manager              | Jackie Porter           |
 | Domain Expert / Verify       | Fabio Pitino            |
 | Domain Expert / Database     | Jose Finotto            |
@@ -190,7 +206,7 @@ DRIs:
 
 | Role                         | Who
 |------------------------------|------------------------|
-| Leadership                   | Darby Frey             |
+| Leadership                   | Cheryl Li              |
 | Product                      | Jackie Porter          |
 | Engineering                  | Grzegorz Bizon         |
 
diff --git a/doc/architecture/blueprints/consolidating_groups_and_projects/index.md b/doc/architecture/blueprints/consolidating_groups_and_projects/index.md
index a8d87e5f967..53357220755 100644
--- a/doc/architecture/blueprints/consolidating_groups_and_projects/index.md
+++ b/doc/architecture/blueprints/consolidating_groups_and_projects/index.md
@@ -6,7 +6,7 @@ comments: false
 description: Consolidating groups and projects
 ---
 
-# Consolidating Group and Project
+# Consolidating Groups and Projects
 
 There are numerous features that exist exclusively within groups or
 projects. The boundary between group and project features used to be clear.
@@ -127,6 +127,22 @@ The work required to establish `Namespace` as a container for our features is
 tracked under [Consolidate Groups and Projects](https://gitlab.com/groups/gitlab-org/-/epics/6473)
 epic.
 
+## Migrating features to Namespaces
+
+The initial iteration will provide a framework to house features under `Namespaces`. Stage groups will eventually need to migrate their own features and functionality over to `Namespaces`. This may impact these features in unexpected ways. Therefore, to minimize UX debt and maintain product consistency, stage groups will have to consider a number of factors when migrating their features over to `Namespaces`:
+
+1. **Conceptual model**: What are the current and future state conceptual models of these features ([see object modeling for designers](https://hpadkisson.medium.com/object-modeling-for-designers-an-introduction-7871bdcf8baf))? These should be documented in Pajamas (example: [Merge Requests](https://design.gitlab.com/objects/merge-request)).
+1. **Merge conflicts**: What inconsistencies are there across project, group, and admin levels? How might these be addressed? For an example of how we rationalized this for labels, please see [this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/338820).
+1. **Inheritence & information flow**: How is information inherited across our container hierarchy currently? How might this be impacted if complying with the new [inheritence behavior](https://gitlab.com/gitlab-org/gitlab/-/issues/343316) framework?
+1. **Settings**: Where can settings for this feature be found currently? How will these be impacted by `Namespaces`?
+1. **Access**: Who can access this feature and is that impacted by the new container structure? Are there any role or privacy considerations?
+1. **Tier**: Is there any tier functionality that is differentiated by projects and groups?
+1. **Documentation**: Is the structure and content of documentation impacted by these changes at all?
+1. **Solution proposal**:
+   - Think big: This analysis provides a great opportunity to zoom out and consider the feature UX as a whole. How could you make this feature lovable based on the new structure, inheritance, and capabilities afforded by `Namespaces`? Is there any UI which doesn't comply with Pajamas?
+   - Start small: What are the product changes that need to be made to assist with the migration?
+   - Move fast: Prioritise these solution ideas, document in issues, and create a roadmap for implementation.
+
 ## Who
 
 Proposal:
@@ -151,5 +167,10 @@ DRIs:
 | Product                      | Melissa Ushakov        |
 | Leadership                   | Michelle Gill          |
 | Engineering                  | Imre Farkas            |
+| Design                       | Nick Post              |
 
 <!-- vale gitlab.Spelling = YES -->
+
+## Related topics
+
+- [Workspaces developer documentation](../../../development/workspaces/index.md)
diff --git a/doc/architecture/blueprints/container_registry_metadata_database/index.md b/doc/architecture/blueprints/container_registry_metadata_database/index.md
index f52635baf7b..7bbaefb8e1e 100644
--- a/doc/architecture/blueprints/container_registry_metadata_database/index.md
+++ b/doc/architecture/blueprints/container_registry_metadata_database/index.md
@@ -193,13 +193,19 @@ PostgreSQL introduced significant improvements for partitioning in [version 12](
 - Bulk load (`COPY`) now uses bulk inserts instead of inserting one row at a time;
 
 To leverage these features and performance improvements, we need to use PostgreSQL 12 from the start.
-
-GitLab currently ships with PostgreSQL 11 for self-managed instances. That is _likely_ to change in 14.0, with PostgreSQL 12 becoming the minimum required version, which will likely happen before the upgraded registry becomes available for self-managed instances. If not, self-managed instances will have two options:
-
-1. Administrators can manually provision and configure a separate PostgreSQL 12 database for the registry, allowing them to benefit from features provided by the new registry and its metadata database.
-1. Continue to use the current registry without the database if online garbage collection is not a concern or provisioning a separate database is not possible. We will continue supporting the current version with security backports and bug fixes for the foreseeable feature.
-
-It's important to note that apart from online garbage collection, the metadata database's availability will unblock the implementation of many requested features for the GitLab Container Registry, which will only be available for instances using the new version backed by the metadata database.
+GitLab 14.0 and later [ships with PostgreSQL 12](../../../administration/package_information/postgresql_versions.md)
+for self-managed instances. Customers not able to upgrade to PostgreSQL 12 have two options:
+
+- Administrators can manually provision and configure a separate PostgreSQL 12 database for the
+  registry. This lets you benefit from the features provided by the new registry and its metadata
+  database.
+- If online garbage collection isn't a concern or provisioning a separate database isn't possible,
+  continue to use the current registry without the database. GitLab supports the current version
+  with security backports and bug fixes.
+
+Apart from online garbage collection, the metadata database's availability unblocks the
+implementation of many requested features for the GitLab Container Registry. These features are only
+available for instances using the new version backed by the metadata database.
 
 ### Availability
 
diff --git a/doc/architecture/blueprints/feature_flags_development/index.md b/doc/architecture/blueprints/feature_flags_development/index.md
index a5e46d25921..94d52ea3474 100644
--- a/doc/architecture/blueprints/feature_flags_development/index.md
+++ b/doc/architecture/blueprints/feature_flags_development/index.md
@@ -29,7 +29,7 @@ The extensive usage of feature flags poses a few challenges
   We sometimes forget how our feature flags are configured or why we haven't
   yet removed the feature flag.
 - The usage of feature flags can also be confusing to people outside of
-  development that might not fully understand dependence of ~feature or ~bug
+  development that might not fully understand dependence of ~"type::feature" or ~"type::bug"
   fix on feature flag and how this feature flag is configured. Or if the feature
   should be announced as part of release post.
 - Maintaining feature flags poses additional challenge of having to manage