Uploaded image for project: 'Bitbucket Data Center'
  1. Bitbucket Data Center
  2. BSERV-12496

Rate limit for git operations

XMLWordPrintable

    • 155
    • We collect Bitbucket feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.

      Problem Definition

      Some customer, that has a huge user base, may not have full visibility of the CIs and users that are connected and performing git operations against the Bitbucket Instance, which cause the option of changing the CIs to perform less request or on notification based more challenging and time consuming that should be.

      Suggested Solution

      In those scenarios, some customers would like to have a way to rate-limit, like the feature which we have for REST API also be available for git operations, which can be set up and configured on Users base, group Base or Repository base.

      With that, in case some user or automation is causing performance issues to the application, the admin would be able to restrict the amount of request for that user, avoid major issues for the application.

            [BSERV-12496] Rate limit for git operations

            Nitin Sharma added a comment -

            https://getsupport.atlassian.com/browse/SSP-59806

            Nitin Sharma added a comment - https://getsupport.atlassian.com/browse/SSP-59806

            null pointer added a comment -

            So currently rate limiting doesn't do anything for SSH operations?

            At large companies there are many CI CD pipelines and users. Some users and pipelines get out of control and excessively clone or cause stress via git SSH operations.

            Policing so many people is not possible. Rate limiting for SSH is required. Rate limiting the REST APIs and HTTP operations is insufficient.

            Currently this leads to a bad experience of Bitbucket server. A few misbehaving users take it down for everyone else. Someone has to manually track down who is causing the issues each time.

            null pointer added a comment - So currently rate limiting doesn't do anything for SSH operations? At large companies there are many CI CD pipelines and users. Some users and pipelines get out of control and excessively clone or cause stress via git SSH operations. Policing so many people is not possible. Rate limiting for SSH is required. Rate limiting the REST APIs and HTTP operations is insufficient. Currently this leads to a bad experience of Bitbucket server. A few misbehaving users take it down for everyone else. Someone has to manually track down who is causing the issues each time.

            Daniel Holmes added a comment -

            Something to add here.  The current feature for REST APIs doesn't actually just limit for REST APIs.  If you use HTTP for git, it also seems to apply there.  It would be good for the current limiter to actually distinguish /api vs /scm calls for controlling limiting.

            Then, for implementing this limiting for git actions, it should account for combinations of HTTP and SSH initiated git operations into the behavior so that they are unified in handling them both together.

            Daniel Holmes added a comment - Something to add here.  The current feature for REST APIs doesn't actually just limit for REST APIs.  If you use HTTP for git, it also seems to apply there.  It would be good for the current limiter to actually distinguish /api vs /scm calls for controlling limiting. Then, for implementing this limiting for git actions, it should account for combinations of HTTP and SSH initiated git operations into the behavior so that they are unified in handling them both together.

              Unassigned Unassigned
              ddresch@atlassian.com Dilan Dresch
              Votes:
              38 Vote for this issue
              Watchers:
              28 Start watching this issue

                Created:
                Updated: