LitmusChaos was accepted as a CNCF sandbox project last week. Maintainers, community and the team are thrilled to join CNCF's larger ecosystem. What does this really mean to the Litmus project and the community or the users? Cloud-native chaos engineering gets a boost for broader community involvement. I have covered the journey of LitmusChaos and the future roadmap in the announcement blog here.

The project

Well, the project is now under vendor-neutral governance. This is the point of joining CNCF as a project. This allows large companies and end-users to invest their resources to the development of the project and build a larger community of the users. So, the project grows, perhaps faster. Of course, MayaData will continue to sponsor this project but the maintainers actively seek more contributions from the community.

The Community

LitmusChaos has two primary components. First is the actual engine that orchestrates the declarative chaos and the second is ChaosHub. The project now seeks contributions to both areas, however, the experiments to the chaos hub are crucial to the growth of adoption of the project. Adoption and contribution of new chaos experiments are cyclic in nature and help each other.

Kubernetes SREs can help

LitmusChaos primary persona is SREs. Cloud-native SREs are moving towards the “chaos first” principle in their DevOps strategy where plans for chaos engineering are devised before the deployment and operations. With this shift, it is only a question of “when” and not “if” to adopt chaos engineering for them. LitmusChaos helps SREs to do a litmus test on the resilience of Kubernetes implementation and the applications running on Kubernetes. We assume both Kubernetes and the microservices/applications on Kubernetes undergo rigorous testing practices before ending up in the hands of SREs. However, each implementation is different in the resource configurations, scale, load, and the combinations of various applications running on Kubernetes. This necessitates to do a litmus test on the resilience of the platform and applications periodically. In other words, adopt chaos first principle.

Litmus project helps SREs to jump-start their chaos journey by giving the required operator and experiments. There are numerous Kubernetes resource-specific experiments already along with a few application-specific ones. It is possible for you to introduce your first chaos experiments in minutes. I.e., it takes a few minutes from installing Litmus to injecting a fault.

SREs can use Litmus, its experiments and develop new experiments seamlessly. There is an SDK available in Ansible, Python, and GO. If the newly developed experiment is generic and useful to the community, they can contribute it back to ChaosHub.

What can you contribute other than chaos experiments?

The project is under active development. The roadmap is updated here https://github.com/litmuschaos/litmus/blob/master/ROADMAP.md#in-progress-near-term.

Some of the experiments are being extended for Python and GO SDK. You can put your Python or GO skills into active mode and fulfill your open source karma.

I am also excited to say that litmus portal is being developed which can receive contributions from frontend developers. Are you interested in contributing to the portal with your ReactJS, GraphQL, Database, GoLang, Cypress skills? You are welcome - join slack to talk to the team or directly pick up an issue at GitHub.

Conclusion

We are thrilled to have joined as a CNCF sandbox project and looking forward to taking the Litmus project for greater development and adoption.

Join litmus community slack to ask any questions on how to get started.

Follow us on GitHub.