[
https://issues.apache.org/jira/browse/CAMEL-26806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18141977#comment-18141977
]
Claus Ibsen commented on CAMEL-26806:
-------------------------------------
Notes for when this is picked up, after the 4.24 release:
*Pointing the integration at the services* is the hard part of this ticket: a
test-infra service knows its address, but the integration's configuration must
be overridden with it (such as {{camel.component.kafka.brokers}}), which needs
a mapping per service. A design for it comes first.
More that chaos and test-infra could do together, in order of value:
# *Faults on the service itself.* All chaos faults today happen inside Camel (a
send, a poll or a route fails or stalls), which imitates a broker problem. With
test-infra the broker is a real container that chaos could act on: pause it
(docker pause: the connections hang) or stop and start it ({{camel infra
restart}} exists), so the consumer must reconnect. That tests what an
in-process fault cannot: the reconnect logic, the recovery tasks (the run of
CAMEL-26804 against the infra Kafka showed its KafkaReconnect thread), and
where a Kafka consumer resumes after a broker restart. A rule could be
{{service=kafka stall duration=10s}}, driven by the CLI, which owns the infra
process; the expectations stay as they are, as they count what the routes did.
A slow network would need Toxiproxy, which test-infra does not have yet.
# *Verifying the consumer facts of the Good to know hints* (CAMEL-26716, design
PR #29554): per messaging component, start its service, run a one-line route,
fail one message, and read in the chaos report whether the consumer read it
again (kept by the consumer). As a test suite it confirms facts such as
breakOnFirstError or transacted for real, and fails when a component upgrade
changes the behaviour.
# *Scenarios that declare their infra:* a {{.chaos}} file with {{infra=kafka}},
so {{camel run --chaos=test/chaos/x.chaos}} or the Citrus test starts the
broker first, and the CI gate of the chaos example
(apache/camel-jbang-examples#134) runs against a real broker instead of a stub.
# *A clean broker between experiments:* recreate the topic or queue, so the
messages left by one experiment do not count in the next.
_Claude Code on behalf of Claus Ibsen_
> camel-jbang - chaos-explore --infra: start the test-infra services the routes
> need for the exploration, and stop them after
> ---------------------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-26806
> URL: https://issues.apache.org/jira/browse/CAMEL-26806
> Project: Camel
> Issue Type: New Feature
> Components: camel-jbang
> Reporter: Claus Ibsen
> Priority: Major
> Fix For: 4.25.0
>
>
> Building on CAMEL-26760 and the warning-free feed of a broker run by camel
> infra: {{camel cmd chaos-explore --infra}} would start, with {{camel infra
> run}}, the services the routes of the integration need (Kafka, an MQTT or
> AMQP broker, a database), point the integration at them, explore, and stop
> them after. Then an exploration tests what a stub cannot: a consumer that
> commits a failed record or reads it again, redelivery and the dead letter
> queue of the broker.
> _Claude Code on behalf of Claus Ibsen_
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
