1075129 - Make Treestatus part of Treeherder

Status: RESOLVED WONTFIX

(Release Engineering :: General, defect)

Description

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

Waaaay down the road, since treeherder is supposed to become the single point of truth about the state of the trees, I think that at some point the treestatus api should be moved to be part of Treeherder, so I can close a tree (or all trees) directly from Treeherder's UI.

Comment 1

[Ed Morley [:emorley]]

I know one of the intentions with the current tree status site was to make it simple, reliable and separate from other services that have worse uptime.

I'd very much like better control of the trees from treeherder - however that may be best done using the treestatus API and the persona logins that both will be using.

For example one problem with including treestatus in treeherder, is that at least for the moment, pushing a treeherder deploy causes server errors whilst the processes are being restarted (a la bug 1088226) - which would cause disruption to people to hg.m.o, since the hook would fail closed.

Also, I know gps et al see autoland becomming the main entrypoint for code in the future (ie !sheriffs never go near the tree), in which case closing the tree becomes "telling autoland to pause", which really becomes "make autoland clever enough to not push on a broken tree". As such, I'm wondering if it's worth spending too much time on rewriting treestatus to be a reliable part of treeherder, until those workflows and requirements are clearer?

Comment 2

[Ed Morley [:emorley]]

(In reply to Ed Morley [:edmorley] from comment #1)
> I'd very much like better control of the trees from treeherder - however
> that may be best done using the treestatus API and the persona logins that
> both will be using.

ie: Have treestatus remain separate, but have quick access controls in treeherder, that allow easier opening/closing without having to leave the treeherder UI (similar to the buildapi retrigger/cancel buttons that save having to visit self-serve).

Comment 3

[Ed Morley [:emorley]]

Moving this to TreeStatus, since I think the discussion needs to happen with the stakeholders there first :-) (And hopefully some of those are watching the TreeStatus component)

Comment 4

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

Comment 1/2 seems good enough to me. Wouldn't mind trying to do the work myself if we choose to go that way.

Comment 5

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

This could be done via RelengAPI now, if desired.  I don't think this is a treestatus issue anymore.

Comment 6

[Ed Morley [:emorley]]

I think this is a WONTFIX.