1458560 - [meta] Move platform display name mappings out of Treeherder's UI

Status: RESOLVED FIXED

(Tree Management :: Treeherder, enhancement, P3)

Description

[Ed Morley [:emorley]]

(Filing in response to recent email thread; ask if you'd like a forward)

Currently the platform name for a job provided to us by Taskcluster/... (eg "windows2012-64") is mapped to a more user-friendly display name (eg "Windows 2012 x64") in Treeherder's frontend - which is then used in the caption for each row of jobs in the UI.

See:
https://github.com/mozilla/treeherder/blob/7bc1093f0408d173e6cd2c85d1c6e856ac47001f/ui/js/constants.js#L4-L146

This mapping is a pain, since:
* it is (as I understand it) the last thing that isn't in-tree (mozilla-central), so easy to forget / more hassle for people adding new platforms
* consumers of Treeherder's API have no way of using it
* it contains lots of cruft that would require manually sorting through to try and clean up (compared to being part of the database schema and so automatically expired)

Bug 1043249 was open to move this mapping from the UI to the API - however in a post-buildbot world it would be best to just move it to the Taskcluster task definitions instead (similar to the job/group name/symbols) and remove the mapping from Treeherder entirely. (And equivalent for non-Taskcluster). 

I presume the steps would be:
1) Decide on where this metadata should live in-tree & add it
2) Update the pulse schemas appropriately
3) Adjust Treeherder's schema & pulse ingestion layer so it can handle the new metadata, but have fallbacks for both non-taskcluster (buildbot and others) and also taskcluster branches that don't yet have the metadata from (1)
4) At some point in the future (after bug 1443251 and bug 1349182 are fixed, and :davehunt's teams systems have updated their Pulse submissions too), remove the fallbacks

Comment 1

[Ed Morley [:emorley]]

Once we've done 1-4 I guess we could just remove the short form of the platform name ("windows2012-64") entirely?

Comment 2

[Dustin J. Mitchell [:dustin] (he/him)]

Now that it's written out, that makes a lot more sense than the other options I was considering.

We could potentially just start sending the "human" names in the same place in the pulse messages.  It seems that the default is to display the supplied name if the mapping contains no matching entry.  Then the mapping would slowly become unused, and could be removed at a later point.

Comment 3

[Ed Morley [:emorley]]

What were the other options, out of interest? :-)

(In reply to Dustin J. Mitchell [:dustin] pronoun: he from comment #2)
> We could potentially just start sending the "human" names in the same place
> in the pulse messages.  

I think Perfherder uses the platform name as part of the signature generation, which would mean a potential discontinuity in the stats unless otherwise handled somehow? Rob/Will?

Comment 4

[Dustin J. Mitchell [:dustin] (he/him)]

The other options I had in mind were:

 - add this information to https://hg.mozilla.org/build/ci-configuration and import that into TH on startup
 - add this information to a fixed location in mozilla-central and import it on startup

neither of those would allow testing new platforms in try, though, and the first would not ride the trains..

Comment 5

[William Lachance (:wlach)]

(In reply to Ed Morley [:emorley] from comment #3)
> What were the other options, out of interest? :-)
> 
> (In reply to Dustin J. Mitchell [:dustin] pronoun: he from comment #2)
> > We could potentially just start sending the "human" names in the same place
> > in the pulse messages.  
> 
> I think Perfherder uses the platform name as part of the signature
> generation, which would mean a potential discontinuity in the stats unless
> otherwise handled somehow? Rob/Will?

Yes, we use the machine platform from the job signature, which is confusingly not a reference to the machine platform table but a string:

https://github.com/mozilla/treeherder/blob/527d1645f7a078b3d8ba797bcffc2445f34316a5/treeherder/etl/perf.py#L63
https://github.com/mozilla/treeherder/blob/527d1645f7a078b3d8ba797bcffc2445f34316a5/treeherder/model/models.py#L346

Performance signatures do change fairly often for other reasons, so I don't think it would be the end of the world if there was a discontinuity here. But be sure to give :jmaher and :igoldan (at least) a heads up if you're going to do this.

Comment 6

[Gregory Szorc [:gps]]

I semi-frequently look at long-term graphs of data to look for long-term trends. If one day all of the old data was not available, this would be a bit disruptive. It would be *really* nice to carry forward old data to its new name.