Configuration/notifications of application limits
Problem statement
We have seen an urgent need to define more application limits within GitLab, to ensure that noisy neighbors don't impact performance and availability of instances. (For example gitlab.com)
While we have stated that these limits should be configurable, we have yet to define where and how they will be configured, and how both users and operators will know when they hit them.
Proposed solution
Since there is a sense of urgency around implementation of these issues, we should have a crawl/walk/run approach.
MVC
Goal: deliver limits on GitLab.com, where they are most urgently needed
- Configuration: Limits defined in a
Plan, with defaults applying to only GitLab.com (Plan's do not exist on self-managed today)- Changed via rails console
- Audit log event when value is changed
- Documentation: Limits and their defaults defined in documentation, along with how to change
- Operators: When a limit is hit, it should be logged. These can then be consumed in the customers logging solution, like Kibana.
- End users:
- For API's, standard response code with additional information on why it failed due to the limit.
- For interactive limits, work with your UX person
Next iteration
- Bring
Planto self-managed, with aPlan.defaultwhich applies globally - Ensure documentation is up to date
Next+1 iteration
- Inclusion in our audit events feature: https://docs.gitlab.com/ee/administration/audit_events.html#overview
- A UI where you can view the currently defined limits, and change them.
- API coverage of setting/getting limits as well
Edited by silv