build.macports.org: implement simple front-end to display status; including "down for maintenance" (if intentional), or "no response from buildbot infrastructure" (for unanticipated issues)

[mascguy (Christopher Nielsen)]

Presently, when things are down, build.macports.org doesn't provide a response. So we have to infer that things have been taken down for maintenance/restarts, with no real way to tell whether it's intentional or not.

So it would be great if we could implement some type of simple front-end/reverse-proxy - say, via Apache or whatever - to provide an info page.

Ideally there would be something to tell us when things are down for maintenance, as well as when things aren't responding when they should.

This would both reduce the number of queries to the dev mailing list, and/or direct e-mails to @ryandesign when things aren't working.

[ryandesign (Ryan Carsten Schmidt)]

When the internet connection that build.macports.org uses is down, as it was today, and on May 31, and on May 30, there is no way for it to provide a response.

If you're suggesting routing all build.macports.org web traffic through another server on a different internet connection so that it could provide a message when the real server is unreachable, which server would we use for that?

Conceivably we could use Braeburn, the server that powers www.macports.org and trac.macports.org. But I'm not sure if it has the capacity to accommodate that additional traffic. And it is in Germany and the buildmaster is in Texas. I'm not sure if introducing additional network delay to all requests is best, since people already complain that it responds slowly (which is both because of limited upstream network bandwidth and the amount of time it takes buildbot 0.8 to respond to some types of requests). It also introduces an additional point of failure. I usually keep a close eye on the buildbot and know when it is down and what I need to do to get it back online, but that changes when additional servers outside of my control are added in.

When I shut the servers down in anticipation of a thunderstorm and possible power outage, I leave the internet connection and router on, and the router could conceivably act as reverse proxy to provide a message when the backend is down. It might also be nice to let the router handle TLS and certificates. I did attempt to set that up about a year ago but didn't complete it.

[mascguy (Christopher Nielsen)]

Replying to ryandesign:

When the internet connection that build.macports.org uses is down, as it was today, and on May 31, and on May 30, there is no way for it to provide a response.

Fair enough, and no worries for that case.

When I shut the servers down in anticipation of a thunderstorm and possible power outage, I leave the internet connection and router on, and the router could conceivably act as reverse proxy to provide a message when the backend is down. It might also be nice to let the router handle TLS and certificates. I did attempt to set that up about a year ago but didn't complete it.

Yep, that's super-simple, and eliminates worries regarding capacity and such. So I'd vote for an approach like that, assuming it's not a major pain to setup.