Claus Ibsen created CAMEL-26689:
-----------------------------------
Summary: camel-chaos - a model of the chaos rules in
camel-catalog: targets, hooks, faults, parameters and known rules
Key: CAMEL-26689
URL: https://issues.apache.org/jira/browse/CAMEL-26689
Project: Camel
Issue Type: Improvement
Components: camel-catalog, camel-jbang
Reporter: Claus Ibsen
Fix For: 4.24.0
The vocabulary of the camel-chaos rules lives only in the code of
{{ChaosRuleParser}}: the targets ({{endpoint=}}, {{component=}}, {{route=}},
{{step=}}), the hooks each target has, the faults each hook offers, the
parameters of each fault with their types and limits, and the general options
({{rate}}, {{until}}, {{from}}, {{at}}, {{expect}}, {{within}}). Tools that
help people write rules need it as data:
* the chaos screen (CAMEL-26608): an add form with fields, pickers and a live
preview, and "chaos here" on a diagram node, offering only the faults that node
can take;
* the AI of stage 2 (CAMEL-26607), which turns a loose prompt ("the order route
should fail 5%") into rules;
* the MCP catalog tools and the docs.
h3. Proposal
A {{chaos-model.json}} in camel-chaos, copied to camel-catalog like the dev
consoles:
* *targets*: name, description, what a picker offers (endpoints, routes, steps);
* *hooks*: name, the targets that have it, the faults it offers, and whether it
is reached only with {{at=}} ({{reply}}, {{dlq}});
* *faults*: the parameters, with type (class, duration, duration range,
integer, enum, header map) and limits (status 300-599, the HTTP schemes of
{{status=}}, {{after=}} not at {{reply}}, the corrupt modes, the lifecycle
actions, repeat 1-100);
* *options*: {{rate}} in its three forms (probability, {{every:N}},
{{burst:on/period}}), {{until}}, {{from}}, {{expect}} with its kinds and ops,
{{within}};
* *recipes*: the known rules in plain words, grouped by what goes wrong, each a
rule template with placeholders and defaults, for example "Downstream returns
an error (HTTP 503)": {{endpoint=$\{http\} error status=$\{status:503\}
rate=$\{rate:0.25\} until=$\{until:10m\}}}, "Did the work, then failed":
{{endpoint=$\{producer\} error at=reply until=1}}, "The route flaps":
{{route=$\{route\} lifecycle action=stop duration=10s repeat=3 every=1m}}.
h3. Keeping it true
* The parser stays the source of truth. A golden-style test builds the model
from the parser's own tables ({{ChaosRuleParser.offered()}}, the parameter
keys, the modes, actions, expectation kinds and ops) and fails when the
committed file differs; {{-Dcamel.chaos.updateModel=true}} writes it again, as
the CLI help golden test does.
* The recipes are written by hand. The same test fills each recipe with its
sample values and parses it, so a recipe that no longer parses fails the build.
* {{PrepareCatalogMojo}} copies the file into camel-catalog, with
{{CamelCatalog.chaosModelJSon()}}.
* The running integration still checks every rule when it is added
({{chaos-add}} refuses with the reason), so a tool with a catalog of another
version cannot add a broken rule: at worst it offers a recipe that the
integration refuses with a clear message.
Not chosen: a {{model}} option on the chaos dev console. It would always match
the running version, but the docs, the MCP catalog tools and an AI without a
running integration could not use it. It can be added later if version skew
turns out to matter.
The chaos screen design that this comes from:
https://claude.ai/artifact/8nzJQAAjBpFWVKrexaoPZT (section 6).
_Claude Code on behalf of Claus Ibsen_
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
