blob: 7c2974ca2583ca4643b9cb446c17edc7f90f06a0 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
|
---
stage: enablement
group: Tenant Scale
description: 'Cells: Router Endpoints Classification'
---
<!-- vale gitlab.FutureTense = NO -->
DISCLAIMER:
This page may contain information related to upcoming products, features and
functionality. It is important to note that the information presented is for
informational purposes only, so please do not rely on the information for
purchasing or planning purposes. Just like with all projects, the items
mentioned on the page are subject to change or delay, and the development,
release, and timing of any products, features, or functionality remain at the
sole discretion of GitLab Inc.
This document is a work-in-progress and represents a very early state of the
Cells design. Significant aspects are not documented, though we expect to add
them in the future. This is one possible architecture for Cells, and we intend to
contrast this with alternatives before deciding which approach to implement.
This documentation will be kept even if we decide not to implement this so that
we can document the reasons for not choosing this approach.
# Cells: Router Endpoints Classification
Classification of all endpoints is essential to properly route request
hitting load balancer of a GitLab installation to a Cell that can serve it.
Each Cell should be able to decode each request and classify for which Cell
it belongs to.
GitLab currently implements hundreds of endpoints. This document tries
to describe various techniques that can be implemented to allow the Rails
to provide this information efficiently.
## 1. Definition
## 2. Data flow
## 3. Proposal
## 4. Evaluation
## 4.1. Pros
## 4.2. Cons
|
