1375520 - Create a service/API for performing backouts which could be exposed via Treeherder's UI

Status: NEW

(Developer Services :: General, task)

Description

[Carsten Book [:Tomcat]]

We did a Sheriff Survey to find out what people think about Sheriffing and also what could be improved in General (workflow, tools, CI).

One popular demand was a "backout button" in treeherder. I think this is actually a great idea but i think needs vcs work/requirement first.

Not sure what people think if we should use this as meta bug or if should file a second bug as treeherder Bug.

A backout button (likely only visible to like level 3 User) would have the benefit of:

-> Faster backout on a bustage 
-> Does not need to have a sheriff around if someone notice (like on a weekend) a bustage but is not aware of the steps to do a backout
-> Streamlined workflow - not someone using qbackout, someone hg backout and the other some different

Comment 1

[Ed Morley [:emorley]]

I agree this sounds like a good idea. Seems to fit with the idea of locking repos down and reducing number of people with direct commit access too.

This definitely isn't a Treeherder bug for now (morphing summary to make this clearer) - creating a service to do this is the hard part, Treeherder would then either link to this new service's frontend, or else make a client side API call. I'm presuming auth would be done with Taskcluster auth + scopes or similar.

Comment 2

[Gregory Szorc [:gps]]

The auth bit of this is a bit difficult. Likely operates similarly to Autoland. The way that works is MozReview associates your BMO login with your LDAP credentials by having you ssh into reviewboard-hg.mozilla.org. Then there is a backchannel HTTP request to Autoland where MozReview basically says "user X [whom I'm trusted to speak for]" wants to do X. For this to work, we'd need a formal trust relationship between Treeherder and Autoland and we need to figure out how to map Treeherder logins to LDAP so attribution in version control is correct. (Or you can have Autoland maintain the mapping.) I'm not sure how Phabricator is solving this. It is possible you can piggyback off whatever they are doing.

I really wish we had time to move hg.mo from LDAP to auth0 to make identity management easier...

Comment 3

[Ed Morley [:emorley]]

(In reply to Gregory Szorc [:gps] from comment #2)
> we'd need a formal trust relationship between Treeherder and Autoland 
> and we need to figure out how to map Treeherder logins to LDAP so
> attribution in version control is correct.

Just to emphasise comment 1 - my strong preference would be for Treeherder to have virtually no part in this at all, beyond either linking to a separate dashboard/page somewhere (which would perform its own auth), or else making a client side API call to this service using the taskcluster token stored in localstorage [1].

As such there would be *no* trust relationship between Treeherder and this service, and no need to map anything, since Taskcluster auth exposes the underlying LDAP user and groups (such as scm_level3).


[1] this token is already used for things like taskcluster client-side job retriggers.

Comment 4

[Gregory Szorc [:gps]]

OK. We still need to establish a trust relationship *somewhere*. And if we follow the model of MozReview <-> Autoland, that involves limiting IPs that can access the service, a formal security review, etc. Basically the Autoland service is allowed to spoof pushlog data and that's not something we can expose lightly.

Comment 5

[Ed Morley [:emorley]]

Yes I realise, my point was that this can be simpler than it might be if Treeherder were involved, since we can bootstrap existing auth mechanisms (given TC auth is used very pervasively throughout CI so far, and will be performing more actions like automated pushes for eg HSTS updates in the future) rather than having to involve a third/forth/... system.