Skip to content

Commit 5bb96d0

Browse files
bogdan-stBogdan Stancu
andauthored
Add proposal for user overrides API (cortexproject#6818)
* Add proposal for tenant limits API Signed-off-by: Bogdan Stancu <[email protected]> * Change endpoints Signed-off-by: Bogdan Stancu <[email protected]> * suggestions Signed-off-by: Bogdan Stancu <[email protected]> * support only block storage Signed-off-by: Bogdan Stancu <[email protected]> * overrides not limits Signed-off-by: Bogdan Stancu <[email protected]> * grammar Signed-off-by: Bogdan Stancu <[email protected]> * move hard limits to open questions Signed-off-by: Bogdan Stancu <[email protected]> --------- Signed-off-by: Bogdan Stancu <[email protected]> Co-authored-by: Bogdan Stancu <[email protected]>
1 parent aea76ee commit 5bb96d0

File tree

1 file changed

+77
-0
lines changed

1 file changed

+77
-0
lines changed

docs/proposals/user-overrides-api.md

Lines changed: 77 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,77 @@
1+
---
2+
title: "User Overrides API"
3+
linkTitle: "User Overrides API"
4+
weight: 1
5+
slug: overrides-api
6+
---
7+
8+
- Author: Bogdan Stancu
9+
- Date: June 2025
10+
- Status: Proposed
11+
12+
## Overview
13+
14+
This proposal outlines the design for a new API endpoint that will allow users to modify their current limits in Cortex. Currently, overrides can only be changed by administrators modifying the runtime configuration file and waiting for it to be reloaded.
15+
16+
## Problem
17+
18+
Currently, when users need limit adjustments, they must:
19+
1. Manually editing the runtime configuration file
20+
2. Coordinate with users to verify the changes
21+
3. Potentially repeating this process multiple times to find the right balance
22+
23+
This manual process is time-consuming, error-prone, and doesn't scale well with a large number of users. By offering a self-service API, users can adjust their own limits within predefined boundaries, reducing the administrative overhead and improving the user experience.
24+
25+
## Proposed API Design
26+
27+
### Endpoints
28+
29+
#### 1. GET /api/v1/user-overrides
30+
Returns the current overrides configuration for a specific tenant.
31+
32+
Response format:
33+
```json
34+
{
35+
"ingestion_rate": 10000,
36+
"ingestion_burst_size": 20000,
37+
"max_global_series_per_user": 1000000,
38+
"max_global_series_per_metric": 200000,
39+
...
40+
}
41+
```
42+
43+
#### 2. PUT /api/v1/user-overrides
44+
Updates overrides for a specific tenant. The request body should contain only the overrides that need to be updated.
45+
46+
Request body:
47+
```json
48+
{
49+
"ingestion_rate": 10000,
50+
"max_series_per_metric": 100000
51+
}
52+
```
53+
54+
#### 3. DELETE /api/v1/user-overrides
55+
Removes tenant-specific overrides, reverting to default overrides.
56+
57+
### Implementation Details
58+
59+
1. The API will be integrated into the cortex-overrides component to:
60+
- Read the current runtime config from the configured storage backend
61+
- Persist changes back to the storage backend
62+
- The API will only work with configurations stored in block storage backends.
63+
64+
2. Security:
65+
- Rate limiting will be implemented to prevent abuse
66+
- Changes will be validated before being applied
67+
68+
69+
3. Error Handling:
70+
- Invalid limit values will return 400 Bad Request
71+
- Storage backend errors will return 500 Internal Server Error
72+
73+
### Open Questions:
74+
- How do we implement a hard-limit configuration to avoid users
75+
setting unreasonable limits?
76+
- What set of overrides can be configurable through this API?
77+
Limits like `shard_size` should only be modified by the admin.

0 commit comments

Comments
 (0)