Skip to content

feat(chaos): registry-driven fault/trigger axes, lazy agent#31

Draft
pradeepvrd wants to merge 1 commit into
submit/5-agents-apifrom
submit/6-chaos
Draft

feat(chaos): registry-driven fault/trigger axes, lazy agent#31
pradeepvrd wants to merge 1 commit into
submit/5-agents-apifrom
submit/6-chaos

Conversation

@pradeepvrd

@pradeepvrd pradeepvrd commented Jun 20, 2026

Copy link
Copy Markdown
Owner

Chaos used to live in pkg/agents/chaos/ as a single Gemini agent hardwired to fortio load generation; this migrates it into devops_bench/chaos/ with registry-driven axes: a FAULTS registry (generate_load), a TRIGGERS registry (time), a typed ChaosSpec parser, and a lazily-imported ChaosAgent on models.loop.

Behavior changes

  • Fault/trigger types are extensible via @FAULTS.register / @TRIGGERS.register; the spec parser validates action.type / trigger.type against the registry (unknown types raise ValidationError) rather than a hand-maintained Union.
  • Concrete faults/triggers import eagerly so the registries populate, but the agent + provider SDK chain stays lazy — import devops_bench.chaos never touches a provider SDK.
  • ChaosAgent is provider-agnostic via get_model() (provider SDKs are optional extras); each fault owns its tool handlers and command lifecycle.

Bugs fixed

  • Fault commands run as a shell-free argv via core.subprocess.run (parsed with shlex.split) instead of subprocess.run(..., shell=True), so model-generated commands are no longer shell-interpreted.

Comment thread devops_bench/chaos/faults/generate_load.py Outdated
Comment thread devops_bench/chaos/faults/generate_load.py Outdated
Comment thread devops_bench/chaos/registry.py Outdated
Comment thread devops_bench/chaos/spec.py Outdated
Comment thread devops_bench/chaos/spec.py Outdated
@pradeepvrd pradeepvrd force-pushed the submit/5-agents-api branch from e6d22f4 to 2fa6e73 Compare June 21, 2026 01:30
@pradeepvrd pradeepvrd force-pushed the submit/5-agents-api branch from 2fa6e73 to ddf3ce9 Compare June 22, 2026 01:53
@pradeepvrd pradeepvrd force-pushed the submit/5-agents-api branch from ddf3ce9 to 307bb21 Compare June 23, 2026 05:04
@pradeepvrd pradeepvrd force-pushed the submit/5-agents-api branch from 307bb21 to 915b68f Compare June 23, 2026 06:08
@pradeepvrd pradeepvrd changed the title feat(chaos): registry-driven fault/trigger axes, lazy agent [+#21,#22] feat(chaos): registry-driven fault/trigger axes, lazy agent Jun 23, 2026
@pradeepvrd pradeepvrd force-pushed the submit/5-agents-api branch from 915b68f to 885f8b8 Compare June 23, 2026 06:37
@pradeepvrd pradeepvrd force-pushed the submit/5-agents-api branch from 885f8b8 to 90261d8 Compare June 23, 2026 07:25
@pradeepvrd pradeepvrd force-pushed the submit/6-chaos branch 2 times, most recently from 9db9100 to ba65ba9 Compare June 23, 2026 08:21
@pradeepvrd pradeepvrd force-pushed the submit/5-agents-api branch from 90261d8 to 073719a Compare June 23, 2026 18:13
Chaos used to live in `pkg/agents/chaos/` as a single Gemini agent hardwired to fortio load generation; this migrates it into `devops_bench/chaos/` with registry-driven axes: a `FAULTS` registry (`generate_load`), a `TRIGGERS` registry (`time`), a typed `ChaosSpec` parser, and a lazily-imported `ChaosAgent` on `models.loop`.

**Behavior changes**
- Fault/trigger types are extensible via `@FAULTS.register` / `@TRIGGERS.register`; the spec parser validates `action.type` / `trigger.type` against the registry (unknown types raise `ValidationError`) rather than a hand-maintained `Union`.
- Concrete faults/triggers import eagerly so the registries populate, but the agent + provider SDK chain stays lazy — `import devops_bench.chaos` never touches a provider SDK.
- `ChaosAgent` is provider-agnostic via `get_model()` (provider SDKs are optional extras); each fault owns its tool handlers and command lifecycle.

**Bugs fixed**
- Fault commands run as a shell-free argv via `core.subprocess.run` (parsed with `shlex.split`) instead of `subprocess.run(..., shell=True)`, so model-generated commands are no longer shell-interpreted.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant