Open Bug 1416861 Opened 2 years ago Updated 23 days ago

Remove signature hash use in API endpoints

Categories

(Tree Management :: Perfherder, enhancement, P3)

enhancement

Tracking

(Not tracked)

People

(Reporter: wlach, Unassigned)

References

(Blocks 1 open bug)

Details

In bug 1265709 I expressed the wish that Perfherder do away with the notion of the signature hash. Since I filed that, additional problems with this approach came up that convinced me more than ever that this is the right thing to do, for example bug 1309294.

I've removed most of the client-side code that references signatures (with one small exception: https://github.com/mozilla/treeherder/blob/e513dd9a2e31e8f78507b4687f984b756726e6b2/ui/js/models/perf/alerts.js#L26), however the existing endpoints still return signature hashes as part of their payload.

I think we'd be best off just replacing these with some new endpoints. These are also the only two performance endpoints that reference the project in the url, which is no longer really necessary.

/api/performance/signatures/ (replacing /api/project/<projectname>/performance/sigantures/)
-------------------------------------------------------------------------
Should take a very similar set of options to the current signature API, but instead of indexing by signature hash, just return a plain list. e.g.:

[
    {
        "suite": "tps",
        "machine_platform": "linux64",
        "framework_id": 1,
        "has_subtests": true,
        "id": 1305969,
        "option_collection_hash": "102210fe594ee9b33d82058545b1ed14f4c8206e",
        "extra_options": [
            "e10s"
        ]
    },
    {
        "suite": "glvideo",
        "machine_platform": "linux64",
        "framework_id": 1,
        "id": 1484241,
        "test": "Mean tick time across 100 ticks: ",
        "option_collection_hash": "f69e1b00908837bf0550250abb1645014317e8ec",
        "extra_options": [
            "e10s"
        ]
    },
    ...
]

/api/performance/data/ (replacing  /api/project/<projectname>/performance/sigantures/)
-------------------------------------------------------------------------
Similar to the above. We now return 'signature_id' as part of each performance datum, which should let us say which signature the returned datum would apply to.

To handle the one exception case I mention above, ensure that the /api/performance/signatures/ endpoint has enough query parameters to be able to quickly fetch the other equivalent signatures on other branches.

--

I would initially implement this as a set of new APIs, keeping the old ones intact. After a transition period of 6 months or so, we could just retire the old APIs (and remove the signature hash from the performance datum db model?)
Blocks: 1178227
Priority: -- → P3
Summary: Do away with the signature hash (for real this time) → Remove signature hash use in API endpoints
See Also: → 1519289
You need to log in before you can comment on or make changes to this bug.