Skip to main content
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: even when the prior run was interrupted mid-way. 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 your 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 /etc/2501/env.runner 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. Place an inventory.ini file in the scenario directory: the runner detects it automatically and passes it to every ansible-playbook call for that scenario. Standard Ansible INI format:
The hostnames must match the logical names used in scenario.json so the runner can correlate them correctly.
If no inventory.ini is present, 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.