Feature summary Allow up to the per-tool CPU limit CPUs per job
Use case(s) I have a few Rust-based bots that run multithreaded&async, which could really benefit from more CPUs
Benefits So I don't have to run 2-3 copies of the same bot in parallel. If I'm using more CPUs anyway, might as well do it without unnecessary hackery...
This limit comes from the per-namespace LimitRange objects originally set up in T234702. The main reason these exist is to ensure that a single pod doesn't fully starve out a worker node.
That being said, since our workers have 4 or 8 vCPUs allocated I don't see an issue with raising the default to 2 or 3. If there are good use cases for anything above those they can be discussed case-by-case in Toolforge (Quota-requests) anyways.
3 CPUs would be plenty, I think that's actually the per-tool limit, including the webservice?