From de65f5d6439df54b769a4d26a87abd25839898aa Mon Sep 17 00:00:00 2001
From: Thong Kuah <tkuah@gitlab.com>
Date: Tue, 26 Mar 2024 00:02:45 +0000
Subject: [PATCH] Add FAQ for cluster-wide feature for Cells 1.0
Many groups ask for about this, so offer some guidance on what to
expect, and what to do.
---
doc/architecture/blueprints/cells/index.md | 7 ++++--
.../blueprints/cells/iterations/cells-1.0.md | 24 +++++++++++++++++++
2 files changed, 29 insertions(+), 2 deletions(-)
diff --git a/doc/architecture/blueprints/cells/index.md b/doc/architecture/blueprints/cells/index.md
index 76cae6a906e78..12d9bb7ca1a74 100644
--- a/doc/architecture/blueprints/cells/index.md
+++ b/doc/architecture/blueprints/cells/index.md
@@ -365,8 +365,11 @@ Cluster-wide features are strongly discouraged because:
- They might require implementation of non-trivial [data aggregation](goals.md#aggregation-of-cluster-wide-data) that reduces resilience to [single node failure](goals.md#high-resilience-to-a-single-cell-failure).
- They are harder to build due to the need of being able to run [mixed deployments](goals.md#cells-running-in-mixed-deployments). Cluster-wide features need to take this into account.
- They might affect our ability to provide an [on-premise like experience on GitLab.com](goals.md#on-premise-like-experience).
-- Some features that are expected to be cluster-wide might in fact be better implemented using federation techniques that use trusted intra-cluster communication using the same user identity. User Profile is shared across the cluster.
-- The Cells architecture limits what services can be considered cluster-wide. Services that might initially be cluster-wide are still expected to be split in the future to achieve full service isolation. No feature should be built to depend on such a service (like Elasticsearch).
+- Some features that are expected to be cluster-wide might in fact be better implemented using aggregation techniques that use trusted intra-cluster communication using the same user identity.
+ For example, user Profile is shared across the cluster.
+- The Cells architecture limits what services can be considered cluster-wide.
+ Services that might initially be cluster-wide are still expected to be split in the future to achieve full service isolation.
+ No feature should be built to depend on such a service (like Elasticsearch).
### Will Cells use the [reference architecture for 50,000 users](../../../administration/reference_architectures/50k_users.md)?
diff --git a/doc/architecture/blueprints/cells/iterations/cells-1.0.md b/doc/architecture/blueprints/cells/iterations/cells-1.0.md
index 244756905ddae..4db3ce8314e47 100644
--- a/doc/architecture/blueprints/cells/iterations/cells-1.0.md
+++ b/doc/architecture/blueprints/cells/iterations/cells-1.0.md
@@ -702,3 +702,27 @@ The table below is a comparison between the existing GitLab.com features, and no
- Geo is per-Cell.
- Routing Service can direct to Geo replica of the Cell (if it knows it).
- We might have many routing services in many regions.
+
+1. Are cluster-wide tables available to all cells?
+
+ No, cluster-wide tables are stored in a Cell-local database. However, we will
+ determine synchronization of cluster-wide tables on a case by case basis.
+
+1. How can I adapt a feature to be compatible with Cells?
+
+ Many groups have questions about how to adapt a feature for Cell.
+ This especially applies if a feature is available at the instance level, or
+ can be used across groups.
+
+ Here are some strategies for evolving a thing for Cells 1.0:
+
+ - Leave the feature unchanged.
+ For example, admins / users will have to create an account per cell.
+ - Disable the feature for Cells 1.0.
+ - For critical cases, move the feature to cluster-wide level.
+ For example, users can sign in at a single location, `https://gitlab.com/users/sign_in`.
+
+ In many cases, it is not yet necessary to re-implement an instance-wide feature
+ to work on a cluster-wide level. This is because for Cells 1.0, the net
+ effect of only allowing private visibility and new users mean that we can
+ defer this until Cells 1.5.
--
GitLab