Cells 1.0: Runner registration with `glrt-` token does not work on the secondary cell
The registration of a runner that was created in the GitLab UI (or API call) happens through the POST /runner/verify REST endpoint. This endpoint takes the token and system_id attributes, and currently no information conveys the destination cell, so all requests are routed to the primary cell.
Proposal
Embed routing information into new runner authentication tokens created in secondary cells.
Instead of creating a glrt-UfMt7-xxxxxx-ZJpuvsb token, GitLab would create a glrt-cell_2_UfMt7-xxxxxx-ZJpuvsb token. The short sha would be UfMt7-xxx, which would mean that both GitLab and GitLab Runner would need code changes to be able to strip out the routing information, in the same way that it today knows how to strip the glrt- prefix. The router would also need to understand runner authentication tokens to route them to the respective cell if routing information is present, or to the primary cell otherwise.
| cell | old token | proposed token | short sha |
|---|---|---|---|
| 1 | glrt-UfMt7-xxxxxx-ZJpuvsb |
glrt-cell_1_UfMt7-xxxxxx-ZJpuvsb |
UfMt7-xxx |
| 1 | UfMt7-xxxxxx-ZJpuvsb |
cell_1_UfMt7-xxxxxx-ZJpuvsb |
UfMt7-xxx |
| 2 | glrt-UfMt7-xxxxxx-ZJpuvsb |
glrt-cell_2_UfMt7-xxxxxx-ZJpuvsb |
UfMt7-xxx |
| 2 | UfMt7-xxxxxx-ZJpuvsb |
cell_2_UfMt7-xxxxxx-ZJpuvsb |
UfMt7-xxx |
Other options considered
Add new cell (or routing) argument to endpoint.
Although this would not require any changes to the runner authentication tokens, it creates more problems than it solves, because it would require doing the same change to any unauthenticated endpoints dealing with authentication tokens (example 1, example 2).