## Introduction This epic describes all aspects to implement a first iteration of Cells architecture: https://docs.gitlab.com/ee/architecture/blueprints/cells/: ## Goal Two running Cells do share `Admin Area > Settings`. Change being made in a first one, is reflected in second one.  ## Architecture - The changes will introduce a new GitLab Schema: `gitlab_main_clusterwide`. - This schema will be attached to `cluster_main` connection. - The reads and writes to `application_settings` will be done via `cluster_main` connection. - As the simplification the Pod 2 will configure `cluster_main` connection to point to main database of Pod 1. This description, especially last bullet point is slightly different than what is in https://docs.gitlab.com/ee/architecture/blueprints/cells/. This is done as initial simplification, and subject to be evaluated how and where cluster-wide tables should be stored. ## Problems to solve 1. [x] We add `gitlab_main_clusterwide` and configure `application_settings` table to use it. 1. [x] We identify and allow-list all cross-joins, cross-modifications and foreign keys between `application_settings` and other tables. 1. [x] We fix (empty) allow-lists. 1. [x] We introduce a parent model `ClusterMain::ApplicationRecord` that `ApplicationSetting` inherits from. 1. [x] We add to `config/database.yml` the `cluster_main` connection, and configure `ClusterMain::ApplicationRecord` to use it. 1. [x] We run Pod 2 using GDK/GCK/Omnibus and configure the `cluster_main` to connect back to Pod 1 main database. 1. [x] User can go to `Admin Area > Settings` and change values. ## Related - https://gitlab.com/gitlab-org/pods-group/group-tasks/-/issues/33