diff --git a/.github/ISSUE_TEMPLATE/create-new-section-template.md b/.github/ISSUE_TEMPLATE/create-new-section-template.md new file mode 100644 index 00000000..8960b80c --- /dev/null +++ b/.github/ISSUE_TEMPLATE/create-new-section-template.md @@ -0,0 +1,47 @@ +--- +name: Create a new section +about: For documentation issues requiring an entirely new section in the sidebar +title: Create {section} +labels: sections + +--- + + + + + + +# Create {section-name} + +## Section Name: {section-name} + + +### Why do we need to create this section + + +### What will this section contain? + + +### Directory + + +### Sub-sections + + +##### Sub-section one + + +##### Sub-section two + + + + +## Helpful Resources + + + + + +### Comments for the reviewers? + \ No newline at end of file diff --git a/.github/ISSUE_TEMPLATE/question.md b/.github/ISSUE_TEMPLATE/question.md new file mode 100644 index 00000000..6b904771 --- /dev/null +++ b/.github/ISSUE_TEMPLATE/question.md @@ -0,0 +1,19 @@ +--- +name: 🤔 Questions +about: For Questions not answered in our community meetings, Docs, Readme or Slack +title: {title} +labels: question + +--- + + + +**Please make sure you have;** + +- Reviewed the [Questions](https://github.com/litmuschaos/litmus-docs-beta/labels/question) asked by our community members and contributers. +- Searched opened and closed [GitHub issues](https://github.com/litmuschaos/litmus-docs-beta/issues) + + +### Comments for the reviewers? + + diff --git a/.github/ISSUE_TEMPLATE.md b/.github/ISSUE_TEMPLATE/technical-issues.md similarity index 50% rename from .github/ISSUE_TEMPLATE.md rename to .github/ISSUE_TEMPLATE/technical-issues.md index 6716fbdb..d91e30bf 100644 --- a/.github/ISSUE_TEMPLATE.md +++ b/.github/ISSUE_TEMPLATE/technical-issues.md @@ -1,4 +1,12 @@ - +--- +name: 🛠️ Technical Issue +about: For BUG REPORTS & FEATURE REQUESTS only! +title: {title} +labels: technical + +--- + + ## Is this a BUG REPORT or FEATURE REQUEST? @@ -12,10 +20,7 @@ If this is a BUG REPORT, please: If this is a FEATURE REQUEST, please: - Describe *in detail* the feature/behavior/change you'd like to see. -In both cases, be ready for followup questions, and please respond in a timely -manner. If we can't reproduce a bug or think a feature already exists, we -might close your issue. If we're wrong, PLEASE feel free to reopen it and -explain why. +In both cases, be ready for follow-up questions, and please respond in a timely manner. If we can't reproduce a bug or think a feature already exists, we might close your issue. If we're wrong, PLEASE feel free to reopen it and explain why. --> **What happened**: @@ -24,4 +29,7 @@ explain why. **How to reproduce it (as minimally and precisely as possible)**: -**Anything else we need to know?**: \ No newline at end of file +**Anything else we need to know?**: + +### Comments for the reviewers? + \ No newline at end of file diff --git a/.github/ISSUE_TEMPLATE/update-documentation-template copy.md b/.github/ISSUE_TEMPLATE/update-documentation-template copy.md new file mode 100644 index 00000000..6053b486 --- /dev/null +++ b/.github/ISSUE_TEMPLATE/update-documentation-template copy.md @@ -0,0 +1,21 @@ +--- +name: ⬆️ Update documentation +about: For issues that require an update or improvement to the existing Litmus documentation +title: {title} +labels: updates + +--- + + + +## What error was observed? + + +## What improvement does this issue propose? + + +## Helpful Resources + + +### Comments for the reviewers? + diff --git a/.github/PULL_REQUEST_TEMPLATE.md b/.github/PULL_REQUEST_TEMPLATE.md index 0a4e2db3..2ddf484a 100644 --- a/.github/PULL_REQUEST_TEMPLATE.md +++ b/.github/PULL_REQUEST_TEMPLATE.md @@ -1,10 +1,14 @@ -**What this PR does / why we need it**: +### What this PR does / why we need it: + -**Which issue this PR fixes** *(optional, in `fixes #(, fixes #, ...)` format, will close that issue when PR gets merged)*: fixes # +### Which issue this PR fixes *(optional, in `fixes #(, fixes #, ...)` format, will close that issue when PR gets merged)*: fixes # -**Special notes for your reviewer**: +### What changes were made? + + +### Special notes for your reviewer: **Checklist:** - [ ] Fixes # diff --git a/.gitignore b/.gitignore index a57ed27f..9cb7e13e 100755 --- a/.gitignore +++ b/.gitignore @@ -17,6 +17,7 @@ website/i18n/* # Generated files website/.docusaurus website/.cache-loader +website/build # Misc .DS_Store diff --git a/website/build/.gitkeep b/website/build/.gitkeep deleted file mode 100644 index e69de29b..00000000 diff --git a/website/docs/agent-installation.md b/website/docs/agent-installation.md index 83f543ea..e67d9f80 100644 --- a/website/docs/agent-installation.md +++ b/website/docs/agent-installation.md @@ -4,12 +4,12 @@ title: Litmus Chaos Agent Install sidebar_label: Chaos Agent --- -In Litmus the Agents can be classified as two types +In Litmus the Agents can be classified into two, namely; - Self Agent - External Agent -As part of Litmus installation by default, a self cluster would be registered as Agent in the Portal. From Portal you induce chaos into self cluster and observe the results from the Portal. +As a part of the Litmus installation, by default, a self cluster would be registered as an Agent in the Portal. From the Portal you may induce chaos into self cluster and observe the results from the Portal. As you are aware by now, Portal is a Cross Cloud Chaos Control plane. That is you can connect multiple external kubernetes agents to this portal. Once connected you can manage the chaos from the Portal that is you can induce chaos into this agent from the Portal and observe the results from the Portal. Using the command line utility _litmusctl_ you can connect the external agents to the Portal. @@ -193,4 +193,4 @@ Installation Mode: cluster 👉 Litmus agents can be accessed here: http://172.17.0.2:31696/targets ``` -To verify, if the connection process was successful you can view the list of connected agents from the Targets section on your LitmusPortal and ensure that the connected agent is in Active State. +To verify, if the connection process was successful you can view the list of connected agents from the targets section on your LitmusPortal and ensure that the connected agent is in Active State. diff --git a/website/docs/architecture.md b/website/docs/architecture.md index cb20f9c0..7b94cb0d 100644 --- a/website/docs/architecture.md +++ b/website/docs/architecture.md @@ -13,40 +13,33 @@ The above picture gives you a high-level architecture of the Litmus. At highleve 1. Portal 2. Agents -**Portal** is a set of Litmus components which act as Cross Cloud Chaos Control plane (WebUI) which is be used to orchestrate and observe the chaos workflows on Agents. +**Portal** is a set of Litmus components which act as Cross Cloud Chaos Control plane (WebUI) which is used to orchestrate and observe the chaos workflows on Agents. **Agent** is the set of Litmus components which induces Chaos using the chaos workflows on the K8S cluster component. -Typical user scenario, The user would install litmus. This would in-turn install Portal and Agent on the self cluster. Using the portal user can create/schedule new chaos workflows on the Agents and observe the results from here. User can also connect more clusters to the portal, and use the Portal as single window pane for cross cloud chaos management. +A typical user scenario would be when a user would install litmus. This would, in turn, install Portal and Agent on the self cluster. Using the portal, the user can create/schedule new chaos workflows on the Agents and observe the results from here. Users can also connect more clusters to the portal, and use the Portal as single window pane for cross cloud chaos management. - -**Portal Components** +#### Portal Components Portal has the following components -- Litmus WebUI - - Litmus UI provides web user interface, where user can construct and observe the chaos workflow at ease. Also this act as cross cloud chaos control plane that is - -- Litmus Server - - Litmus Server act as middle ware which is use to handle API request from the user interface, store the config and results details into the DB. This also act as interface to communicate between the requests and scheduling the workflow to Agent. +- **Litmus WebUI**
+ Litmus UI provides web user interface, where a user can construct and observe the chaos workflow at ease. Also this act as a cross cloud chaos control plane. -- Litmus DB +- **Litmus Server**
+ Litmus Server act as middleware which is use to handle API request from the user interface, store the config and result details into the DB. This also act as an interface to communicate between the requests and scheduling the workflow to the Agent. - Litmus DB act as config store for chaos workflows and its results. - -**Agent components** +- **Litmus DB**
+ Litmus DB act as a config store for chaos workflows and its results. +#### Agent components Agents has the following Litmus components -- Chaos Operator - - Chaos-Operator watches for the ChaosEngine CR and executes the Chaos-Experiments mentioned in the CR. Chaos-Operator is namespace scoped. By default, it runs in `litmus` namespace. Once the experiment is completed, chaos-operator invokes chaos-exporter to export chaos metrics to a Prometheus database. - -- CRDs +- **Chaos Operator**
+ Chaos-Operator watches for the ChaosEngine CR and executes the Chaos-Experiments mentioned in the CR. Chaos-Operator is namespace scoped. By default, it runs on the `litmus` namespace. Once the experiment is completed, chaos-operator invokes chaos-exporter to export chaos metrics to a Prometheus database. +- **CRDs**
During installation, the following three CRDs are installed on the Kubernetes cluster. ``` @@ -55,27 +48,21 @@ Agents has the following Litmus components chaosresults.litmuschaos.io ``` -- Chaos Experiment +- **Chaos Experiment**
+ Chaos Experiment is a CR and are available as YAML files on [Chaos Hub](https://hub.litmuschaos.io/). For more details visit [Chaos Hub documentation](https://litmusdocs-beta.netlify.app/docs/chaoshub). - Chaos Experiment is a CR and are available as YAML files on [Chaos Hub](https://hub.litmuschaos.io/). For more details visit Chaos Hub [documentation](https://litmusdocs-beta.netlify.app/docs/chaoshub). +- **Chaos Engine**
+ ChaosEngine CR links application to experiments. User has to create ChaosEngine YAML by specifying the application label, it's experiments and create the CR. The CR is watched by Chaos-Operator and chaos-experiments are executed on a given application. -- Chaos Engine - - ChaosEngine CR links application to experiments. User has to create ChaosEngine YAML by specifying the application label and experiments and create the CR. The CR is watched by Chaos-Operator and chaos-experiments are executed on a given application. - -- Chaos Results - - ChaosResult resource holds the results of a ChaosExperiment with a namespace scope. It is created or updated at runtime by the experiment itself. It holds important information like the ChaosEngine reference, Experiment State, Verdict of the experiment (on completion), salient application/result attributes. It is also a source for metrics collection. It is updated/patched with the status of the experiment run. It is not removed as part of the default cleanup procedures to allow for extended reference. - -- Chaos Probes +- **Chaos Results**
+ ChaosResult resource holds the results of a ChaosExperiment within a namespace scope. It is created or updated at runtime by the experiment itself. It holds important information like the ChaosEngine reference, Experiment State, Verdict of the experiment (on completion), salient application/result attributes. It is also a source for metrics collection. It is updated/patched with the status of the experiment run. It is not removed as part of the default cleanup procedures to allow for extended reference. +- **Chaos Probes**
Litmus probes are pluggable checks that can be defined within the ChaosEngine for any chaos experiment. The experiment pods execute these checks based on the mode they are defined in & factor their success as necessary conditions in determining the verdict of the experiment (along with the standard “in-built” checks). -- Chaos Exporter - +- **Chaos Exporter**
Optionally metrics can be exported to a Prometheus database. Chaos-Exporter implements the Prometheus metrics endpoint. -- Subscriber - +- **Subscriber**
Subscriber is the component used in Agent side which interact with Litmus Server component to get the details of Chaos workflow and send the results back. diff --git a/website/docs/getstarted.md b/website/docs/getstarted.md index 68e21b4a..ed947762 100644 --- a/website/docs/getstarted.md +++ b/website/docs/getstarted.md @@ -20,11 +20,11 @@ sidebar_label: Pre-requisites Running chaos on your application involves the following steps: -[Install Litmus](litmus-install-cluster-mode) +- [Install Litmus](litmus-install-cluster-mode) -[How to Create and Run a Workflow](create-workflow) +- [How to Create and Run a Workflow](create-workflow) -[Observe ChaosResults](observe-workflow) +- [Observe ChaosResults](observe-workflow)
diff --git a/website/docs/introduction.md b/website/docs/introduction.md index cb525576..4ee8986d 100644 --- a/website/docs/introduction.md +++ b/website/docs/introduction.md @@ -14,11 +14,11 @@ Service downtimes are always expensive and they are very difficult to predict an LitmusChaos is a complete framework to implement chaos engineering within a cloud-native ecosystem. It helps both Developers and SREs automate the chaos experiments at different stages within the DevOps pipeline like development, during CI/CD, & in production. -- What is a Chaos Experiment? +#### What is a Chaos Experiment? Chaos Experiments are fundamental units within the LitmusChaos architecture. Users can choose between readily available chaos experiments or create new ones to construct a required chaos workflow. -- What is a Chaos Workflow? +#### What is a Chaos Workflow? A chaos workflow is much more than a simple chaos experiment. It supports the user in defining the expected result, observing the result, analysing the overall system behaviour, and in the decision-making process if the system needs to be tuned for improving the resilience. LitmusChaos provides necessary infrastructure to develop, use, and manage chaos workflows for a typical development or operations team. Teaming and GitOps features of Litmus help greatly to collaborate the chaos workflows management within the teams or software organisations. diff --git a/website/docs/litmus-installation-cluster.md b/website/docs/litmus-installation-cluster.md index 83864873..98b5f26b 100644 --- a/website/docs/litmus-installation-cluster.md +++ b/website/docs/litmus-installation-cluster.md @@ -7,6 +7,10 @@ sidebar_label: Control Plane (Cluster Mode) --- +
+
+ +Installing Litmus in cluster mode gives Litmus access to cluster wide resources. Here, the CRDs are installed directly on the cluster. ## Pre-requisites @@ -18,12 +22,12 @@ sidebar_label: Control Plane (Cluster Mode) ## Installation -Installation of Litmus can be done using either of the below methods +Installation of Litmus can be done using either of the below methods; - [Helm3](#helm_install) chart or - [Kubectl](#kubectl_install) yaml spec file -### Installation Steps +### Install Litmus using Helm The helm chart will install all the required service account configuration and chaos control plane. @@ -38,7 +42,7 @@ helm repo list #### Step-2: Create the litmus namespace -- The litmus infra components will be placed in this namespace. +The litmus infra components will be placed in this namespace. **Note**: The chaos control plane can be placed in any namespace, though it is typically placed in "litmus". diff --git a/website/docs/litmus-installation-namespace.md b/website/docs/litmus-installation-namespace.md index e4a14954..2f365bb5 100644 --- a/website/docs/litmus-installation-namespace.md +++ b/website/docs/litmus-installation-namespace.md @@ -7,12 +7,16 @@ sidebar_label: Control Plane (Namespace Mode) --- +
+
+ +Installing Litmus in namespace mode limits Litmus access to a particluar namespace. Here, you need to create a namespace where Litmus CRDs would be installed directly. This namespace will be specified during the installation step. ## Pre-requisites - Kubernetes 1.15 or later. ​ -- Recommend to have a Persistent volume(PV) of 20GB, You can start with 1GB for test purposes as well. This PV is used as persistent storage to store the chaos config and chaos-metrics in the Portal. By default, litmus would use the default storage class to allocate the PV. +- It is Recommended to have a Persistent volume(PV) of 20GB, You can start with 1GB for test purposes as well. This PV is used as persistent storage to store the chaos config and chaos-metrics in the Portal. By default, litmus would use the default storage class to allocate the PV. - Helm3 or Kubectl @@ -38,7 +42,7 @@ helm repo list #### Step-2: Create the litmus namespace -- The litmus infra components will be placed in this namespace. +The litmus infra components will be placed in this namespace. **Note**: The chaos control plane can be placed in any namespace, though it is typically placed in "litmus". @@ -72,7 +76,7 @@ Visit https://docs.litmuschaos.io/docs/getstarted/ to find more info. > **Note:** Litmus uses Kubernetes CRDs to define chaos intent. Helm3 handles CRDs better than Helm2. Before you start running a chaos experiment, verify if Litmus is installed correctly. -- The cluster-admin or an equivalent user with the right permissions are required to install them CRDs upfront. To apply LitmusCRDs: +The cluster-admin or an equivalent user with the right permissions are required to install the CRDs upfront. To apply LitmusCRDs, run the command below. ```bash kubectl apply -f https://raw.githubusercontent.com/litmuschaos/litmus/master/litmus-portal/litmus-portal-crds.yml @@ -95,7 +99,7 @@ customresourcedefinition.apiextensions.k8s.io/eventtrackerpolicies.eventtracker. #### **Install Litmus** -- Set the namespace on which you want to install litmus. +Set the namespace on which you want to install litmus. ```bash export LITMUS_PORTAL_NAMESPACE="" @@ -105,7 +109,7 @@ kubectl get ns ${LITMUS_PORTAL_NAMESPACE} kubectl create ns ${LITMUS_PORTAL_NAMESPACE} ``` -- The cluster-admin or an equivalent user with the right permissions are required to install them CRDs upfront. To apply LitmusCRDs: +The cluster-admin or an equivalent user with the right permissions are required to install them CRDs upfront. To apply LitmusCRDs, run: ```bash kubectl apply -f https://raw.githubusercontent.com/litmuschaos/litmus/master/litmus-portal/litmus-portal-crds.yml @@ -124,7 +128,7 @@ customresourcedefinition.apiextensions.k8s.io/chaosresults.litmuschaos.io create customresourcedefinition.apiextensions.k8s.io/eventtrackerpolicies.eventtracker.litmuschaos.io created ``` -- Replace namespace with the target namespace. +Replace namespace with the target namespace. ```bash export LITMUS_PORTAL_NAMESPACE="" @@ -168,7 +172,7 @@ service/mongo-service created mongo-0 1/1 Running 0 6m16s ``` -- Check the services running in litmus namespace: +Check the services running in litmus namespace: ```bash kubectl get svc -n litmus diff --git a/website/docs/observe-workflow.md b/website/docs/observe-workflow.md index d3f4c303..2759a889 100644 --- a/website/docs/observe-workflow.md +++ b/website/docs/observe-workflow.md @@ -8,7 +8,7 @@ sidebar_label: Observe Workflow --- -After scheduling a workflow, the user can track the status of the workflow from the Browse Workflow section. The status that is currently displayed are : +After scheduling a workflow, the user can track the status of the workflow from the Browse Workflow section. The status that is currently displayed are: - Failed - Running diff --git a/website/docs/terms.md b/website/docs/terms.md new file mode 100644 index 00000000..b023a9c5 --- /dev/null +++ b/website/docs/terms.md @@ -0,0 +1,31 @@ +--- +id: terms +title: Glossary Terms +sidebar_label: Terms +--- + +--- + +- **Chaos Engineering**: [Chaos Engineering](https://en.wikipedia.org/wiki/Chaos_engineering) is a field of engineering that is focused on the design and implementation of systems that are subject to failure. + +- **Chaos Experiments**: [Chaos Experiments](https://en.wikipedia.org/wiki/Chaos_experiment) are off-the-shelf templates that one needs to "pull" before including them as part of a chaos run against any target applications + +- **Chaos Workflow**: [Chaos Workflow](https://en.wikipedia.org/wiki/Chaos_workflow) is a type of workflow that is used to model the behavior of a system under failure. It supports the user in defining the expected result, observing the result, analysing the overall system behaviour, and in the decision-making process if the system needs to be tuned for improving the resilience of the system. + +- **CRDs**: [Custom Resource Definitions](https://kubernetes.io/docs/concepts/api-extension/custom-resources/) are a type of Kubernetes API that allows users to define their own custom resources. + +- **Chaos Operator**: [Chaos Operator](https://github.com/litmuschaos/chaos-operator) is are used to inject chaos into applications and Kubernetes architecture in a fashioned manner. + +- **Chaos Scheduler**: [Chaos Scheduler](https://github.com/litmuschaos/chaos-scheduler) is a Kubernetes scheduler, which are custom-controllers with direct access to Kubernetes API that can manage the lifecycle of certain resources or applications, while always trying to ensure the resource is in the "desired state". + +- **Chaos Control Plane**: [Chaos Control Plane](https://docs.litmuschaos.io/docs/architecture/chaos-control-plane/) consist of micro-services responsible for the functioning of the Chaos Center, the website-based portal that can be used for interacting with Litmus, apart from the CLI. + +- **Litmus Service Account**: [Kubernetes Service Account](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/) allow you to give an identity to your Pods, which can be used to: Authenticate Pods to the Kubernetes API server, allowing the Pods to read and manipulate Kubernetes API objects (for example, a CI/CD pipeline that deploys applications to your cluster). + +- **ChaosCenter**: [Chaos Center](https://docs.litmuschaos.io/docs/getting-started/resources#chaoscenter) is a single source of truth to control all the different Chaos Activities happening around Litmus + +- **Chaos Agent**: [Chaos Agent](https://docs.litmuschaos.io/docs/getting-started/resources#chaosagents) is the target cluster where Chaos would be injected via Litmus. + +- **Gitops**: [Gitops](https://docs.litmuschaos.io/docs/concepts/overview#gitops/) enables you to configure a single source of truth for your chaos workflows and experiments + +- **Probes**: [Probes](https://docs.litmuschaos.io/docs/concepts/probes) are pluggable checks that can be defined within the ChaosEngine for any Chaos Experiment \ No newline at end of file diff --git a/website/docs/tutorials.md b/website/docs/tutorials.md index 4d4d8702..bfca2c67 100644 --- a/website/docs/tutorials.md +++ b/website/docs/tutorials.md @@ -6,7 +6,8 @@ sidebar_label: Tutorials import {Tutorials} from '@site/src/components/tutorials/Tutorials/Tutorials.jsx' -The tutorials help you to quickly learn some of the standard day-0 to day-n flows associated with the LitmusChaos framework (and Chaos Engineering in general). Each tutorial is created with a definitive objective. If you believe the objective is not met, please create issues on the Github repository stating what is missing. + +The tutorials help you to quickly learn the LitmusChaos framework (and Chaos Engineering in general). This tutorial is splitted into a flow that lets you learn Litmus at in a self paced manner, there are n-days and you can choose to go over each day accordingly or x-days at the same time. Each tutorial is created with a definitive objective. If you believe the objective is not met, please create issues on the Github repository stating what is missing. --- diff --git a/website/sidebars.js b/website/sidebars.js index 213e9372..d89967e0 100644 --- a/website/sidebars.js +++ b/website/sidebars.js @@ -51,6 +51,7 @@ module.exports = { // "rbac", // "service-acounts", // ], - Advanced: ['litmus-psp', 'k8s-support'] + Advanced: ['litmus-psp', 'k8s-support'], + Glossary: ['terms'], } }