[Tech Debt]: Wire chaos workload params through WorkloadConfig.Params

[mrhillsman]

Category

Hardcoded values

Description

The configuration reference (docs/configuration.md) and the chaos workload guide (docs/chaos-workloads.md) document YAML-tunable params for all three chaos workloads, mirroring how the tps workload exposes file-size, iterations, and duration through WorkloadConfig.Params. The code does not implement this surface:

• internal/workloads/chaos_disk.go — the in-VM script references ${CHAOS_DISK_MOUNT}, ${CHAOS_DISK_FILL_PERCENT}, ${CHAOS_DISK_FILL_SLEEP}, ${CHAOS_DISK_RELEASE_SLEEP} with shell defaults, but the systemd unit never sets these env vars. Defaults are the only achievable values without exec'ing into the VM and editing the unit.
• internal/workloads/chaos_network.go — Latency (100ms) and PacketLoss (5%) are Go struct fields hardcoded inside NewChaosNetworkWorkload. No Config.Params read, no env var, no YAML override.
• internal/workloads/chaos_process.go — CHAOS_SIGNAL, CHAOS_INTERVAL, CHAOS_MIN_PID are hardcoded Environment= lines in chaosProcessSystemdUnit. The shell script reads them, but they always have the same value.

internal/workloads/tps.go is the working reference — it reads w.Config.Params["file-size" | "iterations" | "duration"] and bakes the values into the in-VM scripts.

Severity

Medium — increases maintenance burden or risk of future bugs

Affected Files

• internal/workloads/chaos_disk.go — script + systemd unit
• internal/workloads/chaos_network.go — Latency / PacketLoss fields, script
• internal/workloads/chaos_process.go — script + systemd unit Environment= lines
• internal/workloads/chaos_disk_test.go — assertions for parameter flow-through
• internal/workloads/chaos_network_test.go — same
• internal/workloads/chaos_process_test.go — same

(File paths assume the rename in the companion tech-debt issue [chaos-network.go → chaos_network.go] has landed. If not, substitute the hyphenated names.)

Proposed Fix

Mirror the tps pattern. For each chaos workload, read the documented YAML keys from Config.Params (with the documented defaults if absent) and inject either via sprintf into the script or via systemd Environment= lines:

Workload	YAML key	Default	Where to inject
chaos-disk	mount	/mnt/data	Both diskSetupScript mountpoint and chaosDiskScript MOUNT_POINT
chaos-disk	fill-percent	90	systemd Environment= or sprintf
chaos-disk	fill-sleep	60	same
chaos-disk	release-sleep	30	same
chaos-network	latency-ms	100	sprintf into chaosNetworkStartScript (already format-stringed)
chaos-network	packet-loss-percent	5.0	same
chaos-process	signal	SIGTERM	systemd Environment=CHAOS_SIGNAL=...
chaos-process	interval	30	systemd Environment=CHAOS_INTERVAL=...
chaos-process	min-pid	1000	systemd Environment=CHAOS_MIN_PID=...

Add tests that assert each parameter flows from WorkloadConfig.Params into the rendered cloud-init userdata.

Area

Workloads

Architecture Layer

Layer 3 - Workload Definitions (workloads, registry)

Additional Context

This is the largest gap surfaced by the documentation overhaul on docs/comprehensive-overhaul. The docs (chaos-workloads.md, configuration.md) describe the intended surface; treating them as a spec, this issue closes the gap between documented and implemented behavior.

Related: chaos-disk also has a mountpoint-consistency issue tracked separately.