Fetching the latest programs, projects, and workspace data.

Description: Chaos Mesh is not like Chaos Engineering as a Service now: - Poor observability: the result of chaos experiments are not easy to observe and judge, the users need to check whether the Chaos effects by manual. - Chaosd(for physic node) is too simple: only supports command line operation, does not support task scheduling and life cycle management. - The costs of learning operation and maintenance are high: the maintenance of Chaos Mesh and Chaosd are not unified. - It should be a unified place to manage Chaos experiments for multiple platforms and multiple clusters, and can see the monitoring data of the experiment.
Showing 5 of 7 projects. Click any project card for scope, mentors, and proposal studio.
A Chaos Engineering Platform for Kubernetes.
Chaos Mesh is a powerful chaos engineering platform for Kubernetes. There is a Katacoda playground as interactive tutorial, and we want to build more Katacoda scenarios as the minimum examples for each certain type of chaos experiment. The basic work would be to create new katacoda scenarios as referred to by https://github.com/chaos-mesh/chaos-mesh/tree/master/examples, and build small applications (with well-built observability) as the target of chaos experiment if required. This project will not require you to dive deep into the hard-core parts of Chaos Mesh, instead, it would be a tour of learning and exploring Chaos Mesh.
<p>Chaos Mesh has an existing Go-based E2E test suite for validating chaos behavior on Kubernetes. The current tests are effective, but many scenarios mix test intent, fixture setup, Chaos Mesh custom resource creation, probing logic, assertions, and cleanup in Go code. This makes the E2E suite harder to read and extend, especially for new contributors who need to understand both the user-facing chaos behavior and the underlying Kubernetes test implementation at the same time. This project will introduce a Gherkin + Godog based BDD layer for selected Chaos Mesh E2E tests. The mentee will migrate the existing PodChaos and NetworkChaos E2E tests into executable Gherkin feature files backed by reusable Go step definitions. The new feature files should preserve Chaos Mesh-specific behavior and network/pod verification details, rather than hiding them behind overly broad user-story wording.</p><p><br></p><p><br></p><p>Expected Outcome:</p><p><br></p><p>- A Godog-based BDD test layer that can run Chaos Mesh E2E scenarios from Gherkin feature files</p><p>- Gherkin feature files for all existing PodChaos E2E scenarios</p><p>- Gherkin feature files for all existing NetworkChaos E2E scenarios</p><p>- Reusable Go step definitions for common E2E operations such as preparing workloads, applying Chaos Mesh custom resources, probing pod/network behavior, checking expected failure or delay, and verifying recovery</p><p>- Integration with the existing E2E development workflow, with exact command and CI integration decided during implementation</p><p>- Documentation explaining the Gherkin scenario style, step definition conventions, and migration guidance for other Chaos Mesh E2E tests</p>
StressChaos is a chaos experiment that injects stress to the system. The current implementation of StressChaos is lack of observability, most of observability solutions could not observe the stress at Pod level, but only at Node level. This project is to enhance observability for StressChaos. Expected Outcome: Chaos Mesh end users could observe the injected stress at Pod level. Upstream Issues: https://github.com/chaos-mesh/chaos-mesh/discussions/3012, https://github.com/chaos-mesh/chaos-mesh/issues/3651
Observability is very important for each application, we want to monitor more things of Chaos Mesh components, enrich the metrics for both logic patterns and performance data. We want to let users could watch the status of Chaos Mesh on grafana dashboard, and developers could using time-series metrics for debugging and profiling.