Document limits in GitLab - what type of limits, their default values, and how to change them
We need to document broadly the limits in our application. The limits can be a combination of recommendations or a prevention setting to keep GitLab running in a performant manner.
We should start with the obvious ones, it can be a list of areas under Dev which is the most used and expand from there. We need to document what limit, the default, and how to change it.
Sid 4. Why don’t we add limits to our documentation? gitlab-org/gitlab!18111 (diffs) Regarding nr. 4 can we make sure that limits in the application are documented?
Sid Maybe that is an engineering / definition of done responsibility, I’m open to that.
Eric Johnson We should document the presence of the ability to set limits for sure. But in many cases the limit value itself is dependent on the environment.
Sid Eric Johnson agree, we should document what limit, the default, and how to change it. And in most cases we should use the default on GitLab.com
Eric Johnson And maybe the values for our reference environments (first iteration of 25k got certified today)
mek Sid, agreed. We have started to recommend repo size / sharding limits in our reference architecture. It would be prudent for us to document all the areas in the application as well. I see this as prevention guidelines that would also help availability. I have started an issue to track an MVC effort, starting with Dev section. #5617 (moved)
Eric Johnson It would be brilliant if the values were in code, and could be populated automatically. They’re going to be pretty dynamic (at least GitLab.com’s)
gabriel perhaps an API for that?
Dev section (MVC)
- Number of comments per notable gitlab-org/gitlab!18111 (diffs)