Labs and courses

Several copies that do not collide

Every instance puts its own prefix in front of every name, so two copies with the same internal addresses do not get in each other's way. That is what makes a lab usable for a class rather than for one person.

Building, resetting and tearing down are one permission: an instance is meant to be disposable, and whoever may build one may throw it away.

The engine builds nothing itself

Creating a VM, a container or a network is already written down once, together with every check that belongs to it. The lab engine calls exactly those functions and waits for their tasks instead of laying disks down itself.

A second path for creating guests would drift away from the first one at the latest with the next change there — and then a lab would build machines that differ from the ones the rest of the product builds.

Exercises that mark themselves

A lab carries exercises with points, hints, a solution and an order. The checks run against the built environment rather than against an answer sheet, and they run through the host — no network in the lab is needed for them to work.

Participants get their own view of the lab they are working in. Several labs form a course, and the results come out as a file a spreadsheet reads.

A network that behaves like the real one

An isolated lab has no way out, which is the point of it: something that must not reach the internet cannot. Provisioning happens when the guests are set up, before the exercise starts.

And where the exercise is about a bad line, latency, loss and a rate cap can be set on a guest — so an application meets the branch office over a satellite link here, and not on the day it goes there.