Litmus provides multiple ansible utils (task files) to perform Kubernetes, Storage (OpenEBS provider) & Chaos operations. The LitmusLib lends modularity to the litmusbook & achieves code reuse in the project.
Once the experiment flow is identified, it is recommended to explore the existing list of utils to map to the test steps/blocks. In the event where an existing util (or a set of utils) cannot satisfy the experiment’s requirements, new utils can be created in conformance with the following characteristics:
Each util is invoked with explicit arguments from the playbook (or a parent taskfile), passed as “include_vars”. For example, deployment details such as manifest paths, namespaces, service endpoints & labels (refer the individual utils readme for exact info). Typically, these don’t “return” any data to the main playbook (the scope of ansible register variables is valid/global across the lifetime of a playbook).
Each util adheres to a definite purpose/function. Typically, utils consist of the logic to either manipulate cluster resources (create, scale, patch, upgrade, fail, remove etc., therefore changing cluster state), run status checks on specific cluster components (namespaces, pods, nodes) or execute some stateful application-specific tasks (data writes, reads, integrity-checks).
Some of the utils (esp. in chaoslib) use other supporting tools to perform its function. These are deployed, used & cleaned up as part of the util’s run.
Based on the function it performs, a util is categorized as belonging to a particular library (chaoslib, funclib or common) & placed accordingly in the Litmus repository directory structure.