Chaos Mesh

Term 2 · Jun-Aug · 2 projects

• Refactor PodChaos and NetworkChaos E2E Tests into Gherkin-based BDD Scenarios

  LFX Mentorship · Listed in the official cohort

  @g1eny0ungSource IssueLFX portal

  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.

  • Go
  • Kubernetes
  • Kubernetes E2E testing
  • Ginkgo/Gomega
  • Gherkin
  • Godog
  • +2

• Runtime Fact Checker for Chaos Mesh Experiments

  LFX Mentorship · Listed in the official cohort

  @g1eny0ungSource IssueLFX portal

  Chaos Mesh can report the lifecycle and status of a chaos experiment, but users often still need to manually verify whether the real runtime behavior matches the intended chaos behavior. For example, a user may want to know whether a PodChaos experiment actually affected the selected pods, whether a DNSChaos experiment actually changed DNS responses, or whether a NetworkChaos experiment actually changed connectivity or latency between workloads. This project will build a runtime fact checker for Chaos Mesh experiments. The first version should be a standalone CLI prototype where users specify one Chaos Mesh custom resource to check. The tool will collect runtime evidence from Kubernetes resources, Chaos Mesh status, events, and active probes when needed, then compare the observed behavior with the expected behavior implied by the Chaos CR. Core matching logic should be implemented by deterministic collectors, probes, and rules. LLM support, if added, should only summarize or explain collected facts; it should not be the source of truth for the verdict.

  • Go
  • Kubernetes
  • Kubernetes client-go/controller-runtime
  • Chaos Mesh custom resources
  • networking basics
  • DNS basics
  • +2

Term 1 · Mar-May · 1 project

• Observability for StressChaos

  LFX Mentorship · Listed in the official cohort

  @STRRLSource IssueLFX portal

  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.

  • Go
  • Kubernetes
  • Linux
  • Observability Tools(e.g. Prometheus
  • Grafana
  • etc.)

Term 0 · 2022 Spring (Mar-May) · 1 project

• Interactive Katacoda Playground for Chaos Experiment Examples

  LFX Mentorship · Listed in the official cohort

  @STRRLSource IssueLFX portal

  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 < 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.

  • Go
  • Kubernetes
  • Shell scripts

Term 0 · 2021 Fall (Sep-Nov) · 1 project

• Monitoring Metrics about Chaos Mesh

  LFX Mentorship · Listed in the official cohort

  @strrlSource IssueLFX portal

  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.

  • Go
  • prometheus
  • grafana

Term 0 · 2021 Spring (Mar-May) · 2 projects

• Chaos Engineering as a Service

  LFX Mentorship · Listed in the official cohort

  @WangXiangUSTCSource IssueLFX portal

  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.

  • Go

• Enriching AWS chaos

  LFX Mentorship · Listed in the official cohort

  @STRRLSource IssueLFX portal

  We have already made a technical previewing implementation for AWS Chaos, it could inject some simple chaos now, such as stop/restart the EC2. And we want to make it more stable and structured. And there is another direction of AWS chaos: AWS service failure. It might be useful for testing infrastructure automation tools. Basically there are two things that we want to do: - enriching e2e test cases using localstack - more chaos by simulating AWS service failure by hijacking awscli request to a modified localstack

  • Go
  • Python(Optional)

Term 0 · 2020 Q3–Q4 · 2 projects

• Create a debug information collector for Chaos Mesh

  CommunityBridge · Listed in the official cohort

  @YangKeaoSource IssueCommunityBridge

  Create a diagnotic info collector for Chaos Mesh to collect debugging info of a specific chaos experiment, covering chaos-daemon log, tc rules, iptables rules, etc.

  • Chaos Mesh
  • Kubernetes
  • Go

• Support chaos-daemon work independently on a non-k8s node.

  CommunityBridge · Listed in the official cohort

  @YangKeaoSource IssueCommunityBridge

  At present, chaos-daemon can only be run as a daemonset service in the Kubernetes environment, but some users want to inject faults into Kubernetes cluster itself, and they cannot use Chaos Mesh to do this. There are also some users who are unable to use Chaos Mesh because their applications are not deployed in the Kubernetes environment. So we need to make the chaos-daemon component run on non-k8s nodes alone, and inject faults directly into this node to solve the problems mentioned above.

  • Chaos Mesh
  • Kubernetes
  • Go