Skip to content

Move `users` adjacent tables to be `gitlab_main_clusterwide`

Manoj M J [On PTO] requested to merge 415201-cells-iteration-2-configure-users-adjacent-tables-to-be-gitlab_main_clusterwide-to-support into master

What does this MR do and why?

For #415201 (closed)

As we are working on Cells, we have to classify tables to be either cell-local or clusterwide.

#415201 (closed) contains the list of tables that are touched while performing the action - User creates a group, and are good candidates to be clusterwide tables. As a general rule: Since we have decided that users will be a clusterwide table, all tables that are closely related to users will be clusterwide tables too.

In this MR, the following tables from that list are moved to gitlab_main_clusterwide schema. The model will now inherit from < MainClusterwide::ApplicationRecord (which is a no-op now as main_clusterwide db is not yet configured)

table name justification for moving to clusterwide any cross joins with namespaces?
emails belongs to user_id ❌
identities contains all identities for user, has user_id as foreign key. (It includes saml_provider_id as a column too, but it should be ok to make this table clusterwide, as there is only 1 cross-join, or this table could be split later) #419931
plans does not belong to any entity, could be global, just like licenses #419988 (closed)
routes #415201 (comment 1496933366) #420046
redirect_routes #415201 (comment 1496933366) #420046
user_callouts belongs to user_id ❌
user_details belongs to user_id #419933
user_preferences belongs to user_id ❌
user_statuses belongs to user_id ❌
user_synced_attributes_metadata belongs to user_id ❌

Side effect

The side effect of making this change is that now we will start to see cross-joins between 2 databases (gitlab_main_cell and gitlab_main_clusterwide). Currently, only namespaces table is marked as gitlab_main_cell, so any cross-join failures that we see in the pipeline of this MR is between namespaces and one of the tables we moved.

Cross joins cannot exist between two databases, and should be fixed. But, for the time being, we are only marking existing cross-join violations with allow_cross_joins_across_databases(url: url), so that this MR's pipeline can pass. &11103 has been opened to track all the violations we have found out after this change, and they will be scheduled and worked on later.

Also see: #415201 (comment 1495061091), for a related discussion.

Screenshots or screen recordings

Screenshots are required for UI changes, and strongly recommended for all other merge requests.

Before After

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

For #415201 (closed)

Edited by Manoj M J [On PTO]

Merge request reports