Stage 5 gives Waystone a web panel: a login page, and buttons for start, stop and the operation history. That means the controller will answer browsers for the first time. Before writing a single page, I wanted the door they come through to be solid. Stage WS is that door. There's no UI in it yet. It's the part every page will stand on.
At the end of 4b-2 the controller could take requests and the agent could report what was running, but nothing connected the two. A start request was written down and then just sat there. Stage 4c joins them up. You ask the controller to start a server, the agent on that machine carries it out, and the result is recorded against the operation. Then all of it moves out of my terminal windows and into systemd, where it runs by itself and comes back after a reboot.
Since stage 4a, Waystone has been able to record that someone asked for a server to start. What it can't do yet is hear back from the machine the server runs on. In stage 4b the agent on each machine connects to the controller and reports what's really running. 4b-1 is the half of that which lives in the database: what a "connection" means, what a report may change, and who is allowed to send one.
Stage 4a-1 gave Waystone a memory: a PostgreSQL database where every action is recorded as an operation before it happens. But nothing could talk to it yet. Stage 4a-2 adds the controller's API, the front door that the web interface, the command line and eventually everything else will come through.
Through stage 3, Waystone could build a Minecraft server from nothing, install its jar and start or stop it, all without root. But it had no memory. Once a request was done, nothing recorded who asked for it, what happened, or whether it was still running. Stage 4 gives Waystone a controller that keeps that record, and stage 4a-1 is its foundation: the database.
In Stage 3c-1, Waystone learned to write a server's settings and accept the EULA through a sandboxed worker. One manual step was left: the Minecraft jar. Until now, I copied it into each server's folder by hand. As of Stage 3c-2, that's gone too. A server now goes from nothing to running in five steps, and nothing gets copied onto the machine by hand:
In Stage 3b, Waystone learned to create a game server from scratch: its own Linux account, data directory and systemd unit. I still had to copy the Minecraft jar and write its configuration by hand, though. Stage 3c is about removing those last manual steps.
In Stage 3a, Waystone learned to start and stop a Minecraft server. There was a catch: I had to set that server up by hand first, including its user, its folder and its systemd unit. As of Stage 3b, that's no longer true. One request now gives a game server everything it needs to exist on a machine.
Waystone just started and stopped its first Minecraft server through the real agent path. On screen it's a handful of commands in a terminal. Underneath, it's the security boundary the rest of the panel will stand on, so here's what's in that screenshot and why it's built this way.