1887975 - create t-linux* pools without scratch-disk

Status: RESOLVED FIXED

(Firefox Build System :: Task Configuration, task)

Description

[Joel Maher ( :jmaher ) (UTC -8)]

with the exceptions of linux xpcshell-condprof, all linux and android-em tasks can run successfully (same failure rate +- 5% runtime - should be a savings) if we do not have a scratch-disk added. For reference we pay almost $40K/month for local-ssd scratch-disks attached to spot instances. They are attached to builds as well, so this will put a good dent in the budget, but not remove it entirely.

working with :aerickson yesterday, he created handbuilt-docker-worker-tester-20240325 which is used as an image for some testing;

I propose:

1. make handbuilt-docker-worker-tester-20240325 a formal image
2. edit pool: gecko-t/t-linux-kvm-gcp to have no scratch-disk and use image from #1
3. create new pool {pool-group}/t-linux-large-noscratch-gcp and {pool-group}/t-linux-xlarge-noscratch-gcp
4. once deployed edit taskcluster configs in m-c to use new *-noscratch-gcp pools

:aerickson, can you help with step #1 ?

Comment 1

[Andrew Erickson [:aerickson]]

re 1:

It's as formal as it's going to get.

The current production d-w tester image (docker-worker-gcp-u14-04-2023-06-13) is aliased incorrectly as monopacker-produced (it was also built by hand). We've never had a monopacker configuration for it (our docs regarding doing builds all reference doing changes hand).

Not sure why it wasn't moved to monopacker (perhaps because it's 14.04 it's hard to automate any longer since it's long deprecated) or 18.04 (like the d-w builder images).

Comment 2

[Joel Maher ( :jmaher ) (UTC -8)]

Attachment: Bug 1887975 - create 'noscratch' workers for t-linux-[x]large-noscratch-gcp, and t-linux-kvm-noscratch-gcp. r=#relsre-reviewers

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/ci/ci-configuration/rev/cf3f3ae2146d
create 'noscratch' workers for t-linux-[x]large-noscratch-gcp, and t-linux-kvm-noscratch-gcp. r=relsre-reviewers,markco