fix(codacy): Fixing the codacy issue (#228)
* fix(codacy): Fixing the codacy issue Signed-off-by: shubhamchaudhary <shubham.chaudhary@mayadata.io> * fix(codacy): Fixing the codacy issue Signed-off-by: shubhamchaudhary <shubham.chaudhary@mayadata.io>
This commit is contained in:
Shubham Chaudhary
GitHub
parent
b44e4ba6a3
commit
b60d67df96
|
|
@ -18,13 +18,10 @@ might close your issue. If we're wrong, PLEASE feel free to reopen it and
|
|||
explain why.
|
||||
-->
|
||||
|
||||
|
||||
|
||||
**What happened**:
|
||||
|
||||
**What you expected to happen**:
|
||||
|
||||
**How to reproduce it (as minimally and precisely as possible)**:
|
||||
|
||||
|
||||
**Anything else we need to know?**:
|
||||
|
|
@ -7,12 +7,12 @@
|
|||
**Special notes for your reviewer**:
|
||||
|
||||
**Checklist:**
|
||||
- [ ] Fixes #<issue number>
|
||||
- [ ] Labelled this PR & related issue with `documentation` tag
|
||||
- [ ] PR messages has document related information
|
||||
- [ ] Labelled this PR & related issue with `breaking-changes` tag
|
||||
- [ ] PR messages has breaking changes related information
|
||||
- [ ] Labelled this PR & related issue with `requires-upgrade` tag
|
||||
- [ ] PR messages has upgrade related information
|
||||
- [ ] Commit has unit tests
|
||||
- [ ] Commit has integration tests
|
||||
- [ ] Fixes #<issue number>
|
||||
- [ ] Labelled this PR & related issue with `documentation` tag
|
||||
- [ ] PR messages has document related information
|
||||
- [ ] Labelled this PR & related issue with `breaking-changes` tag
|
||||
- [ ] PR messages has breaking changes related information
|
||||
- [ ] Labelled this PR & related issue with `requires-upgrade` tag
|
||||
- [ ] PR messages has upgrade related information
|
||||
- [ ] Commit has unit tests
|
||||
- [ ] Commit has integration tests
|
||||
|
|
@ -4,42 +4,42 @@ Litmus is an Apache 2.0 Licensed project and uses the standard GitHub pull reque
|
|||
|
||||
There are several areas of Litmus that could use your help. For starters, you could help in improving the sections in this document by either creating a new issue describing the improvement or submitting a pull request to this repository.
|
||||
|
||||
* If you are a first-time contributor, please see [Steps to Contribute](#steps-to-contribute).
|
||||
* If you would like to suggest new tests to be added to litmus, please go ahead and [create a new issue](https://github.com/litmuschaos/litmus/issues/new) describing your test. All you need to do is specify the workload type and the operations that you would like to perform on the workload.
|
||||
* If you would like to work on something more involved, please connect with the Litmus Contributors.
|
||||
* If you would like to make code contributions, all your commits should be signed with Developer Certificate of Origin. See [Sign your work](#sign-your-work).
|
||||
- If you are a first-time contributor, please see [Steps to Contribute](#steps-to-contribute).
|
||||
- If you would like to suggest new tests to be added to litmus, please go ahead and [create a new issue](https://github.com/litmuschaos/litmus/issues/new) describing your test. All you need to do is specify the workload type and the operations that you would like to perform on the workload.
|
||||
- If you would like to work on something more involved, please connect with the Litmus Contributors.
|
||||
- If you would like to make code contributions, all your commits should be signed with Developer Certificate of Origin. See [Sign your work](#sign-your-work).
|
||||
|
||||
## Steps to Contribute
|
||||
|
||||
* Find an issue to work on or create a new issue. The issues are maintained at [litmuschaos/litmus] (https://github.com/litmuschaos/litmus/issues). You can pick up from a list of [good-first-issues] (https://github.com/litmuschaos/litmus/labels/good%20first%20issue).
|
||||
* Claim your issue by commenting your intent to work on it to avoid duplication of efforts.
|
||||
* Fork the repository on GitHub.
|
||||
* Create a branch from where you want to base your work (usually master).
|
||||
* Make your changes.
|
||||
* Relevant coding style guidelines are the [Go Code Review Comments](https://code.google.com/p/go-wiki/ wiki/CodeReviewComments) and the _Formatting and style_ section of Peter Bourgon's [Go: Best Practices for Production Environments](http://peter.bourgon.org/go-in-production/#formatting-and-style).
|
||||
* Commit your changes by making sure the commit messages convey the need and notes about the commit.
|
||||
* Push your changes to the branch in your fork of the repository.
|
||||
* Submit a pull request to the original repository. See [Pull Request checklist](#pull-request-checklist)
|
||||
- Find an issue to work on or create a new issue. The issues are maintained at [litmuschaos/litmus](https://github.com/litmuschaos/litmus/issues). You can pick up from a list of [good-first-issues](https://github.com/litmuschaos/litmus/labels/good%20first%20issue).
|
||||
- Claim your issue by commenting your intent to work on it to avoid duplication of efforts.
|
||||
- Fork the repository on GitHub.
|
||||
- Create a branch from where you want to base your work (usually master).
|
||||
- Make your changes.
|
||||
- Relevant coding style guidelines are the [Go Code Review Comments](https://code.google.com/p/go-wiki/wiki/CodeReviewComments) and the _Formatting and style_ section of Peter Bourgon's [Go: Best Practices for Production Environments](http://peter.bourgon.org/go-in-production/#formatting-and-style).
|
||||
- Commit your changes by making sure the commit messages convey the need and notes about the commit.
|
||||
- Push your changes to the branch in your fork of the repository.
|
||||
- Submit a pull request to the original repository. See [Pull Request checklist](#pull-request-checklist)
|
||||
|
||||
## Pull Request Checklist
|
||||
* Rebase to the current master branch before submitting your pull request.
|
||||
* Commits should be as small as possible. Each commit should follow the checklist below:
|
||||
|
||||
- For code changes, add tests relevant to the fixed bug or new feature
|
||||
- Pass the compile and tests - includes spell checks, formatting, etc
|
||||
- Commit header (first line) should convey what changed
|
||||
- Commit body should include details such as why the changes are required and how the proposed changes
|
||||
- DCO Signed
|
||||
- Rebase to the current master branch before submitting your pull request.
|
||||
- Commits should be as small as possible. Each commit should follow the checklist below:
|
||||
- For code changes, add tests relevant to the fixed bug or new feature
|
||||
- Pass the compile and tests - includes spell checks, formatting, etc
|
||||
- Commit header (first line) should convey what changed
|
||||
- Commit body should include details such as why the changes are required and how the proposed changes
|
||||
- DCO Signed
|
||||
|
||||
* If your PR is not getting reviewed or you need a specific person to review it, please reach out to the Litmus contributors at the [Litmus slack channel](https://app.slack.com/client/T09NY5SBT/CNXNB0ZTN)
|
||||
- If your PR is not getting reviewed or you need a specific person to review it, please reach out to the Litmus contributors at the [Litmus slack channel](https://app.slack.com/client/T09NY5SBT/CNXNB0ZTN)
|
||||
|
||||
## Sign your work
|
||||
|
||||
We use the Developer Certificate of Origin (DCO) as an additional safeguard for the LitmusChaos project. This is a well established and widely used mechanism to assure that contributors have confirmed their right to license their contribution under the project's license. Please add a line to every git commit message:
|
||||
|
||||
```sh
|
||||
```sh
|
||||
Signed-off-by: Random J Developer <random@developer.example.org>
|
||||
```
|
||||
```
|
||||
|
||||
Use your real name (sorry, no pseudonyms or anonymous contributions). The email id should match the email id provided in your GitHub profile.
|
||||
If you set your `user.name` and `user.email` in git config, you can sign your commit automatically with `git commit -s`.
|
||||
|
|
@ -48,15 +48,16 @@ You can also use git [aliases](https://git-scm.com/book/tr/v2/Git-Basics-Git-Ali
|
|||
|
||||
## Setting up your Development Environment
|
||||
|
||||
This project is implemented using Go and uses the standard golang tools for development and build. In addition, this project heavily relies on Docker and Kubernetes. It is expected that the contributors:
|
||||
- are familiar with working with Go;
|
||||
- are familiar with Docker containers;
|
||||
- are familiar with Kubernetes and have access to a Kubernetes cluster or Minikube to test the changes.
|
||||
This project is implemented using Go and uses the standard golang tools for development and build. In addition, this project heavily relies on Docker and Kubernetes. It is expected that the contributors.
|
||||
|
||||
- are familiar with working with Go
|
||||
- are familiar with Docker containers
|
||||
- are familiar with Kubernetes and have access to a Kubernetes cluster or Minikube to test the changes.
|
||||
|
||||
For setting up a Development environment on your local host, see the detailed instructions [here](./docs/developer.md).
|
||||
|
||||
## Community
|
||||
|
||||
The litmus community will have a weekly contributor sync-up on Tuesdays 16.00-16.30IST / 12.30-13.00CEST
|
||||
- The sync up meeting is held online on [Google Hangouts](https://meet.google.com/uvt-ozaw-bvp)
|
||||
- The release items are tracked in this [planning sheet](https://docs.google.com/spreadsheets/d/15svGB99bDcSTkwAYttH1QzP5WJSb-dFKbPzl-9WqmXM).
|
||||
- The sync up meeting is held online on [Google Hangouts](https://meet.google.com/uvt-ozaw-bvp)
|
||||
- The release items are tracked in this [planning sheet](https://docs.google.com/spreadsheets/d/15svGB99bDcSTkwAYttH1QzP5WJSb-dFKbPzl-9WqmXM).
|
||||
|
|
|
|||
29
README.md
29
README.md
|
|
@ -11,16 +11,16 @@ and Kubernetes infrastructure in a managed fashion. Its objective is to make the
|
|||
hardening of application workloads on Kubernetes easy by automating the execution of chaos experiments. A sample chaos
|
||||
injection workflow could be as simple as:
|
||||
|
||||
- Install the Litmus infrastructure components (RBAC, CRDs), the Operator & Experiment custom resource bundles via the operator manifest
|
||||
- Annotate the application under test (AUT), enabling it for chaos
|
||||
- Create a ChaosEngine custom resource tied to the AUT, which describes the experiment to be executed
|
||||
- Install the Litmus infrastructure components (RBAC, CRDs), the Operator & Experiment custom resource bundles via the operator manifest
|
||||
- Annotate the application under test (AUT), enabling it for chaos
|
||||
- Create a ChaosEngine custom resource tied to the AUT, which describes the experiment to be executed
|
||||
|
||||
Benefits provided by the Chaos Operator include:
|
||||
|
||||
- Standardised chaos experiment spec
|
||||
- Categorized chaos bundles for stateless/stateful/vendor-specific
|
||||
- Test-Run resiliency
|
||||
- Ability to chaos run as a background service based on annotations
|
||||
- Standardised chaos experiment spec
|
||||
- Categorized chaos bundles for stateless/stateful/vendor-specific
|
||||
- Test-Run resiliency
|
||||
- Ability to chaos run as a background service based on annotations
|
||||
|
||||
## What is a chaos operator and how is it built?
|
||||
|
||||
|
|
@ -40,17 +40,17 @@ runner pod), which is created & managed by it in order to implement the reconcil
|
|||
|
||||
The ChaosEngine is the core schema that defines the chaos workflow for a given application. Currently, it defines the following:
|
||||
|
||||
- Application info (namespace, labels, kind) of primary (AUT) and auxiliary (dependent) applications
|
||||
- ServiceAccount used for execution of the experiment
|
||||
- Flag to turn on/off chaos annotation checks on applications
|
||||
- Chaos Experiment to be executed on the application
|
||||
- Attributes of the experiments (overrides defaults specified in the experiment CRs)
|
||||
- Flag to retain/cleanup chaos resources after experiment execution
|
||||
- Application info (namespace, labels, kind) of primary (AUT) and auxiliary (dependent) applications
|
||||
- ServiceAccount used for execution of the experiment
|
||||
- Flag to turn on/off chaos annotation checks on applications
|
||||
- Chaos Experiment to be executed on the application
|
||||
- Attributes of the experiments (overrides defaults specified in the experiment CRs)
|
||||
- Flag to retain/cleanup chaos resources after experiment execution
|
||||
|
||||
The ChaosEngine is the referenced as the owner of the secondary (reconcile) resource with Kubernetes deletePropagation
|
||||
ensuring these also are removed upon deletion of the ChaosEngine CR.
|
||||
|
||||
Here is a sample ChaosEngineSpec for reference: https://docs.litmuschaos.io/docs/getstarted/#prepare-chaosengine
|
||||
Here is a sample ChaosEngineSpec for reference: <https://docs.litmuschaos.io/docs/getstarted/#prepare-chaosengine>
|
||||
|
||||
## What is a litmus chaos chart and how can I use it?
|
||||
|
||||
|
|
@ -145,6 +145,5 @@ improving the documentation, contributing to the core framework and tooling, etc
|
|||
|
||||
Head over to the [Contribution guide](CONTRIBUTING.md)
|
||||
|
||||
|
||||
## License
|
||||
[](https://app.fossa.io/projects/git%2Bgithub.com%2Flitmuschaos%2Fchaos-operator?ref=badge_large)
|
||||
|
|
|
|||
|
|
@ -1,49 +1,48 @@
|
|||
#### Sample Chaos Experiment
|
||||
|
||||
This folder has the required manifests to create, and run a simple pod delete chaos experiment.
|
||||
For more details, about Litmus and other experiments, please ref: https://docs.litmuschaos.io
|
||||
For more details, about Litmus and other experiments, please ref: <https://docs.litmuschaos.io>
|
||||
|
||||
|
||||
### Steps to follow to run this experiment:
|
||||
### Steps to follow to run this experiment
|
||||
|
||||
Apply the Kubernetes manifests in the described order to trigger the experiment.
|
||||
|
||||
- Deploy the Litmus chaos operator YAML. This will install the chaos CRDs in the cluster & also chaos operator deployment in `litmus` namespace
|
||||
|
||||
```
|
||||
kubectl apply -f 01-chaos-operator.yaml`
|
||||
```
|
||||
|
||||
- Create a sample nginx deployment which is annotated for chaos
|
||||
|
||||
```
|
||||
kubectl apply -f 02-annotated-nginx-deploy.yaml
|
||||
```
|
||||
|
||||
- Install the pod-delete chaosexperiment custom resource.
|
||||
|
||||
```
|
||||
kubectl apply -f 03-pod-delete-experiment.yaml
|
||||
```
|
||||
|
||||
- Create a serviceaccount with just enough permissions to execute the experiment
|
||||
- Deploy the Litmus chaos operator YAML. This will install the chaos CRDs in the cluster & also chaos operator deployment in `litmus` namespace
|
||||
|
||||
```yaml
|
||||
kubectl apply -f 01-chaos-operator.yaml`
|
||||
```
|
||||
|
||||
- Create a sample nginx deployment which is annotated for chaos
|
||||
|
||||
```yaml
|
||||
kubectl apply -f 02-annotated-nginx-deploy.yaml
|
||||
```
|
||||
|
||||
- Install the pod-delete chaosexperiment custom resource.
|
||||
|
||||
```yaml
|
||||
kubectl apply -f 03-pod-delete-experiment.yaml
|
||||
```
|
||||
|
||||
- Create a serviceaccount with just enough permissions to execute the experiment
|
||||
|
||||
```yaml
|
||||
kubectl apply -f 04-rbac-manifest.yaml
|
||||
```
|
||||
|
||||
- Create the chaosengine custom resource which ties the nginx app instance with the pod-delete experiment specification.
|
||||
- Create the chaosengine custom resource which ties the nginx app instance with the pod-delete experiment specification.
|
||||
|
||||
```
|
||||
```yaml
|
||||
kubectl apply -f 05-chaos-engine.yaml
|
||||
```
|
||||
|
||||
- To check the status of the this experiment, refer to the chaosengine status
|
||||
- To check the status of the this experiment, refer to the chaosengine status
|
||||
|
||||
```
|
||||
```yaml
|
||||
kubectl describe chaosengine engine -n litmus
|
||||
```
|
||||
```
|
||||
```yaml
|
||||
...
|
||||
Status:
|
||||
Engine Status: completed
|
||||
|
|
|
|||
Loading…
Reference in New Issue