Merge pull request #930 from ksatchit/clone-0.8.0-RC1

Cherry Pick from master into v0.8.x branch

build/ansible-runner/Dockerfile

@@ -8,8 +8,9 @@ RUN apt-get clean && \
     apt-get install -y --no-install-recommends python-minimal python-pip netcat iproute2 jq sshpass \
     curl openssh-client python-setuptools && rm -rf /var/lib/apt/lists/* 
 
+RUN pip install --upgrade pip
 #Installing ansible and dependencies for k8s module
-RUN pip install ansible==2.7.3 openshift jmespath
+RUN pip install ansible==2.7.3 openshift jmespath boto boto3
 
 RUN touch /mnt/parameters.yml /mnt/cloud_config.yml
 
@@ -21,8 +22,7 @@ RUN gcloud --version
 #Installing Kubectl
 ENV KUBE_LATEST_VERSION="v1.12.0"
 RUN curl -L https://storage.googleapis.com/kubernetes-release/release/${KUBE_LATEST_VERSION}/bin/linux/amd64/kubectl -o /usr/local/bin/kubectl && \
-    chmod +x /usr/local/bin/kubectl && \
-    curl -o /usr/local/bin/aws-iam-authenticator https://amazon-eks.s3-us-west-2.amazonaws.com/1.10.3/2018-07-26/bin/linux/amd64/aws-iam-authenticator && \chmod +x /usr/local/bin/aws-iam-authenticator
+    chmod +x /usr/local/bin/kubectl
 
 #Adding hosts entries and making ansible folders
 RUN mkdir /etc/ansible/ /ansible && \

ceps/0001-cep-template.md

@@ -0,0 +1,173 @@
+---
+cep-number: 0
+title: My CEP
+authors:
+-   "@ksatchit"
+owners:
+
+-   TBD
+
+-   "@ksatchit"
+editor: TBD
+creation-date: yyyy-mm-dd
+last-updated: yyyy-mm-dd
+status: provisional/implementable/implemented/deferred/rejected/withdrawn/replaced
+see-also:
+
+-   CEP-1
+
+-   CEP-2
+
+replaces:
+
+-   CEP-3
+
+superseded-by:
+
+-   CEP-100
+---
+
+# Title
+
+This is the title of the Chaos Enhancement Proposal (CEP).
+Keep it simple and descriptive.
+A good title can help communicate what the CEP is and should be considered as part of any review.
+
+The title should be lowercased and spaces/punctuation should be replaced with `-`.
+
+To get started with this template:
+1. **Make a copy of this template.**
+  Name it `YYYYMMDD-my-title.md`.
+1. **Fill out the "overview" sections.**
+  This includes the Summary and Motivation sections.
+1. **Create a PR.**
+  Name it `[CEP NUMBER] Title`, e.g. `[CEP 20191014] Initial work on Chaos Operator`.
+  Assign it to owner(s) that are working on these features.
+1. **Merge early.**
+  Avoid getting hung up on specific details and instead aim to get the goal of the CEP merged quickly.
+  The best way to do this is to just start with the "Overview" sections and fill out details incrementally in follow on PRs.
+  View anything marked as a `provisional` as a working document and subject to change.
+  Aim for single topic PRs to keep discussions focused.
+  If you disagree with what is already in a document, open a new PR with suggested changes.
+
+The canonical place for the latest set of instructions (and the likely source of this file) is [here](/ceps/0001-cep-template.md).
+
+The `Metadata` section above is intended to support the creation of tooling around the CEP process.
+
+## Table of Contents
+
+A table of contents is helpful for quickly jumping to sections of a CEP and for highlighting any additional information provided beyond the standard CEP template.
+[Tools for generating](https://github.com/ekalinin/github-markdown-toc) a table of contents from markdown are available.
+
+-   [Table of Contents](#table-of-contents)
+
+-   [Summary](#summary)
+
+-   [Motivation](#motivation)
+
+    -   [Goals](#goals)
+    -   [Non-Goals](#non-goals)
+
+-   [Proposal](#proposal)
+
+    -   [User Stories](#user-stories-optional)
+    -   [Story 1](#story-1)
+    -   [Story 2](#story-2)
+    -   [Implementation Details/Notes/Constraints](#implementation-detailsnotesconstraints)
+    -   [Risks and Mitigations](#risks-and-mitigations)
+
+-   [Graduation Criteria](#graduation-criteria)
+
+-   [Implementation History](#implementation-history)
+
+-   [Drawbacks](#drawbacks)
+
+-   [Alternatives](#alternatives)
+
+-   [Infrastructure Needed [optional]](#infrastructure-needed)
+
+## Summary
+
+The `Summary` section is incredibly important for producing high quality user focused documentation such as release notes 
+or a development road map.It should be possible to collect this information before implementation begins in order to avoid 
+requiring implementors to split their attention between writing release notes and implementing the feature itself.
+CEP editors should help to ensure that the tone and content of the `Summary` section is useful for a wide audience.
+
+A good summary is probably at least a paragraph in length.
+
+## Motivation
+
+This section is for explicitly listing the motivation, goals and non-goals of this CEP.
+Describe why the change is important and the benefits to users.
+The motivation section can optionally provide links to [experience reports](https://github.com/golang/go/wiki/ExperienceReports) to demonstrate the interest in a CEP 
+within the wider Litmus community.
+
+### Goals
+
+List the specific goals of the CEP.
+How will we know that this has succeeded?
+
+### Non-Goals
+
+What is out of scope for his CEP?
+Listing non-goals helps to focus discussion and make progress.
+
+## Proposal
+
+This is where we get down to the nitty gritty of what the proposal actually is.
+
+### User Stories (optional)
+
+Detail the things that people will be able to do if this CEP is implemented.
+Include as much detail as possible so that people can understand the "how" of the system.
+The goal here is to make this feel real for users without getting bogged down.
+
+#### Story 1
+
+#### Story 2
+
+### Implementation Details/Notes/Constraints (optional) 
+
+What are the caveats to the implementation?
+What are some important details that didn't come across above.
+Go in to as much detail as necessary here.
+This might be a good place to talk about core concepts and how they releate.
+
+### Risks and Mitigations
+
+What are the risks of this proposal and how do we mitigate.
+Think broadly.
+For example, consider both security and how this will impact the larger kubernetes ecosystem.
+
+## Graduation Criteria
+
+How will we know that this has succeeded?
+Gathering user feedback is crucial for building high quality experiences and owners have the important responsibility 
+of setting milestones for stability and completeness.
+
+## Implementation History
+
+Major milestones in the life cycle of a CEP should be tracked in `Implementation History.
+Major milestones might include the following.
+
+-   the `Summary` and `Motivation` sections being merged signaling owner acceptance
+-   the `Proposal` section being merged signaling agreement on a proposed design
+-   the date implementation started
+-   the first Litmus release where an initial version of the CEP was available
+-   the version of Litmus where the CEP graduated to general availability
+-   when the CEP was retired or superseded
+
+## Drawbacks (optional)
+
+Why should this CEP _not_ be implemented.
+
+## Alternatives (optional)
+
+Similar to the `Drawbacks` section the `Alternatives` section is used to highlight and record other possible approaches 
+to delivering the value proposed by a CEP.
+
+## Infrastructure Needed (optional)
+
+Use this section if you need things from the project/owner.
+Examples include a new subproject, repos requested, github details.
+Listing these here allows a owner to get the process for these resources started right away.

ceps/README.md

@@ -0,0 +1,50 @@
+# Chaos Enhancement Proposals (CEPs)
+
+A Chaos Enhancement Proposal (CEP) is a way to propose, communicate and coordinate on new efforts for the LitmusChaos project.
+You can read the full details of the project in [CEP-1](0001-chaos-enhancement-proposal-process.md).
+
+This process is still in _alpha_ state and is mandatory for all major feature beginning release 0.9.
+
+## Quick start for the CEP process
+
+-   Socialize an idea with the Litmus contributors.Make sure that others think the work is worth taking up and will help review the CEP and any code changes required.
+-   Follow the process outlined in the [CEP template](YYYYMMDD-cep-template.md)
+
+## FAQs
+
+### Do I have to use the CEP process
+
+No... but we hope that you will.
+Over time having a rich set of CEPs in one place will make it easier for people to track what is going in the community 
+and find a structured historic record.
+
+CEPs are required when the changes are wide-ranging & are feature-level items. 
+These changes are usually coordinated through Litmus maintainers.
+
+### Why would I want to use the CEP process
+
+Our aim with CEPs is to clearly communicate new efforts to the Litmus Chaos contributor community.
+As such, we want to build a well curated set of clear proposals in a common format with useful metadata.
+
+We are inspired by KEPs, i.e., [Kubernetes Enhancement Proposals](https://github.com/kubernetes/enhancements/tree/master/keps)
+
+### Do I put my CEP in the root CEP directory or a SIG subdirectory
+
+If the CEP is mainly restricted to one SIG's purview then it should be in a CEP directory for that SIG.
+If the CEP is widely impacting much of Litmus, it should be put at the root of this directory.
+
+### What will it take for CEPs to "graduate" out of "beta"
+
+Things we'd like to see happen to consider CEPs well on their way.
+
+-   A set of CEPs that show healthy process around describing an effort and recording decisions in a reasonable amount of time.
+-   CEPs exposed on a searchable and indexable web site.
+-   Presubmit checks for CEPs around metadata format and markdown validity.
+
+Even so, the process can evolve. As we find new techniques we can improve our processes.
+
+### My FAQ isn't answered here
+
+The CEP process is still evolving!
+If something is missing or not answered here feel free to reach out to [LitmusChaos Community](https://kubernetes.slack.com/messages/CNXNB0ZTN).
+If you want to propose a change to the CEP process you can open a PR on [CEP-1](0001-cep-template.md) with your proposal.

chaoslib/litmus/container_kill/containerd_chaos/containerd.j2

@@ -0,0 +1,28 @@
+apiVersion: extensions/apps/v1
+kind: DaemonSet
+metadata:
+  name: containerd-chaos
+spec:
+  template:
+    metadata:
+      labels:
+        app: crictl
+      name: containerd-chaos
+    spec:
+      containers:
+      - image: {{ containerd_image }}
+        imagePullPolicy: Always
+        name: containerd-chaos
+        command: ['sh', '-c', 'echo Hello! && sleep 1800']
+        volumeMounts:
+          - name: cri-socket
+            mountPath: /run/containerd/containerd.sock
+          - name: cri-config
+            mountPath: /etc/crictl.yaml
+      volumes:
+        - hostPath:
+            path: /run/containerd/containerd.sock
+          name: cri-socket
+        - hostPath:
+            path: /etc/crictl.yaml 
+          name: cri-config