shashank created CAMEL-26436:
--------------------------------
Summary: camel-chaos - control a running application from the
Camel CLI: a chaos dev console, camel cmd chaos-*, camel get chaos
Key: CAMEL-26436
URL: https://issues.apache.org/jira/browse/CAMEL-26436
Project: Camel
Issue Type: Improvement
Components: camel-jbang, camel-cli-connector
Reporter: shashank
Assignee: shashank
Next stage of CAMEL-26330 (design/chaos.adoc, section "Control", step 3 of
"Order of work"), after CAMEL-26330 (apache/camel#28716) and CAMEL-26418
(apache/camel#28754) put {{components/camel-chaos}} on main. So far rules can
only be added with {{camel.chaos.rules}} at startup or from Java
({{ChaosManager}}); the design adds them to a running application from the
Camel CLI.
*Proposal*
* A {{chaos}} dev console in camel-chaos, read only ({{@DevConsole}},
{{isReadOnly()}} true): the current rules (id, version, state, matches, faults,
end), the report (verdict, final, seed, all versions of every rule, counts per
route), or why chaos is off. It has no option that adds, changes or removes a
rule: {{/q/dev/*}} passes any query parameter as an option, so over HTTP chaos
only lists and reports.
* A {{chaos}} action in the CLI connector ({{LocalCliConnector}}): add, change,
remove and clear through {{ChaosManager}}, with the same parser as
{{camel.chaos.rules}}; a rule that is not valid is refused with the reason, an
id that does not exist (change or remove) is "not found". It works only when
chaos is switched on (profile {{dev}} or {{camel.chaos.enabled=true}}, never
profile {{prod}}): the action never creates a {{ChaosManager}}, so it cannot
switch chaos on. camel-cli-connector does not depend on camel-chaos (with
{{camel run}} the JAR comes in the class loader of the integration), so the
manager is found by class name and called by reflection. The status of the CLI
connector carries the console, for {{camel get chaos}}.
* camel-jbang: {{camel cmd chaos-add|chaos-change|chaos-remove|chaos-clear}}
(flat verb-noun commands like {{stop-route}}; add, change and remove need the
name or pid of exactly one integration, as {{camel cmd sql}}, since rule ids
are per integration; clear acts without one on all integrations that have chaos
switched on), {{camel get chaos [--report] [--json]}}, and {{camel run
--chaos}} (adds {{camel:chaos}}, as {{--observe}} adds observability-services;
also with {{--runtime=main}} and for a Maven project; refused with Spring Boot
and Quarkus for now, as the run would have to add camel-chaos to the exported
project and give it Camel profile {{dev}}), with help text and the generated
command docs.
* Docs: the chaos page gets "Control while it runs"; the security model lists
the chaos rules as a development opt-in and says that {{exception=}} can name
any public {{Throwable}} class on the classpath; {{design/chaos.adoc}} catches
up with what #28716 and #28754 built (poll strategy wrapped once, counting in
the route policy, netty-http {{status=}} in CAMEL-26432), as asked in the
review of #28754.
The MCP tool group ({{camel_runtime_chaos_*}}, with {{destructiveHint=true}} on
add and change and both in {{ToolConfirms}}, as agreed in the review of #28716)
is the next step (design "Order of work", the MCP tool group), in its own pull
request. Until then {{camel ask}} reaches the commands only through its
{{camel}} command tool, which asks the user before {{camel cmd chaos-*}} (a
{{camel cmd}} changes something).
_Filed with Claude Code on behalf of allthingssecurity._
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
