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 Plan to self-managed, with a Plan.default which 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 Oct 29, 2019 by silv
Assignee Loading
Time tracking Loading