Skip to main content
Version: 3.8.0

Configuring GitOps


With the latest release of LitmusChaos 3.0.0:

  • The term Chaos Experiment has been changed to Chaos Fault.
  • The term Chaos Scenario/Workflow has been changed to Chaos Experiment.
  • Introduction

    GitOps enables you to configure a single source of truth for your chaos experiment and faults, any changes made either to the artifacts stored in the configured git repository or the portal will be synced.

    Before you begin

    Steps to configure GitOps

    • Setup a git repository, so that the ChaosCenter can sync with it, and push all the chaos experiments in that repository.
    • The git repo can be public or private but for authorization, you have to provide an access token or any other mode of authentication.
    • Login into ChaosCenter, go to GitOps (Project Setup > GitOps on the left nav).

    • Select the Git Repository radio button.
    • Copy the git URL of your git repository and paste it in the Repository URL text box.
    • Enter the branch where you want to sync your chaos experiments.

    • You can allow access of your repository either through an access token or through an SSH key.
    • In the case of the SSH key, click the button Generate New SSH Key and just copy the key and paste it in the Deploy Keys Tab inside Settings in your git - repository. Click on the allow write access checkbox, and then on the Add key button.
    • Go back to the portal and click on the Save button. A snackbar will pop up showing, Successfully updated GitOps! message.
    • Some metadata will be pushed to your repository, that is the projectID of your project.
    • Now whenever you schedule a chaos experiment, it will automatically be pushed to your repository. And that repository will be the single source of truth.

    It is also possible to account for the chaos experiments that are created and pushed to the git repository directly, after configuring GitOps. In this case, if the chaos experiment is a single run chaos experiment, then it starts executing as soon as it is pushed to the repository. Alternatively, if the chaos experiment is a scheduled chaos experiment, then it executes as per the defined schedule. On the other hand, updating an existing chaos experiment present in the git repository will not execute the chaos experiment but only sync the chaos experiment resource definition with the ChaosCenter, if applicable.

    Steps to configure Event-Triggered Chaos Injection

    • Once the chaos experiment is pushed to your repository, you’ll notice every chaos experiment has a experiment_id. You can get this from the chaos experiment YAML file. You need to copy the id and annotate the target application so that if there’s any change in the application, gitops will sync the chaos experiment using this experiment_id and run it on your target application. You can use the following command:
    kubectl annotate deploy/target-application${experiment_id}
    kubectl annotate deploy/target-application
    • You can check if the event-tracker is running using this command:
    kubectl get pods -n litmus -w
    • To check the logs copy the pod name of the event-tracker and add it to the following command:
    kubectl logs -f event-tracker-pod-name -n litmus

    In the logs, you’ll notice that the event-tracker has started. If you make changes in the application the event tracker will trigger the chaos injection. If the policy conditions are met then the event tracker will inform the server to schedule a chaos experiment in that same target. For eg: if you have an Nginx app as your target application, you can just edit the deployment and change its image tag, this will trigger the chaos injection.

    Below is a sample policy where two conditions are present and will be validated by the respective operator. The chaos experiment will be triggered if both conditions are met due to the AND condition type.

    kind: EventTrackerPolicy
    name: eventtrackerpolicy-sample
    namespace: litmus
    # Add fields here
    condition_type: "and"
    - key: "spec.replicas"
    value: "1"
    operator: EqualTo
    - key: "spec.template.spec.containers[0].image"
    value: "nginx:1.18"
    operator: EqualTo

    Currently supported policy operators are:

    • EqualTo
    • NotEqualTo
    • LessThan
    • GreaterThan
    • GreaterThanEqualTo
    • LessThanEqualTo

    Learn More