Page MenuHomePhabricator

Request increased quota for Legoktm's Rust Toolforge tools
Closed, DeclinedPublic

Description

Tool Name: apt-browser, empty-categories, masto-collab, otd-helper, poty-stuff, prosesize, rfa-voting-history, rust-hello-world, slf, steve-adder, streaks, tour-nyc, upcoming-mainpage
Quota increase requested: +2 CPUs (total of 3)
Reason:

Compiling Rust code on the grid was pretty fast and very parallel because it could use multiple CPUs. On k8s, using toolforge jobs, it's pretty slow, even with 1 full CPU, mostly because it can't parallelize. I would like to be able to run a build job with 2 CPUs (and then 1 CPU for the running webservice). Most of the time these extra resources won't be used since compiling is a relatively rare operation compared to a constantly running webservice.

Event Timeline

At a glance this feels as though it should already be (mostly) accessible to your system. As each project should already have access to 2 cores worth of cpu. At which point setting a modest cpu request for the web service and no limit for the build pod should get you mostly there. But some layer of the toolforge onion prevents allowing a pod to use more than 1 core. I'm not sure of the history of this. Or if we can update it with a quota request.

@taavi do you have more information on why a given pod cannot use more than 1 core?

The old default quotas had a K8s LimitRange that restricted pods to 1 CPU. The new quotas incremented in T333979: Re-visit Toolforge Kubernetes default quotas (April 2023) increase them, but I still haven't fully rolled them out to old pods as I want to automated that (T350873). I'm hoping that will be done within the next week or two. If this is wanted before then, feel free to just bump the quotas, they should be uncontroversial as the new limits are higher (8 CPU total with max 3 per pod).

The old default quotas had a K8s LimitRange that restricted pods to 1 CPU. The new quotas incremented in T333979: Re-visit Toolforge Kubernetes default quotas (April 2023) increase them, but I still haven't fully rolled them out to old pods as I want to automated that (T350873). I'm hoping that will be done within the next week or two. If this is wanted before then, feel free to just bump the quotas, they should be uncontroversial as the new limits are higher (8 CPU total with max 3 per pod).

I don't know that I quite follow. The CPU quota could be increased, but a pod still cannot be assigned more than 1 CPU until the change is rolled out, yes? If I'm understanding correctly there is nothing to do until then?

Ah cool, I'm happy to wait a few weeks for the new quotas!

The old default quotas had a K8s LimitRange that restricted pods to 1 CPU. The new quotas incremented in T333979: Re-visit Toolforge Kubernetes default quotas (April 2023) increase them, but I still haven't fully rolled them out to old pods as I want to automated that (T350873). I'm hoping that will be done within the next week or two. If this is wanted before then, feel free to just bump the quotas, they should be uncontroversial as the new limits are higher (8 CPU total with max 3 per pod).

So just to make sure I'm understanding correctly, new tools (~created after Nov 9) have the higher quota already and we're just waiting on updating older tools, right?

I've added a note to the docs that the default quotas are changing soon: https://wikitech.wikimedia.org/w/index.php?diff=2128934&oldid=2128314&title=Help:Toolforge/Kubernetes (which would've stopped me from filing this request in the first place :))