Plan limits for self managed

In %12.6 we introduced a limit for webhooks per project and in %12.8 a limit for webhooks per group. The limits got introduced to avoid too many webhooks to be triggered by one action. The limits can be configured for GitLab.com plans using PlanLimits.

In order to remove the sub_group_webhooks feature flag we might also want to introduce a base limit that works for self managed instances (!26070 (comment 305853635))

Ideas

• We can't use plan limits in CE because they are only available in EE. But to move on with the feature flag, we would need to have this for group hooks only which is also an EE feature. So we can relay on plan limits for now
• The documentation says that self managed instances can add limits by executing Plan.default.limits.update!(group_hooks: 100) in GitLab Rails console. So we could add a migration that does it if not on GitLab.com.

added groupecosystem [DEPRECATED] label

mentioned in merge request !26070 (merged)

@arturoherrero could you have a look?

maybe you have some more ideas how we can implement a limit for self managed instances.

This is blocked at the moment by #32824 (closed).

I'm not sure about adding limits to self-managed instances. We recently tried to do that but we had a problem related to the local development database, so we removed the self-managed limits, see !26693 (merged) before the release.

@Andysoiron Is it not possible to remove the feature flag without self-managed limits?

@arturoherrero thanks for linking this issue. It looks like it is planned for 12.10

Is it not possible to remove the feature flag without self-managed limits?

Technically it is possible to remove the feature flag. There might be instances having a high number of hooks per group though and it might cause problems for them. However I think the risk is quite low. In #198467 (comment 289458612) we found that no group on GitLab.com has more than 35 hooks configured.

@deuley do you know how high the demand for this is on self managed instances? #12097 (closed) is the original issue

In my opinion, we can remove the feature flag.

I don't think any self-managing instance will have a problem with this. As @Andysoiron said it looks like this is not a very well known/used feature. In case one instance start having problems, they are able to set limits via command line: https://docs.gitlab.com/ee/administration/instance_limits.html#number-of-webhooks

We can still set the limit after #32824 (closed).

I do not, unfortunately. Group hooks are not currently counted in usage ping data.

If we wanted to, we could add group hook usage to the usage ping and give it a bit to collect data before making a call... but that seems unnecessary. We might end up seeing something really weird, which wouldn't surprise me all that much because the world is full of chaotic and unpredictable humans.

However, if we already have set a bar that is so much above what we expect to see, it should be fine, and it's relatively low risk since administrators can always up the limit themselves.

Thanks for the comments! We can also add a note to the release post that a limit can be added manually when needed

assigned to @arturoherrero

marked this issue as related to #32824 (closed)

unassigned @arturoherrero

I'm closing this issue in favour of #32824 (closed)

closed

added 1 deleted label

added devopsmanage label and removed 1 deleted label