A lab PC running PLESTY Bench is a bench. This page covers the three things a bench keeps track of: the devices it serves, grouped in fleets; its own folder on the lab's shared disk, the Plesty share; and the runs written into that folder, each one a complete record.
A bench, and the benches it drives
Each bench runs an agent: a small service, guarded by a password-like token, that lets another bench ask it to start or stop its devices. A bench in the master role shows other benches' devices beside its own and can start runs that use them. The other benches are nodes, which only serve their own devices. Networking shows how the agents and device servers connect.
Fleets: the devices a bench serves
A fleet is a list of devices in a file. For each device it records the
module, its version, its address and whether it starts with the others. A
bench holds one or more fleets, each a file <name>.yaml in its fleets/
folder. A new bench starts with an empty fleets/default.yaml. Then the
console and the agent open the same file from the start.
plesty-server fleet new trial # a second fleet, fleets/trial.yaml
plesty-server fleet list # every fleet, its file and device count
plesty-server declare spec <package> --fleet trial # declare a device into one fleet
Each device name belongs to one fleet only. plesty-bench -b <bench> … runs the
same commands on another bench, so a setup script can provision a bench
without sitting at it.
In the console, View ▸ Fleet has a tick box for each fleet and for each other bench. Tick any mix of them, or All (the default), and one table shows those devices. The Fleet column says which fleet each device is in. Every write to a fleet re-reads its file first, so a device declared through the agent appears without a restart and is never overwritten. Run It on a Bench covers declaring and starting devices.
A bench set up before fleets keeps its old fleet.yaml.
The Plesty share, and each bench's folder
The Plesty share is the lab's shared disk. Every PC mounts it under its own
path, for example /mnt/plesty on one PC and G:\Plesty on another. Each bench
has its own folder inside the share, such as bench-a, and that folder is
the one place its devices may write.
G:\Plestybench-aG:\Plesty\bench-a\/mnt/plesty/mnt/plesty/bench-a/bench-a/pol-pl/<run id>/raw/spec/…To set a bench's share and folder, use Server ▸ Configure…, or the command line:
plesty-server data-path G:\Plesty --folder bench-a
The Windows installer also asks for them during install, and Skip leaves them for later. The folder is created if it is missing.
How a device is told where to write
When a bench starts a device, it passes the device three environment variables:
| Variable | Value | Meaning |
|---|---|---|
PLESTY_DATA |
the share, as this PC mounts it | where every recorded path starts |
DEVICE_DATA_ROOT |
the bench's folder in the share | the only place the device may write |
DEVICE_DATA_PATH |
<bench folder>/<data_dir>, or <bench folder>/tmp/<device> |
where the device writes until told otherwise |
data_dir is the device's entry in the fleet, a path relative to the bench's
folder. An absolute data_dir, or one that climbs out with .., is refused. A
device's own .env or the fleet's env: can still override the folder; an
experiment's setup no longer can.
To steer a device's files elsewhere, a client calls set_data_path(path). The
path is taken relative to the bench's folder. An absolute path, a drive
letter or ~ is refused. The device answers with the folder it now writes to,
relative to the share: bench-a/pol-pl/<run id>/raw/spec. An experiment
doesn't call this itself. It calls self.route(...), which does it for each
device and keeps each answer (see Plan & Steps).
A bench with no share set still gives its devices a data path, inside its home
folder: data/<data_dir>, or data/tmp/<device>. A single PC needs no share at
all.
A run's folder is its own record
Each measurement, a run, gets one folder on the share (Data Flow explains why it is the only place the programs meet). As of PLESTY Bench 0.5.0, everything about the run is kept there, beside its data, and none of it only in the bench that ran it:
| In the run folder | What it is |
|---|---|
config.yaml |
the settings this run used. Configure saves here, never into the experiment module's own files |
records.jsonl, journal.jsonl |
what was measured, step by step, and what happened |
raw/<device>/ |
each device's files, in its own bench's folder of the share |
created.json |
who created the run: the operator, which Create run asks for |
notes.txt |
the run's notes, one entry each, naming when and by whom (Experiment ▸ Add note…) |
job-logs/<job>.log |
the run's log, copied in when its job ends, however it ends |
report.html |
the measurement report, written when the run ends |
So any bench that sees the share can open the run, show its log and read its report, including one that didn't measure it. A run also outlives the bench that measured it: uninstalling the bench, or emptying its home folder, leaves the run whole. Runs measured before 0.5.0 kept no log of their own.
To read a run from Python on any PC, use Run. Run.local() turns each
recorded path into this PC's path:
from plesty.lib.experiment import Run, latest_run
run = Run(latest_run("/mnt/plesty/pol-pl", name="pol_pl"))
for record in run.records():
print(run.local(record["data_file"]))
Versions
- Several fleets, the share with a folder per bench, and the run's own log, operator and notes: PLESTY Bench 0.5.0.
DEVICE_DATA_ROOT,set_data_pathrelative to the bench folder, andself.route(...): plesty-lib 0.6.0, a breaking change for device and experiment modules (see its changelog for the migration).
Read next
- Networking — how benches, agents and device servers connect.
- Data Flow — what goes into a run folder, step by step.
- Run It on a Bench — declare a device and start it.