Fine-grained controls for new project Gitaly shard routing
Related to #39111 (closed) and https://gitlab.com/gitlab-com/gl-infra/infrastructure/issues/8650
Currently, GitLab has very basic controls for selecting a Gitaly shard when a new repository is created. A subset of the Gitaly shards can be marked to receive new repositories and one of those is randomly selected when a new project is created.
This causes many problems, some of which have been documented in #39111 (closed), https://gitlab.com/gitlab-com/gl-infra/infrastructure/issues/8650 and gitlab-com/gl-infra/scalability#64.
As https://gitlab.com/gitlab-com/gl-infra/infrastructure/issues/8650 rolls out we need to start thinking about more fine-grained control around host selection.
#39111 (closed) is an easy step forward, but beyond that large instances, such as GitLab.com need more fine-grained controls.
Some examples of the type of control we would like:
- All new repositories in namespace
Xshould route to servers groupA. - All new gold repositories should route to server group
B - All private free repositories should route to server group
C
Having this is an important step towards isolation of different customer types on GitLab.com.