Merge pull request #1319 from ksatchit/v1.2.x

[Cherry pick for 1.2.0]

ADOPTERS.md

@@ -2,5 +2,12 @@ This is the list of organizations and users that publicly shared details of how
 Please send PRs to add or remove organizations/users.
 
 | Organization | Applications/Workloads | Success Story |
-| :---         | :---               | :---
+| :---         | :---               | :---|
 |[Zebrium](https://www.zebrium.com?utm_source=github&utm_campaign=litmuschaos_repo)|[Zebrium K8s Demo](https://github.com/zebrium/zebrium-kubernetes-demo)|Coming soon!|
+|[MayaData](https://mayadata.io)|[Director Online](https://director.mayadata.io/)|Coming soon!|
+|[OpenEBS](https://openebs.io/)|[openebs-ci](https://openebs.ci/)|Coming soon!|
+|[Wipro](https://www.wipro.com/en-IN/infrastructure/wipros-appanywhere/?utm_source=github&utm_campaign=litmuschaos_repo)|[Wipro AppAnywhere](https://www.wipro.com/en-IN/infrastructure/wipros-appanywhere/?utm_source=github&utm_campaign=litmuschaos_repo)|Coming soon!|
+
+| User | Applications/Workloads | Success Story |
+| :--- | :--- | :--- |
+| [Laura Henning](https://github.com/LaumiH) | reasearch on how to do chaos engineering in minikube demo clusters like [these](https://github.com/LaumiH/k8sstuff) | [my story](https://github.com/litmuschaos/litmus/tree/master/adopters/Laura_Henning_Research_Project.md) |

CODE_OF_CONDUCT.md

@@ -34,7 +34,7 @@ This Code of Conduct applies both within project spaces and in public spaces whe
 
 ## Enforcement
 
-Instances of abusive, harassing or otherwise unacceptable behavior may be reported by contacting the project team at community@openebs.io. The project team will review and investigate all complaints, and will respond in a way that it deems appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately.
+Instances of abusive, harassing or otherwise unacceptable behavior may be reported by contacting the project team at support@mayadata.io. The project team will review and investigate all complaints, and will respond in a way that it deems appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately.
 
 Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership.
 

GOVERNANCE.md

@@ -0,0 +1,146 @@
+# LitmusChaos Project Governance
+
+We abide by the [Code of Conduct](./CODE_OF_CONDUCT.md) for all the projects maintained under the LitmusChaos Organization.
+
+For specific guidance on practical contribution steps for any LitmusChaos sub-project please
+see our [CONTRIBUTING.md](./CONTRIBUTING.md) guide and the sub-project specific contributing guides 
+in the respective GitHub repositories.
+
+## Maintainership
+
+There are different types of maintainers, with different responsibilities, but
+all maintainers have 3 things in common:
+
+1) They share responsibility in the project's success.
+2) They have made a long-term, recurring time investment to improve the project.
+3) They spend that time doing whatever needs to be done, not necessarily what
+is the most interesting or fun.
+
+Maintainers are often under-appreciated, because their work is harder to appreciate.
+It's easy to appreciate a really cool and technically advanced feature. It's harder
+to appreciate the absence of bugs, the slow but steady improvement in stability,
+or the reliability of a release process. But those things distinguish a great
+project from a good one.
+
+## Reviewers
+
+A reviewer is a core role within the project.
+They share in reviewing issues and pull requests and their LGTM counts towards the
+required LGTM count to merge a code change into the project.
+
+Reviewers are part of the organization but do not have write access.
+Becoming a reviewer is a core aspect in the journey to becoming a maintainer.
+
+## Adding maintainers
+
+Maintainers are first and foremost contributors that have shown they are
+committed to the long term success of a project. Contributors wanting to become
+maintainers are expected to be deeply involved in contributing code, pull
+request review, and triage of issues in the project for more than three months.
+
+Just contributing does not make you a maintainer, it is about building trust
+with the current maintainers of the project and being a person that they can
+depend on and trust to make decisions in the best interest of the project.
+
+Periodically, the existing maintainers curate a list of contributors that have
+shown regular activity on the project over the prior months. From this list,
+maintainer candidates are selected and proposed maintainers slack channel.
+
+After a candidate has been announced on the maintainers slack channel, the
+existing maintainers are given five business days to discuss the candidate,
+raise objections and cast their vote. The Votes take place via the pull request 
+comment. Candidates must be approved by at least 66% of the
+current maintainers by adding their vote on the mailing list. The reviewer role
+has the same process but only requires 33% of current maintainers. Only
+maintainers of the repository that the candidate is proposed for are allowed to
+vote.
+
+If a candidate is approved, a maintainer will contact the candidate to invite
+the candidate to open a pull request that adds the contributor to the
+MAINTAINERS file. The voting process may take place inside a pull request if a
+maintainer has already discussed the candidacy with the candidate and a
+maintainer is willing to be a sponsor by opening the pull request. The candidate
+becomes a maintainer once the pull request is merged.
+
+## Adding sub-projects
+
+Similar to adding maintainers, new sub projects can be added to LitmusChaos
+GitHub organization as long as they adhere to the LitmusChaos vision and mission. 
+New projects are discussed in either the Contributor Meeting or the Community 
+slack and requires at least 1 maintainer approval.
+
+If a project is approved, a maintainer will add the project to the LitmusChaos
+GitHub organization, and make an announcement on a public forum.
+
+## Stepping down policy
+
+Life priorities, interests, and passions can change. If you're a maintainer but
+feel you must remove yourself from the list, inform other maintainers that you
+intend to step down, and if possible, help find someone to pick up your work.
+At the very least, ensure your work can be continued where you left off.
+
+After you've informed other maintainers, create a pull request to remove
+yourself from the MAINTAINERS file.
+
+## Removal of inactive maintainers
+
+Similar to the procedure for adding new maintainers, existing maintainers can
+be removed from the list if they do not show significant activity on the
+project. Periodically, the maintainers review the list of maintainers and their
+activity over the last three months.
+
+If a maintainer has shown insufficient activity over this period, a neutral
+person will contact the maintainer to ask if they want to continue being
+a maintainer. If the maintainer decides to step down as a maintainer, they
+open a pull request to be removed from the MAINTAINERS file.
+
+## How are decisions made?
+
+LitmusChaos is an open-source project with an open design philosophy. This means
+that the repository is the source of truth for EVERY aspect of the project,
+including its philosophy, design, road map, and APIs. *If it's part of the
+project, it's in the repo. If it's in the repo, it's part of the project.*
+
+As a result, all decisions can be expressed as changes to the repository. An
+implementation change is a change to the source code. An API change is a change
+to the API specification. A philosophy change is a change to the philosophy
+manifesto, and so on.
+
+All decisions affecting LitmusChaos, big and small, follow the same 3 steps:
+
+* Step 1: Open a pull request. Anyone can do this.
+
+* Step 2: Discuss the pull request. Anyone can do this.
+
+* Step 3: Merge or refuse the pull request. Who does this depends on the nature
+of the pull request and which areas of the project it affects.
+
+## Helping contributors with the DCO
+
+The [DCO or `Sign your work`](./CONTRIBUTING.md#sign-your-work)
+requirement is not intended as a roadblock or speed bump.
+
+Some LitmusChaos contributors are not as familiar with `git`, or have used a web
+based editor, and thus asking them to `git commit --amend -s` is not the best
+way forward.
+
+In this case, maintainers can update the commits based on clause (c) of the DCO.
+The most trivial way for a contributor to allow the maintainer to do this, is to
+add a DCO signature in a pull request's comment, or a maintainer can simply
+note that the change is sufficiently trivial that it does not substantially
+change the existing contribution - i.e., a spelling change.
+
+When you add someone's DCO, please also add your own to keep a log.
+
+## I'm a maintainer. Should I make pull requests too?
+
+Yes. Nobody should ever push to master directly. All changes should be
+made through a pull request.
+
+## Conflict Resolution
+
+If you have a technical dispute that you feel has reached an impasse with a
+subset of the community, any contributor may open an issue, specifically
+calling for a resolution vote of the current maintainers to resolve the dispute.
+The same voting quorums required (2/3) for adding and removing maintainers
+will apply to conflict resolution.

MAINTAINERS

@@ -0,0 +1,25 @@
+# Official list of LitmusChaos Maintainers.
+#
+# Names added to this file should be in the following format:
+#     Individual's name,@githubhandle, Company Name
+#
+# Each of the LitmusChaos sub project may have one or more of the 
+# following maintainers and list of reviewers who are 
+# in the process of becoming maintainers. 
+#
+# Please keep the below list sorted in ascending order.
+#
+#Maintainers
+
+"Chandan Kumar",@chandankumar4,MayaData
+"Jayesh Kumar",@k8s-dev,Self
+"Karthik Satchitanand",@ksatchit,MayaData
+"Sumit Nagal",@sumitnagal,Intuit
+"Uma Mukkara",@umamukkara,MayaData
+
+#Reviewers
+"Amit Bhatt",@amitbhatt818,MayaData
+"Rahul M Chheda",@rahulchheda,MayaData
+"Raj Das",@rajdas98,MayaData
+"Shubham Chaudhary",@ispeakc0de,MayaData
+"Udit Gaurav",@uditgaurav,MayaData

NOTICE.md

@@ -1,9 +1,11 @@
 The source code developed for the LitmusChaos Project is licensed 
 under Apache 2.0. 
 
-However, the LitmusChaos project contains unmodified/modified 
+However, the LitmusChaos project contains unmodified
 subcomponents from other OpenSource Projects with separate
 copyright notices and license terms. 
 
 Your use of the source code for these subcomponents is subject
 to the terms and conditions as defined by those source projects.
+
+Please refer to the [fossa](./fossa.md) reports for more details

adopters/Laura_Henning_Research_Project.md

@@ -0,0 +1 @@
+I started using LitmusChaos for a student project in November 2019 and have been observing its extraordinary evolution since then. My company does not yet have plans for adopting chaos engineering because the system we develop is in its early stages. So they kind of commissioned me to find a possible solution and implementation and above all gain knowledge. I came across LitmusChaos through the CNCF Landscape in my research for available open source tools. I did a quick assessment of other tools and found LitmusChaos to fulfill my requirements completely. The help I received from the MayaData developers during my early stages of "is it me or is there really a bug?" convinced me to invest more time in the community and even start constructing own chaoslibs. The presentation I recently held to my team (and many people in the video call I didn't know :D) earned me lots of positive feedback and a possible research question for my upcoming bachelor thesis. So let's see what the future has to offer!

chaoslib/chaostoolkit/kubernetes/pod-delete/chaostoolkit_util.yml

@@ -0,0 +1,25 @@
+---
+  ## Execute this util to perform AWS instance chaos using chaostoolkit-aws
+  ## chaos_file: pod-app-kill-count.j2,
+  ## Requiered variables(region, access_key_id, secrete_access_key, chaos_action(stop_instances,stop_instances_any_type), aws_instance_id) 
+  ## need to be passed or defined before populating json.
+- name: Get the chaos util to perfom chaos test
+  template:
+    src: "/choslib/chaostoolkit/kubernetes/{{ chaos_file }}"
+    dest: pod-app-kill-count.json
+
+- name: Fetch the content of json file to start chaos on node
+  command: cat pod-app-kill-count.json
+  register: json_output
+  failed_when: "json_output.rc != 0"
+
+  ## Invoke this by passing attribute display with values as (true or false) to check the content of json
+- debug:
+    msg: "{{json_output.stdout}}"
+  when: "{{display}} == 'true'"
+
+- name: Create the pod which will perform acation on k8
+  shell: kubectl apply -f {{ chaos_file }} -n {{ namespace }}
+  args:
+    executable: /bin/bash
+

chaoslib/chaostoolkit/kubernetes/pod-delete/example_test_vars.yml

@@ -0,0 +1,11 @@
+---
+
+## Following variables requierd to perform action on AWS instance using chaostoolkit, chaostoolkit-aws driver
+LABEL_NAME: "app" # label name
+NAME_SPACE: "default" # name space 
+APP_ENDPOINT: "localhost" ## you define ingress or service endpoint
+chaos_prob: "count_pods" ## chaos probe validation
+chaos_action: "terminate_pods"    ## stop_instance,
+chaos_experiment: "k8-pod-delete"    ## stop_instance,
+PERCENTAGE: "50" ## percentage pod to be terminated
+file: pod-app-kill-count.j2 ## pod-app-kill-count.j2 (To terminate pod on k8)

chaoslib/chaostoolkit/kubernetes/pod-delete/pod-app-kill-count.j2

@@ -0,0 +1,64 @@
+{
+  "version": "1.0.0",
+  "title": "System is resilient to provider's failures",
+  "description": "Can our consumer survive gracefully a provider's failure?",
+  "tags": [
+    "service",
+    "kubernetes",
+    "spring"
+  ],
+  "configuration": {
+    "app_name": {
+      "type": "env",
+      "key": "LABEL_NAME"
+    },
+    "name_space": {
+      "type": "env",
+      "key": "NAME_SPACE"
+    }
+  },
+  "steady-state-hypothesis": {
+    "title": "Killing the pod where application is running",
+    "probes": [
+      {
+        "type": "probe",
+        "name": "there-should-be-at-least-2-running-app-replicas",
+        "tolerance": 3,
+        "provider": {
+          "type": "python",
+          "module": "chaosk8s.pod.probes",
+          "func": "count_pods",
+          "arguments": {
+            "label_selector": "app= {{ app_name }}",
+            "ns": " {{ name_space }}"
+          }
+        }
+      }
+    ]
+  },
+  "method": [
+    {
+      "type": "action",
+      "name": "Terminate_pod",
+      "provider": {
+        "type": "python",
+        "module": "chaosk8s.pod.actions",
+        "func": "terminate_pods",
+        "arguments": {
+          "label_selector": "app={{ app_name }}",
+          "name_pattern": "{{ app_name }}",
+          "ns": "{{ name_space }} ",
+          "rand": true,
+          "mode": "fixed",
+          "qty": 1
+        }
+      },
+      "pauses": {
+        "after": 20
+      }
+    }
+  ],
+  "rollbacks": [
+
+  ]
+}

chaoslib/litmus/container_kill/containerd_chaos/containerd.j2

@@ -1,15 +1,20 @@
 apiVersion: batch/v1
 kind: Job
 metadata:
-  name: containerd-chaos
+  name: containerd-chaos-{{ run_id }}
   labels:
+    name: containerd-chaos
+{% if chaos_uid is defined and chaos_uid != '' %}        
     chaosUID: {{ chaos_uid }}
+{% endif %}        
 spec:
   template:
     metadata:
       labels:
         app: crictl
+{% if chaos_uid is defined and chaos_uid != '' %}        
         chaosUID: {{ chaos_uid }}
+{% endif %}        
     spec:
       nodeSelector:
         kubernetes.io/hostname: {{ app_node }}

chaoslib/litmus/container_kill/containerd_chaos/crictl-chaos.yml

@@ -26,6 +26,15 @@
     - set_fact: 
         app_node: "{{ app_node.stdout }}"
 
+    - block:
+        - name: Generate a run id if not passed from the engine/experiment
+          shell: echo $(mktemp) | cut -d '.' -f 2 | cut -c -6
+          register: rand_string   
+
+        - set_fact:
+            run_id: "{{ rand_string.stdout | lower }}"
+      when: "run_id is not defined or run_id == ''"
+
     - name: Wait for the specified ramp time before injecting chaos
       wait_for: timeout="{{ ramp_time }}"
       when: "ramp_time is defined and ramp_time != ''"
@@ -48,7 +57,7 @@
 
     - name: Confirm that the containerd-chaos job is running on {{ app_node }} node.
       shell: >
-        kubectl get pod -l app=crictl
+        kubectl get pod -l job-name=containerd-chaos-{{ run_id }}
         --no-headers -o custom-columns=:status.phase
         -n {{ namespace }} | sort | uniq
       args:
@@ -172,7 +181,7 @@
 
         - name: Confirm that the containerd-chaos pod is deleted successfully
           shell: >
-            kubectl get pods -l app=crictl --no-headers -n {{ namespace }}
+            kubectl get pods -l job-name=containerd-chaos-{{ run_id }} --no-headers -n {{ namespace }}
           args:
             executable: /bin/bash
           register: result

chaoslib/litmus/cpu_hog/app_cpu_stress.j2

@@ -2,14 +2,19 @@ apiVersion: batch/v1
 kind: Job
 metadata:
   name: app-cpu-stress-{{ run_id }}
-  labels: 
+  labels:
+    app: app-cpu-stress  
+{% if chaos_uid is defined and chaos_uid != '' %}        
     chaosUID: {{ chaos_uid }}
+{% endif %}   
 spec:
   template:
     metadata:
       labels:
         app: app-cpu-stress
+{% if chaos_uid is defined and chaos_uid != '' %}        
         chaosUID: {{ chaos_uid }}
+{% endif %}        
     spec:
       nodeSelector:
         ## mandatory: provide name of host where target container resides