When the treeherder API is stable, we should add support for it *alongside* the current direct-ES access. Treeherder probably won't have any previous history in it after it comes online, which is important to OrangeFactor. We can set a cut-off date, before which we use the old ES db, and after which we use treeherder. After some amount of time, we'll be able to switch off the ES db completely. Also, this should make switching OF back to the old ES db easier in case there is a problem with treeherder (since I imagine we will keep the old log parser writing to the ES db for a while).

(In reply to Mark Côté [:mcote] from comment #0) > When the treeherder API is stable, we should add support for it *alongside* > the current direct-ES access. Treeherder probably won't have any previous > history in it after it comes online, which is important to OrangeFactor. We > can set a cut-off date, before which we use the old ES db, and after which > we use treeherder. > After some amount of time, we'll be able to switch off the ES db completely. This approach hopefully shouldn't be necessary, since Treeherder has been populating both it's internal DB and the ES DB at the same time (at least for as long as sheriffs have been using it - 1st October), so I imagine that once this bug is fixed (which will likely be a few months out), we'll have as much data as we'll need. Tweaking summary to differentiate this from the shorter term goal of "update OrangeFactor to cope with TBPL being EOL".

(In reply to Ed Morley [:edmorley] from comment #1) > Tweaking summary to differentiate this from the shorter term goal of "update > OrangeFactor to cope with TBPL being EOL". Bug 1085728 & bug 1085730.

I think given that: (a) several parts of the current OrangeFactor either don't work properly or only support buildbot (b) Treeherder now has 4 months worth of bug classifications so we don't need to support both ES and Treeherder APIs at the same time ...it makes more sense to just rewrite a very simple MVP OrangeFactor v2 from scratch, that uses the Treeherder APIs. (We can always think of a clearer name at the same time). I'm not sure whether we should keep it as a separate (/new repo) or land it inside the treeherder repo, like Perfherder. Step 1 will be coming up with the MVP specs/use cases & working out what API we require from Treeherder, and filing bugs over there for them - since I know for sure we don't yet have sufficient APIs available for classification data.

Wontfix since we're rewriting OrangeFactor entirely instead, in bug 1367362.