## Problem There are many about 534 columns in `application_settings`. Each column represents an application setting. In Cells 1.0, each cell will have independent databases. This means without further development, `application_settings` will be per-cell ### Questions * Can we assume most application_settings is OK not to be clusterwide ? * Looking at https://docs.google.com/spreadsheets/d/139BM766XqosbkyZOdPbN9NaClGKl-3amSViSVjor8DU/edit#gid=1138391337 (internal), many settings should be OK not to be clusterwide initially * For the application_settings that must be clusterwide, how will it be made clusterwide ? * Cell-specific, or org-specific, or both ? ### Proposal 1. We need to determine which application setting **must** be clusterwide. 1. We need to determine which application setting **must** be cell-specific. 2. For some application settings, it may be OK to temporarily manage it cell-by-cell. We can then move the application setting to become either cell-specific, or [organization setting](https://gitlab.com/groups/gitlab-org/-/epics/9267). 3. Create ability to each group to migrate settings to be cell-specific (alternatively, we can designate `application_settings` to be cell-specific, and create ability to migrate settings to be clusterwide). Possibly solution: **DO NOTHING** 4. Create `organization_settings` table - DONE. Each application_setting can be migrated as needed to the `orgnization_settings` if required. ### Scenarii for changing the cluster-wide classification of an attribute #### A cluster-wide setting is changed to be cell-local Take in account that a cell (e.g. `cell2`) might be deployed with this change, while another cell might not yet =\> the leader cell would be the SSOT to decide what attributes are cluster-wide, so as long as the change isn't deployed to the leader cell, the attribute would continue to be synced to the `cell2`. As soon as the change is deployed to the leader cell, the setting could be modified on `cell2` without being overwritten by the leader cell. #### A cell-local setting is changed to be cluster-wide Take in account that a cell (e.g. `cell2`) might be deployed with this change, while another cell might not yet =\> the leader cell would be the SSOT to decide what attributes are cluster-wide, so as long as the change isn't deployed to the leader cell, the attribute wouldn't be synced to the `cell2`. As soon as the change is deployed to the leader cell, the setting couldn't be modified on `cell2` and if it does, it would be overwritten by the leader cell soon after.