Integrate site status page

[jonasbardino]

Integrate site status page through a vhost alias like status.BASE_FQDN on either PUBLIC_FQDN or PUBLIC_ALIAS_FQDN.
If set and users request http(s)?://status.BASE_FQDN they will be presented with the contents of state/wwwpublic/status.html which if linked to the default status-dynamic.html delivers dynamic contents based on the the json status events entries in
state/wwwpublic/status-events.json
A basic example and a complete set of actual events are included in the corresponding state/wwwpublic folder of the migrid-ucph-sites repo at https://github.com/ucphhpc/migrid-ucph-sites
with an actual deployment visible on
https://status.erda.dk

Includes basic unit test updates to make sure the existing tests complete without errors but no specific tests to further test variations in configuration values, which would of course be nice to have.

Includes minor consistency fixes in the apache ports template.

[jonasbardino]

Merged through svn.

[alexjeffburke]

Fwiw, I think we should seriously consider fully decoupling the status page.

Rather than the rendering logic for a JSON file of status items existing in the migrid repo, moving that within a status service would allow us to iterate on that standalone, avoid needing multiple places having knowledge of the status item data structures and most importantly allow updating its contents completely independently.

[jonasbardino]

I see your point but the devil in the detail here is that this status is actually shared between the colored status-icon popup integrated bottom right on migrid user pages and the status overview page which runs both locally and on a separate host for redundancy (as in status.erda.dk).
Some of the infrastructure could be further separated and perhaps should, but the event structure and parsing for the status-icon popup would not go away.
It is similar to the coupling we have for html-snippets used both on the site front page (index.html) and in the Support and About popups on user pages.

[alexjeffburke]

Hm, is the popup somehow user specific? Otherwise couldn’t the status server just have a /popup route that returns that as well? Agree the devil is in the detail, and I confess I’ve gone through it all with a fine comb, but from the requirements I am aware of at least currently I’m not understanding a need for the coupling.