dedicated MH build server (and results distribution)

[kohlhase]

Tom and I have been talking about the build process on MathHub: during a (successful) PVS build (the MMT side of) MathHub was practically inaccessible (and died after the build). And that seems inherent in the design that uses one MMT process for both user queries (that is mostly what MathHub needs) and building. So we propose the following design for discussion. It splits building from user queries, i.e. for MathHub we are running two servers (possibly on different machines):

the MMT build server

A dedicated MMT process without any drupal support, on a beefy (virtual) machine

• it has the normal tiscaf web server, which serves
  • Christian's build queue viewer (currently at https://mathhub.info/mh/mmt/buildqueue.html)
  • Christian's error viewer (currently at https://mathhub.info/mh/mmt/errorview.html)
  • Florian's MMT web front end (currently at https://mathhub.info/mh/mmt).
• It also serves an API that
  • allows to gl.mathhub.info alert it of changes in the repository, then it does an update build for the affected archives
  • gives build status information (queue length, load, ETA, ... )
  • services all the requests currently on https://mathhub.info/mh/administrate_mathhub whenever the build queue terminates (whatever that really means, it could be that it terminates only on one math archive, ... then it pushes the generated results to http://gl.mathhub.info. This machine should have good authentification in the web frontend, which should be coordinated with the main MH server, essentially only the MH admins should be able to run things there.

the MH frontend server

This is essentially the setup we currently have only that it does not build anything anymore. Instead it gets all generated content from the MH build server via the GL repositories. For that it pulls content either regularly or upon alert from the build server (or both).

Prerequisites

• [ ] GitLab-based distribution of generated results works (see #253 and #254)
• [ ] working and stable MMT-based build system
• [ ] authentification for the MMT API. (see #243)

[kohlhase]

Here is another thought, we might just use the continuous integration workflow provided by GitLab to do all the mechanics. Something like @tkw1536 did for the KWARC bibs. But maybe with a continuously existing MMT server?

[tkw1536]

This should really be an MMT issue