- page_scenario.go: onclick built via JSON.stringify() embedded raw double
quotes inside a double-quoted HTML attribute, truncating the attribute so
the click handler never compiled; pass the name through an escaped
data-scenario-name attribute instead.
- build.sh: overlay staging rsyncs (OVERLAY_DIR->stage, stage->includes.chroot)
ran without --delete, so a scenario removed from the repo (a9924b0) stayed
baked into every ISO built from the persistent stage cache since — the
"second script" in the Scenario page's list.
- blackbox: rewritten around a deterministic local zip + incremental
patch-the-changed-suffix onto removable media, instead of walking/copying
~90 files through a synchronous ntfs-3g FUSE mount every cycle. journalctl
captures are now "--since last sync" (were "--since boot", growing with
uptime) and metrics.db is excluded (was copied whole every cycle).
- scenario: nvbandwidth-acs-ab now escalates GPU count (same-socket pair,
other socket's pair, one cross-socket pair, all GPUs) under each ACS state
instead of always running all 6 GPUs at once, using a new `bee
gpu-bandwidth-groups` subcommand that discovers socket layout from
`nvidia-smi topo -m` at runtime — gpu_indices is host-specific, so this
can't be baked into the scenario file.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
bee test scenarios
A scenario is a plain JSON file describing an ad-hoc diagnostic run: which
commands to execute (sequentially or in parallel) and what to sample in the
background while they run — without hardcoding a new test into bee's own
code. See audit/internal/platform/scenario.go (ParseScenarioJSON,
ScenarioSpec) for the full field reference.
Running one
bee run <path-to-file.json>
or, for a bare name (no /, no .json):
bee run <name>
which resolves scenarios/<name>.json by checking, in order: (1) the
scenarios shipped with the image itself — always available, no media
needed — then (2) any mounted removable drive (e.g. the same USB stick
already plugged in for blackbox), for scenarios authored on another
machine and dropped there without a network path onto the host. Same
resolution powers the "6. Scenario" page in the web UI.
bee scenario run <arg> is the same command under a longer name.
Files checked in here
nvbandwidth-all-gpu-power-watch.json— the scenario that reproduced the CG480-S6053 reboot: fullnvbandwidthacross all GPUs at once (the per-GPU-socket passes alone never reproduced it), withipmitool sensorandnvidia-smipower/temp sampled every 2s in the background so a crash mid-run still leaves telemetry to check for a power-delivery correlation.gpu_indicesis host-specific — update it to match the GPU indicesnvidia-smi -Lactually reports on the box under test before running.
This directory is the source of truth; iso/builder/build.sh's "preparing
staged overlay" step rsyncs the whole overlay tree — including a checked-in
copy under iso/overlay/usr/share/bee/scenarios/ — into the built image, so
anything meant to ship baked-in needs to exist in both places (this repo
doesn't auto-copy one into the other). platform.LocalScenariosDir
(/usr/share/bee/scenarios on the built host) is what bee run <name>/the
web UI actually reads at runtime.
Adding more
Not every scenario needs to ship in the image. For a one-off test on a
specific host (especially air-gapped), it's simpler to write the JSON file
directly onto the blackbox USB stick under scenarios/<name>.json and run
bee run <name> — no code change, no rebuild. Check a scenario into
iso/overlay/usr/share/bee/scenarios/ only when it's worth keeping around
as a reusable/named test that should be available on every host without a
USB stick.