Three optional Ansible playbooks can live in a scenario directory. The runner discovers and invokes them automatically at the right point in the execution cycle.
Execution Flow
prepare.yml
Runs before the agent executes. Use it to introduce the failure condition the scenario is benchmarking.
Before prepare.yml runs, the runner silently executes restore.yml with errors suppressed. This clears leftover state from any previous failed run so each execution starts from a known baseline.
If prepare.yml itself fails, execution is aborted and the scenario is marked as failed.
restore.yml
Runs after validation, during cleanup. Use it to reset the host to a clean baseline.
Restore failures are non-fatal: the runner logs a warning and continues. Write restore playbooks defensively with ignore_errors: true on steps that may fail on an already-clean host.
validate.yml
Runs after execution as part of the validation phase. Use it to verify that the agent’s actions actually worked: service status, file contents, port availability, process list.
Declared in scenario.json as an ansible validator:
A non-zero exit code fails the resolution gate and marks the scenario as failed.
Using Environment Variables
Variables from the env file are available in all playbooks via lookup('env', ...):
inventory.ini
The runner needs an Ansible inventory to know which hosts to target and how to reach them.
Host mode: place an inventory.ini in the scenario directory. The runner detects it automatically and passes it to every ansible-playbook call.
VM mode (incus/lima): the runner generates the inventory automatically from the provisioned VM’s IP, port, and SSH key. You do not need an inventory.ini.
The hostnames must match the host_name values used in scenario.json.
If no inventory.ini is present in host mode, ansible-playbook runs without an explicit inventory. Your playbooks won’t be able to reach any hosts. Always include inventory.ini when your scenario has playbooks.