Currently retriggers/job cancellation for buildbot jobs is performed via a buildapi call client side, which is protected by LDAP HTTP auth. This is a pain, since the HTTP auth only lasts for the session - and is doubling up on the treeherder Persona login. Ideally we'd do something like: 1) Provide treeherder non-LDAP protected access to buildAPI 2) Route retrigger requests performed using TH UI through the TH service, rather than calling buildapi directly. 3) Add a TH service endpoint that checks the user is logged in/has sufficient permissions, and then makes the desired retrigger/cancel request (along with appending the username of the logged in user, for auditing). A complication I can think of is that retrigger/cancel is currently behind LDAP level 3 commit access - so we'd either have to create a group of users on TH that have retrigger perms (which will likely get out of sync), or else come up with a way to check someone's commit level access on LDAP on the TH service. Also it's worth noting in bug 1076687, a similar server side approach will be needed for TC, so much of the work above will already have been done. (Plus routing all retriggers via the treeherder-service will be simpler/cleaner than having some client side, some server side).
emorley, what steps do you foresee needed to switch to the work done in bug 1168148? And to test the new system, should we select a number of users which will not trigger jobs through buildapi but use adusca's work? We can whitelist on our side. Who would be a good person to review adusca's work and determine that is a solid setup for TH?
I think bug 1170839 is a great first migration step - better than per user. I'm happy to review patches there and elsewhere :-)