1148674 - Decide on improvements to Tier-N job support

Status: RESOLVED DUPLICATE of bug 1387640

(Tree Management :: Treeherder: Data Ingestion, defect, P3)

Description

[Cameron Dawson [:camd]]

Handling Tier-2 jobs could be done more cleanly than what was done in Q1 2015.  We could store the Tier based on the job signature.  Perhaps store that IN the ``reference_data_signature`` table.  

We would need a good UI for editing that.  Currently it uses the exclusion profiles for that.  We could use a similar UI, but differentiate it from an "exclusion" profile.  Or we could provide a ui (even in the django admin) to specify the tier based on the signature.

It might be good to re-evaluate this approach once Tier-2 jobs have been in the wild and we can see the use-cases more clearly.

for example: we may need more than 2 tiers, which could make the existing ``exclusion profile`` based implementation less practical.

Comment 1

[Ryan VanderMeulen [:RyanVM]]

ni? myself to flesh out some other Tier 2 issues I've been needing to file.

Comment 2

[Ryan VanderMeulen [:RyanVM]]

I replied to a message Nigel sent to the sheriffs list that basically sums up what I think TH needs to do still with respect to Tier-2 job handling in the UI.

The big issue at the moment is that the Treeherder UI doesn't adequately differentiate Tier-2 jobs from Tier-1 (in ways that would matter to the sheriffing workflow). In an ideal world, unclassified Tier-2 failures wouldn't factor into the count in the page title, wouldn't be affected by n/p navigation, etc. I could even argue that unclassified Tier-2 failures shouldn't be visible in onlyunstarred ('u') mode. In other words, from a sheriffing standpoint, they should be visible but otherwise out of the way. And then like you said, sheriffs can periodically look at the failures, file bugs for any new ones, then get on with their lives.

Comment 3

[Cameron Dawson [:camd]]

Hit this today with Wes where someone accidentally marked a ton of job types as Tier-3, so they got hidden.  Same mechanism as Tier-2 jobs applies here.

It might be possible to use the same UI for excluding that we do now, but upon saving the profile, go through and update the signatures that in the reference_data_signature (RDS) table to reflect the current setting in the exclusion profile.  

And then, as stated before, get the Tier value for jobs from the RDS table rather than store it in the jobs table.

The unfortunate part of the current impl is that those jobs are now Tier-3 for good, unless we go update them by hand, because the Tier value is saved in the jobs table.  Even after the exclusion profile was fixed, they persist as Tier-3.  If we could just modify the RDS table, they'd be up-to-date immediately.

Comment 4

[Cameron Dawson [:camd]]

I wonder if this would be a good candidate for deliverable in Q2 or Q3?  It's not super big or anything.  But sure would be nice.   Perhaps making a full-page UI for the editing of these profiles could go along with it.