User mapping - Add placeholder user limit
Context
Limiting the number of the placeholder users created during imports is important for .com. Therefore we need to place sensible limits per top-level namespaces. They should take into account top-level namespaces tier and number of seats.
Proposal
Because limiting the number of the placeholder users is especially important for .com, we will default the limit for an instance to "unlimited", and set the limits for .com.
We need two solutions/mechanisms for .com:
- limits based on group's tier and seat number (this issue)
- possibility of raising the limit for a chosen top-level group by an instance Admin (User mapping - implement custom placeholder use... (#473020)).
SM and Dedicated Admins should be able to set limit on their instances if they wanted to, meaning to change from "unlimited" to some number. (Also done in User mapping - implement custom placeholder use... (#473020)).
On .com, we will limit the number of placeholder users available per top-level namespace. We give higher limits to top-level namespaces on higher tiers and with larger amount of seats.
Based on the results of https://gitlab.com/gitlab-data/product-analytics/-/issues/1743+, the proposed limits are:
| Plan | Seats | Placeholder user limit top-level namespace |
|---|---|---|
| Free and Trial | any amount | 200 |
| Premium | <=100 | 500 |
| Premium | 101-500 | 2000 |
| Premium | 501 - 1000 | 4000 |
| Premium | > 1000 | 6000 |
| Ultimate | <=100 | 1000 |
| Ultimate | 101-500 | 4000 |
| Ultimate | 501 - 1000 | 6000 |
| Ultimate | > 1000 | 8000 |
We should monitor the number of errors/warnings "Placeholder user limit exceeded for namespace".
Customers need to set up their paid namespace before the import. (document this)
Placeholder users will not count towards licence limits.
Technical proposal
From #455903 (comment 1928025857):
The limits are based on plan and seats of the top-level namespace. We have similar limits in place for webhooks. We can look at that implementation for some guidance here.
- The MR !89591 (merged) that defined the limits and the data migration to populate them in GitLab.com
-
Gitlab::WebHooks::RateLimiterand the EE-module version that together determine the seat count of the top-level namespace and checks the limit.
The related issue #443553 (closed) will add the Import user, and #464401 (closed) will update the assignment logic to take into account the rate limit, so this issue should be more or less just purely a database migration, and some backend application logic to calculate the limit (using the webhook implementation above for guidance).
We need to enable SM and Dedicated Admins to change the limit for the instance (for all top-level groups on the instance) from "unlimited" to a chosen number. In other words, we need a single setting that applies for the whole instance for self managed.