1286086 - Unify handling of platforms

Status: RESOLVED INVALID

(Firefox Build System :: Task Configuration, task)

Description

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

We currently have a few ways of describing platforms.  Typically we've had "build platform" (e.g., linux64) and "build type" (e.g., opt).  This has led to weird things like "lint opt".  We also have test_platform, but no test_type.

Based on https://github.com/taskcluster/taskcluster-treeherder/blob/master/schemas/task-treeherder-config.yml, the latter are now called labels.  It appears that a single task can have multiple labels, but it's not clear what that might mean.

The "machine" section of that schema has keys "platform", "os", and "architecture", which is a different way to break things down.

I think we have frequently had some confusion and hacking-around to do between build and test platforms, e.g., android or OS X.

In-tree, I have been aiming to make platforms a single /-separated thing, e.g., linux64/asan, but I recently heard of asan-debug and asan-opt builds??

We now have the ability to iterate quickly on all aspects of this (Gecko, TC-TH, and TreeHerder), so we should settle on a consistent approach and implement it everywhere, with enough documentation that we don't veer off into the woods again.

Comment 1

[Greg Arndt [:garndt]]

taskcluster-treeherder (and the new Treeherder ingestion) supports buildMachine and runMachine for when the build and test platforms might differ.  currently taskcluster-treeherder only looks at machine.platform, but for the case of tests we probably want something else.

Comment 2

[Greg Arndt [:garndt]]

re: labels

with this new job ingestion by treeherder, labels have taken the place of what collection used to be...a way of applying labels to a task for classification and display within treeherder.  Previosly this has been mostly used for adding opt/debug/pgo/asan labels (and only one of them) to a build and it will be displayed within the same row on treeherder.  However, a task could have multiple labels, which would result in a task displayed on the same row of other tasks with the same platform and set of labels.

platform: linux64
labels: ["asan", "opt"] 
Treeherder display: Linux x64 asan opt


Note: currently taskcluster-treeherder translates "collection: {opt: true}" to "labels: ["opt"]"

Comment 3

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

From a vidyo conversation:

We will distinguish test platforms from build platforms; the language for these in the pulse messages to TH are buildMachine and runMachine.

The overall definition of a platform is now a data structure:
  platform name              "linux64"
  platform labels            set(['opt', 'asan'])
and I will define the "canonical platform string" as "<platform name>/<label>/<label>/.." with the labels sorted.  The in-tree stuff needs to be able to use strings for platforms, as object properties.  I'll write this down in the Gecko documentation and circulate it widely.  Ideally treeherder could display them the same way to avoid duplication?  Each distinct platform will get its own row in treeherder.

Labels cannot be empty (in fact, it defaults to opt, but that means that foo/opt is the canonical string)

I need to ask sheriffs if we can get rid of the "os" and "arch" fields

I also need to ask about "machine" -- philor may have some ideas here, for example distinguishing a tester in scl3 from an EC2 instance, or maybe EC2 instance type, to try to discern failure patterns.  But that should be separate from platform.

Comment 4

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

From discussion with :grenade, windows platforms should also be differentiated -- builds should be win2012-32 and win2012-64, while tests should be based on the actual test OS version.

Comment 5

[Chris AtLee [:catlee]]

It would be nice if no identifier was a prefix of any other identifier (e.g. "linux" and "linux64" in buildbot). Makes searching for things much simpler!

Comment 6

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

I like that idea.  This is going to introduce a lot of change, though!  Maybe it's easier to just wait until the 17 people still using 32-bit Linux finally upgrade to 21st-century hardware, and we drop the platform :)

Per discussions with Mike, the first step here will be to make a spreadsheet listing all of the names for platforms and how they correspond.  Then we'll try to pick the least disruptive change.

Comment 7

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

I've been convinced that this is not necessary before the BB-to-TC migration is complete, and in fact will be easier once it is complete.

Comment 8

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

I've since become convinced that nobody really knows what a "platform" is anyway, so this is not likely to be a socially tractable problem.  Likely a revamp of how treeherder displays results will help, as I think the common denominator of "platform" is "row in a treeherder push".

Comment 9

[Gregory Szorc [:gps]]

(In reply to Dustin J. Mitchell [:dustin] from comment #8)
> as I think the common
> denominator of "platform" is "row in a treeherder push".

FWIW that is the model in my head as well (for better or for worse). I don't think the platform names really mean much these days - at least for the platforms we don't ship releases from :)