1224177 - status.taskcluster.net pointing to old aws provisioner?

Status: RESOLVED FIXED

(Taskcluster :: UI, defect)

Description

[Pete Moore [:pmoore][:pete]]

Attachment: Screen Shot 2015-11-12 at 13.42.12.png

See screenshot.

The dates are also wrong, but I raised bug 1224170 about that.

Assuming the dates are off by exactly 5 years (based on Auth service being intermittent, and its last entry being 10 November 2020, and today being 12 November 2015 - i.e. it seems reasonable to think it probably means 10 November 2015 and the drift is exactly 5 years) then the implied downtime of aws provisioner would then be since 30 June 2015 (not 30 June 2020), which seems about the time we moved to the new provisioner.

Comment 1

[Pete Moore [:pmoore][:pete]]

erm, correction: I raised bug 1224174 about the wrong dates. :p

Comment 2

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

John, I think someone said this was an easy fix?  It certainly doesn't look good to have a status page that says we're at 100% downtime.  Can you fix this up?

Comment 3

[John Ford [:jhford] CET/CEST Berlin Time]

yep, we just need to hit https://aws-provisioner.taskcluster.net/v1/backend-status and read the output of that.  The assumption is that if the api server is down.  If we wanted uptime robot, i guess we could have an endpoint that returned 500 if the status is not healthy.... hmm....

Comment 4

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

Who knows how to fix the status site?  I don't think we need to get more complicated -- when people complain that status was green while the service was obviously failing, we can make it more complicated.  At the moment they're seeing a red service and thinking "boy, that TaskCluster is a hot mess, I'll steer clear".

Comment 5

[Brian Stack [:bstack]]

This bug is closed as part of the Great Bugzilla Cleaning Sprint of 2016 by bstack and jonasfj, please reopen if you disagree.


I think this is all taken care of by dustin's new status page niceness.