Open Bug 1698018 Opened 4 years ago Updated 3 years ago

Update defaults for custom backfill option

Categories

(Tree Management :: Treeherder, enhancement, P2)

enhancement

Tracking

(Not tracked)

People

(Reporter: igoldan, Unassigned)

Details

Attachments

(1 file)

Whenever I backfill as a perf sheriff, I use the custom backfill option.
For every job I need to backfill, I have to manually change the inclusive: false to true and times: 1 to 5.

We should replace these 2 defaults to true and 5 respectively, to optimize the command for perf sheriffing.

Severity: -- → S4
Priority: -- → P2

This would require the code sheriffs to revert the values for their backfills to revert these values to prevent unnecessary load.

A separate action for backfills by perf sheriffs could be added.

Two comments:

  1. Requesting multiple runs per push causes duplicate builds (one for each task), see bug 1658174. This affects performance tasks because they mostly use shippable builds which are only build by default for pushes which also run perf tasks by default.
  2. The combination of multiple runs per push + running it for every push causes significant load on the hardware pools. Could pushes unrelated to alerts be omitted?

(In reply to Sebastian Hengst [:aryx] (needinfo on intermittent or backout) from comment #2)

[...]
2) The combination of multiple runs per push + running it for every push causes significant load on the hardware pools. Could pushes unrelated to alerts be omitted?

I don't understand what "pushes unrelated to alerts" means. If the suggestion is to implement an heuristic to somehow determine what to omit, that's definitely not something we can practically do. Perf regressions tend to have very unexpected culprits.

The load on hardware pools is something expected. It's a drawback from reducing the job frequency from every 5 pushes to every 20 pushes. There's 4 times more missing data. Thus, the load is 4 times bigger than it used to be.
Perf sheriffs need this (missing) data one way or the other. And we surely need it ASAP, because we have very clear & strict KPIs. If the load is a problem, more advanced Taskcluster mechanisms should be employed or the pool size should be increased.

I would think a separate perf_backfill action could be defined.

This is an action that is has been in use for years and :igoldan is trying to reduce the manual steps a bit, so there is no worry about load on our existing hardware pools. I think the code sheriffs backfill more frequently than perf sheriffs which would make this default not ideal for code sheriffs, and more evidence we need a separate action.

Component: Treeherder: Job Triggering & Cancellation → TreeHerder
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: