From 67ae0c3ce900d9f98ca39fbaa724b08a4fb0729e Mon Sep 17 00:00:00 2001 From: Neelanjan Manna Date: Fri, 14 Jun 2024 19:01:23 +0530 Subject: [PATCH] refactors getting-started, architecture and concepts sections (#263) Signed-off-by: neelanjan00 --- .../docs/architecture/architecture-summary.md | 21 ++++--- .../docs/architecture/chaos-control-plane.md | 8 +-- .../architecture/chaos-execution-plane.md | 11 ++-- .../architecture/chaos-experiment-flow.md | 10 ++-- website/docs/concepts/chaos-workflow.md | 32 ++++++----- website/docs/concepts/chaoshub.md | 45 ++++++++------- website/docs/concepts/infrastructure.md | 29 +++++----- website/docs/concepts/oauth-dex-concept.md | 8 +-- website/docs/concepts/probes.md | 6 +- website/docs/concepts/projects.md | 2 +- website/docs/concepts/teaming.md | 4 +- website/docs/concepts/user-management.md | 20 +++---- website/docs/concepts/visualize-experiment.md | 21 ++++--- website/docs/getting-started/installation.md | 10 ++-- website/docs/getting-started/resources.md | 56 +++++++------------ .../architecture/architecture-summary.md | 21 ++++--- .../architecture/chaos-control-plane.md | 8 +-- .../architecture/chaos-execution-plane.md | 11 ++-- .../architecture/chaos-experiment-flow.md | 10 ++-- .../version-3.0.0/concepts/chaos-workflow.md | 32 ++++++----- .../version-3.0.0/concepts/chaoshub.md | 45 ++++++++------- .../version-3.0.0/concepts/infrastructure.md | 29 +++++----- .../concepts/oauth-dex-concept.md | 8 +-- .../version-3.0.0/concepts/probes.md | 6 +- .../version-3.0.0/concepts/projects.md | 2 +- .../version-3.0.0/concepts/teaming.md | 4 +- .../version-3.0.0/concepts/user-management.md | 20 +++---- .../concepts/visualize-experiment.md | 21 ++++--- .../getting-started/installation.md | 2 +- .../getting-started/resources.md | 56 +++++++------------ 30 files changed, 265 insertions(+), 293 deletions(-) diff --git a/website/docs/architecture/architecture-summary.md b/website/docs/architecture/architecture-summary.md index 670571ac..76db8e86 100644 --- a/website/docs/architecture/architecture-summary.md +++ b/website/docs/architecture/architecture-summary.md @@ -1,7 +1,7 @@ --- id: architecture-summary -title: Architecture Summary -sidebar_label: Architecture Summary +title: Architecture summary +sidebar_label: Architecture summary --- --- @@ -10,16 +10,19 @@ sidebar_label: Architecture Summary The Litmus architecture can be segregated into two parts: -1. **Control Plane:** Contains the components required for the functioning of ChaosCenter, the website-based portal for Litmus. +1. **Control plane:** Contains the components required for the functioning of ChaosCenter, the website-based portal for Litmus. -2. **Execution Plane:** Contains the components required for the injection of chaos in the target resources. +2. **Execution plane:** Contains the components required for the injection of chaos in the target resources. -ChaosCenter can be used for creating and scheduling Chaos Experiments, a set of chaos faults defined in a definitive sequence to achieve desired chaos impact on the target resources upon execution. Users can log in to the ChaosCenter using valid login credentials and leverage the interactive web UI to define their chaos experiment to target multiple aspects of their infrastructure. Once the user creates a Chaos Experiment using the ChaosCenter, it is passed on to the Execution Plane. The Execution Plane can be present either in the host cluster containing the Control Plane if the self chaos infrastructure is being used, or in the target cluster if an external chaos infrastructure is being used. The Execution Plane interprets the Chaos Experiment as a list of steps required for injecting chaos into the target resources. It ensures efficient orchestration of chaos in cloud-native environments using various Kubernetes CRs. Once the Chaos Experiment is executed, Execution Plane sends the chaos result to the Control Plane for their post-processing using either the built-in monitoring dashboard of Litmus or using external observability tools such as Prometheus DB and Grafana dashboard. Litmus also achieves automated Chaos Experiment runs to execute chaos as part of the CI/CD pipeline based on a set of defined conditions using GitOps. +- Control plane can be used for creating and scheduling chaos experiments, which is a set of chaos faults defined in a definitive sequence to achieve desired chaos impact on the target resources upon execution. Users can log in to the ChaosCenter using the web UI or the APIs to define a chaos experiment and assess the resilience of target workloads. + +- Once the user creates a chaos experiment using the ChaosCenter, it is passed on to the execution plane. The Execution plane can be present either in the same cluster as the ChaosCenter if the self chaos infrastructure is being used, or in a remote cluster if an external chaos infrastructure is being used. The Execution plane interprets the chaos experiment as a list of actions that will inject chaos into the target workloads. It ensures efficient orchestration of chaos in various cloud-native environments using Kubernetes custom resources. + +- Once the chaos experiment is executed, Execution plane sends the chaos result to the control plane for their post-processing using either the built-in monitoring dashboard of Litmus or using external observability tools such as Prometheus DB and Grafana dashboard. Litmus also achieves automated chaos experiment runs to execute chaos as part of the CI/CD pipeline based on a set of defined conditions using GitOps. :::note With the latest release of LitmusChaos 3.0.0: - -
  • The term Chaos Delegate/Agent has been changed to Chaos Infrastructure.
    • -
  • The term Chaos Experiment has been changed to Chaos Fault.
    • -
  • The term Chaos Scenario/Workflow has been changed to Chaos Experiment.
    • +- The term **Chaos Delegate/Agent** has been changed to **Chaos Infrastructure**. +- The term **Chaos Experiment** has been changed to **Chaos Fault**. +- The term **Chaos Scenario/Workflow** has been changed to **Chaos Experiment**. ::: diff --git a/website/docs/architecture/chaos-control-plane.md b/website/docs/architecture/chaos-control-plane.md index 2bdd3fbb..84e44821 100644 --- a/website/docs/architecture/chaos-control-plane.md +++ b/website/docs/architecture/chaos-control-plane.md @@ -1,16 +1,16 @@ --- id: chaos-control-plane -title: Chaos Control Plane -sidebar_label: Chaos Control Plane +title: Chaos control plane +sidebar_label: Chaos control plane --- --- Chaos Control Plane -Chaos Control Plane consists of micro-services responsible for the functioning of the ChaosCenter, the website-based portal that can be used for interacting with Litmus, apart from the CLI. Chaos Plane facilitates the creation and scheduling of chaos experiments, system observability during the event of chaos, and post-processing and analysis of fault results. +Chaos control plane consists of micro-services responsible for the functioning of the ChaosCenter, the website-based portal that can be used for interacting with Litmus, apart from the CLI. Chaos Plane facilitates the creation and scheduling of chaos experiments, system observability during the event of chaos, and post-processing and analysis of fault results. -## Chaos Control Plane Components +## Chaos control plane components - **Authentication Server:** A Golang micro-service that is responsible for authorizing, authenticating the requests received from ChaosCenter and managing users along with their projects. It primarily serves the cause of user creation, user login, resetting the password, updating user information, creating project, managing project related operations. diff --git a/website/docs/architecture/chaos-execution-plane.md b/website/docs/architecture/chaos-execution-plane.md index fc3010fe..b870ee8a 100644 --- a/website/docs/architecture/chaos-execution-plane.md +++ b/website/docs/architecture/chaos-execution-plane.md @@ -1,7 +1,7 @@ --- id: chaos-execution-plane -title: Chaos Execution Plane -sidebar_label: Chaos Execution Plane +title: Chaos execution plane +sidebar_label: Chaos execution plane --- --- @@ -65,8 +65,7 @@ It is worth noticing that: :::note With the latest release of LitmusChaos 3.0.0: - -
  • The term Chaos Delegate/Agent has been changed to Chaos Infrastructure.
    • -
  • The term Chaos Experiment has been changed to Chaos Fault.
    • -
  • The term Chaos Experiment/Workflow has been changed to Chaos Experiment.
    • +- The term **Chaos Delegate/Agent** has been changed to **Chaos Infrastructure**. +- The term **Chaos Experiment** has been changed to **Chaos Fault**. +- The term **Chaos Scenario/Workflow** has been changed to **Chaos Experiment**. ::: diff --git a/website/docs/architecture/chaos-experiment-flow.md b/website/docs/architecture/chaos-experiment-flow.md index 18829215..62437069 100644 --- a/website/docs/architecture/chaos-experiment-flow.md +++ b/website/docs/architecture/chaos-experiment-flow.md @@ -1,7 +1,7 @@ --- id: chaos-fault-flow -title: Chaos Fault Flow -sidebar_label: Chaos Fault Flow +title: Chaos fault flow +sidebar_label: Chaos fault flow --- --- @@ -31,7 +31,7 @@ The fault execution is triggered upon the creation of a ChaosEngine resource. Th :::note With the latest release of LitmusChaos 3.0.0: - -
  • The term Chaos Experiment has been changed to Chaos Fault.
    • -
  • The term Chaos Experiment/Workflow has been changed to Chaos Experiment.
    • +- The term **Chaos Delegate/Agent** has been changed to **Chaos Infrastructure**. +- The term **Chaos Experiment** has been changed to **Chaos Fault**. +- The term **Chaos Scenario/Workflow** has been changed to **Chaos Experiment**. ::: diff --git a/website/docs/concepts/chaos-workflow.md b/website/docs/concepts/chaos-workflow.md index c2c69abb..824590e6 100644 --- a/website/docs/concepts/chaos-workflow.md +++ b/website/docs/concepts/chaos-workflow.md @@ -1,20 +1,23 @@ --- id: chaos-workflow -title: Chaos Experiment -sidebar_label: Chaos Experiment +title: Chaos experiment +sidebar_label: Chaos experiment --- --- -**Chaos Experiment** is a set of different operations coupled together to achieve desired chaos impact on a Kubernetes Cluster.
    -It is useful in automating a series of pre-conditioning steps or action which is necessary to be performed before triggering the chaos injection.
    -A Chaos Experiment can also be used to perform different operations parallelly to achieve a desired chaos impact. +Chaos experiments gives you the flexibility to create complex, real-life failure scenarios that are used to validate your target workloads. At the same time, chaos experiments are declarative and can be constructed using the ChaosCenter UI without any programmatic intervention. + +A chaos experiment is composed of chaos faults that are arranged in a specific order to create a failure scenario. The chaos faults target various aspects of an application, including the constituent microservices and underlying infrastructure. You can tune the parameters associated with these faults to impart the desired chaos behavior. + +- It is useful in automating a series of pre-conditioning steps or action which is necessary to be performed before triggering the chaos injection. + +- A Chaos Experiment can also be used to perform different operations parallelly to achieve a desired chaos impact. :::note 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.
    • +The term **Chaos Experiment** has been changed to **Chaos Fault**. +The term **Chaos Scenario/Workflow** has been changed to **Chaos Experiment**. ::: ## Prerequisites @@ -25,12 +28,13 @@ The following should be required before creating a Chaos Experiment: - [Chaos Infrastructure](../getting-started/resources.md#chaosagents) - [Probes](probes.md) -## How do we define and execute a Chaos Experiment ? +## Defining and executing a chaos experiment + +LitmusChaos leverages the popular GitOps tool **Argo** to achieve this goal. Argo enables the creation of different chaos experiments together in form of chaos experiments which are extremely simple and efficient to use. -LitmusChaos leverages the popular GitOps tool **Argo** to achieve this goal. Argo enables the creation of different chaos experiments together in form of chaos experiments which are extremely simple and efficient to use.
    With the help of **ChaosCenter**, chaos experiments with different types of faults can be created. In a Chaos Experiment, the faults can be set to execute in parallel to each other and the user can tune the chaos experiment by adding additional steps to simulate a desired fault that might occur in the production stage. -### Life Cycle of a Chaos Experiment +### Chaos experiment life cycle Here is a sample pod-delete chaos experiment from ChaosCenter. @@ -232,11 +236,11 @@ These include installing the chaos faults, executing the chaos engine of the fau Some additional checks can be added with the faults in the form of probes. These probes are defined in the ChaosEngines of the faults and are updated when the fault execution takes place. The overall chaos experiment result can be viewed with the ChaosResult CRD which contains the `verdict` and the `probeSuccessPercentage` (a ratio of successful checks v/s total probes). -## What is a run? +## Chaos experiment run A chaos experiment run can be defined as a single/one-time execution of the chaos experiment. There can be multiple runs of a single chaos experiment. If the chaos experiment consists of a cron syntax, it will run periodically according to the cron provided in the chaos experiment. -## What is Resilience Score? +## Resilience Score **Resiliency score** is an overall measure of the resiliency of a system for a given chaos experiment, which is obtained upon executing the constituent experiment faults on that system. @@ -255,7 +259,7 @@ Total Resilience for one single fault = (Weight Given to that fault * Probe Succ Overall Resilience Score = Total Test Result / Sum of the assigned weights of the faults ``` -## What is a Cron Chaos Experiment? +## Cron chaos experiment Cron Chaos Experiment is a type of chaos experiment that runs on a pre-defined schedule. It consists of a mandatory field `spec.schedule`. A cron syntax is provided in this field at which the chaos experiment execution takes place. diff --git a/website/docs/concepts/chaoshub.md b/website/docs/concepts/chaoshub.md index 66351540..15ccac93 100644 --- a/website/docs/concepts/chaoshub.md +++ b/website/docs/concepts/chaoshub.md @@ -6,7 +6,11 @@ sidebar_label: ChaosHub --- -ChaosHub allows you to orchestrate chaos experiments from the Public **[ChaosHub](http://hub.litmuschaos.io/)** or an alternate source for the Experiments (basically, a **[fork](https://github.com/litmuschaos/chaos-charts)** of the public hub with custom faults). +A ChaosHub is a collection of experiment templates and faults that you can use to create and launch chaos experiments. Both experiments and faults are stored as manifests in an appropriate directory structure. This way, new experiment templates and faults can be added directly to the repository as files. In addition, the experiment templates can be derived from the existing experiments to be saved in ChaosHub from the web UI. + +- ChaosHub is accessed using a Git service provider such as GitHub, where ChaosHub exists as a repository. This allows native version control and management of the faults and experiment artifacts. + +- Chaos experiments can be created from the public [ChaosHub](http://hub.litmuschaos.io/) which is already connected to your ChaosCenter, or a custom ChaosHub which is a [fork](https://github.com/litmuschaos/chaos-charts) of the public ChaosHub where custom faults can be stored. ## Prerequisites @@ -18,37 +22,37 @@ The following are the prerequisites for creating a Chaos Experiment: An active internet connection is required to clone the git repository for the first time installation. ::: -## Connecting a Git repository using ChaosHub +## Connecting to a Git repository using ChaosHub With ChaosHub, you can construct chaos experiments by selecting, tuning and sequencing different faults together from their connected ChaosHubs. You can make changes in your forked repositories and sync it with the Portal to get the latest changes from the fork. -By default, a Public ChaosHub is provided when the ChaosCenter is installed for the first time. +By default, a public ChaosHub is provided when the ChaosCenter is installed for the first time. -### 1. Connect a Public Git Repository +### 1. Connect a public Git repository You can connect to a public Git repository by simply providing the following details: -- Hub Name +- Hub name - Git URL of the forked repository -- Branch Name +- Branch name -### 2. Connect a Private Git Repository +### 2. Connect a private Git repository -To add a Private Hub, you need provide the Hub name, Git URL of the forked repository and the Branch name similar to that of Public Hub and the repository can be connected by 2 methods: +To add a private ChaosHub, you need provide the hub name, Git URL of the forked repository and the branch name similar to that of public hub and the repository can be connected in two ways: -#### a. Access Token +#### a. Access token Personal Access Tokens are used as an alternative to the password for authentication to Git services. -#### b. SSH Key +#### b. SSH key Just like the Access Token , SSH keys are used for the authentication. These keys come in pairs, a public key that is shared with the Git Services and a private key that is stored with you. SSH link of the repository should be provided if you select this method. @@ -57,13 +61,13 @@ SSH link of the repository should be provided if you select this method. ## Syncing a ChaosHub -If some changes are made into the git repository, you can reflect these changes in the hub by selecting the **Refresh Hub** option from the ChaosHub card. +If some changes are made into the Git repository, you can reflect these changes in the hub by selecting the **Refresh Hub** option from the ChaosHub card. ## Editing a ChaosHub To make changes in a hub like changing the name, branch, access token etc, you can select the **Edit Hub** option from the ChaosHub card. -## Chaos Experiments and Experiments in a ChaosHub +## Chaos experiments and experiments in a ChaosHub ### 1. View the PreDefined Chaos Experiments @@ -73,16 +77,16 @@ After connecting a ChaosHub, you can view the different pre-defined chaos experi ### 2. View the Chaos Faults -Similarly, you can view the different charts and the fault. These charts are sorted according to different categories like generic, aws, azure, kube-components etc. +Similarly, you can view the different charts and the fault. These charts are sorted according to different categories like generic, AWS, Azure, Kube-Components etc. ### 3. View the fault details -You can select one of the chaos faults and can examine the fault details. -The fault page consists of all the important details like the description of the fault, a tutorial video, the maintainer of the fault, etc. -You can also find the fault yaml link, RBAC link, and the ChaosEngine yaml link of the fault. -These yaml links are required for the creation of Custom Chaos Experiments. +You can select one of the chaos faults and can examine the fault details. The fault page consists of all the important details like the description of the fault, a tutorial video, the maintainer of the fault, etc. + +You can also find the Experiment manifest URL, RBAC URL, and the ChaosEngine URLs of the fault. +These URLs are required for the creation of custom chaos experiments. @@ -92,10 +96,9 @@ To remove a ChaosHub from a project, you can select the **Disconnect Hub** optio ## Summary -You can select one of the chaos faults and can examine the fault details. -The fault page consists of all the important details like the description of the fault, a tutorial video, the maintainer of the fault, etc. -You can also find the fault yaml link, RBAC link, and the ChaosEngine yaml link of the fault. -These yaml links are required for the creation of Custom Chaos Experiments. +You can select one of the chaos faults and can examine the fault details.The fault page consists of all the important details like the description of the fault, a tutorial video, the maintainer of the fault, etc. +You can also find the Experiment URL URL, RBAC URL, and the ChaosEngine yaml URL of the fault. +These yaml URLs are required for the creation of Custom Chaos Experiments. ## Learn More diff --git a/website/docs/concepts/infrastructure.md b/website/docs/concepts/infrastructure.md index c48381db..32f743d1 100644 --- a/website/docs/concepts/infrastructure.md +++ b/website/docs/concepts/infrastructure.md @@ -1,34 +1,31 @@ --- id: chaos-infrastructure -title: Chaos Infrastructure -sidebar_label: Chaos Infrastructure +title: Chaos infrastructure +sidebar_label: Chaos infrastructure --- -Chaos infrastructure is a service that runs in your target environment and aids the Litmus control plane in accessing and injecting chaos at a cloud-native scale. All the chaos infrastructure services adhere to the principle of least privilege, where the services execute with the minimum number of required permissions. A Chaos Infrastructure can be created under a Chaos Environment. +Chaos infrastructure is a service that runs in your target environment and aids the Litmus control plane in accessing and injecting chaos at a cloud-native scale. All the chaos infrastructure services adhere to the principle of least privilege, where the services execute with the minimum number of required permissions. A chaos infrastructure can be created under a Chaos Environment. :::note -With the latest release of LitmusChaos 3.0.0 the term **Chaos Delegate/Agent** has been changed to **Chaos Infrastructure** +With the latest release of LitmusChaos 3.0.0 the term **Chaos Delegate/Agent** has been changed to **Chaos Infrastructure**. ::: -## Chaos Environment +## Chaos environment -An environment represents where you are installing your Chaos Infrastructure and acts as an additional level of abstraction for the same. You categorize each environment as prod or non-prod. +An environment represents where you are installing your chaos infrastructure and acts as an additional level of abstraction for the same. You categorize each environment as prod or non-prod. -### Access Types +### Access types -Chaos Infrastructure can be created in two modes: +Chaos infrastructure can be created in two modes: -
  • Cluster Wide: This mode of infrastructure installation allows targeting resources across the entire cluster, in all the namespaces, as part of an experiment.
    • -
  • Namespace Mode: This mode of infrastructure installation allows targeting resources only in the namespace where the chaos infrastructure is deployed.
    • - -

    +- **Cluster Wide:** This mode of infrastructure installation allows targeting resources across the entire cluster, in all the namespaces, as part of an experiment. +- **Namespace Mode:** This mode of infrastructure installation allows targeting resources only in the namespace where the chaos infrastructure is deployed. :::note - -
  • There can only be one cluster-wide chaos infrastructure per cluster.
    • -
  • There may be multiple namespace-scoped chaos infrastructures per cluster.
    • +- There can only be one cluster-wide chaos infrastructure per cluster. +- There may be multiple namespace-scoped chaos infrastructures per cluster. ::: -## Learn More +## Learn more - [How to connect a Chaos Infrastructure](../user-guides/chaos-infrastructure-installation.md) diff --git a/website/docs/concepts/oauth-dex-concept.md b/website/docs/concepts/oauth-dex-concept.md index b40be005..0ac2cd33 100644 --- a/website/docs/concepts/oauth-dex-concept.md +++ b/website/docs/concepts/oauth-dex-concept.md @@ -1,6 +1,6 @@ --- id: oauth-dex-concept -title: Authentication process in ChaosCenter +title: Authentication in ChaosCenter sidebar_label: Authentication in ChaosCenter --- @@ -13,7 +13,7 @@ sidebar_label: Authentication in ChaosCenter ChaosCenter allows OAuth as well as local authentication using Dex and the authentication server. -## Authentication Architecture +## Authentication architecture

    @@ -23,11 +23,11 @@ Litmus portal uses two components for authentication of users: - Authentication Server - Dex OIDC Server (Optional) -By default litmus-portal comes with then authentication server as part of the `litmusportal-server` deployment and it allows local authentication that is based of mongo database. Client services such as `litmus-ctl` and `litmusportal-frontend` make use of this server. +By default litmus-portal comes with then authentication server as part of the **litmusportal-server** deployment and it allows local authentication that is based of mongo database. Client services such as **litmusctl** and **litmusportal-frontend** make use of this server. In order to provide enhanced and seamless login features, we wanted to integrate OAuth and other authentication mechanisms such as OpenID connect. To have flexibility, litmus-portal makes use of an additional component, [Dex OIDC server](https://dexidp.io/). -Dex is a highly extensible cloud-native OIDC provider that is able to take care of various authentication mechanisms. With Dex being deployed, the authentication-server can communicate with the dex-server, enabling integration of various OAuth providers. GitHub and Google auth has been tested at present. +Dex is a highly extensible cloud-native OIDC provider that is able to take care of various authentication mechanisms. With Dex being deployed, the authentication-server can communicate with the dex-server which enables the integration of various OAuth providers. GitHub and Google auth has been tested at present. ## Resources diff --git a/website/docs/concepts/probes.md b/website/docs/concepts/probes.md index c28b22b5..0b37d464 100644 --- a/website/docs/concepts/probes.md +++ b/website/docs/concepts/probes.md @@ -50,11 +50,11 @@ If probe needs any additional RBAC permissions other than the fault's serviceAcc ### httpProbe -The `httpProbe` allows developers to specify a URL which the fault uses to gauge health/service availability (or other custom conditions) as part of the entry/exit criteria. The received status code is mapped against an expected status. It supports http `Get` and `Post` methods. +The `httpProbe` allows developers to specify a URL which the fault uses to gauge health/service availability (or other custom conditions) as part of the entry/exit criteria. The received status code is mapped against an expected status. It supports HTTP `Get` and `Post` methods. -In HTTP `Get` method it sends a http `GET` request to the provided url and matches the response code based on the given criteria(`==`, `!=`, `oneOf`). +In HTTP `Get` method, it sends an HTTP `GET` request to the provided URL and matches the response code based on the given criteria (`==`, `!=`, `oneOf`). -In HTTP `Post` method it sends a http `POST` request to the provided url. The http body can be provided in the `body` field. In the case of a complex POST request in which the body spans multiple lines, the `bodyPath` attribute can be used to provide the path to a file consisting of the same. This file can be made available to the fault pod via a ConfigMap resource, with the ConfigMap name being defined in the [ChaosEngine](glossary.md) OR the ChaosExperiment CR. +In HTTP `Post` method, it sends an HTTP `POST` request to the provided URL. The http body can be provided in the `body` field. In the case of a complex POST request in which the body spans multiple lines, the `bodyPath` attribute can be used to provide the path to a file consisting of the same. This file can be made available to the fault pod via a ConfigMap resource, with the ConfigMap name being defined in the [ChaosEngine](glossary.md) OR the ChaosExperiment CR. It can be defined at `.spec.experiments[].spec.probe` inside ChaosEngine. > `body` and `bodyPath` are mutually exclusive diff --git a/website/docs/concepts/projects.md b/website/docs/concepts/projects.md index 18bd1d2f..548cb9b7 100644 --- a/website/docs/concepts/projects.md +++ b/website/docs/concepts/projects.md @@ -10,7 +10,7 @@ The ChaosCenter comes with a project management system that can be used for work ## Prerequisites -Before learning about the concept of `projects`, it is important to note that a `project` signifies a separation between Chaos infrastructures, Schedules, [Visualization](visualize-experiment.md), and Teams (discussed in the next section) configurations, and prior knowledge of these will prove fruitful in understanding the concept of `projects` in-depth. +Before learning about the concept of projects, it is important to note that a project signifies a separation between Chaos infrastructures, Schedules, [Visualization](visualize-experiment.md), and Teams (discussed in the next section) configurations, and prior knowledge of these will prove fruitful in understanding the concept of projects in-depth. ## Projects diff --git a/website/docs/concepts/teaming.md b/website/docs/concepts/teaming.md index 2ab89eab..b684ca80 100644 --- a/website/docs/concepts/teaming.md +++ b/website/docs/concepts/teaming.md @@ -1,6 +1,6 @@ --- id: teaming -title: Collaborate with Teams +title: Collaborate with teams sidebar_label: Teaming --- @@ -8,7 +8,7 @@ sidebar_label: Teaming The ChaosCenter has a built in teaming feature to facilitate collaboration between users using project level role access, the core concepts of which are discussed below. -## Project level roles (Owner, Editor, Viewer) +## Project level roles Each user has a default project created on user creation by the admin for which they maintain a project level `Owner` access. Every `Owner` has the ability to invite other users into their project with different permission levels, namely `Editor`, and `Viewer`. diff --git a/website/docs/concepts/user-management.md b/website/docs/concepts/user-management.md index b4146745..f339c178 100644 --- a/website/docs/concepts/user-management.md +++ b/website/docs/concepts/user-management.md @@ -1,28 +1,28 @@ --- id: user-management -title: User Management -sidebar_label: User Management +title: User management +sidebar_label: User management --- --- -The ChaosCenter supports two different levels of hierarchy, a portal level access, and a project level access. +The ChaosCenter supports two different levels of hierarchy, a portal level access and a project level access. -> This section discusses the detailed breakdown of the portal level roles a user may have. For project level roles refer [here](teaming.md). +> This section discusses the detailed breakdown of the portal level roles a user may have. For project level roles, refer [here](teaming.md). -## Portal level user Roles (Admin, Non-Admins) +## Portal level user roles ChaosCenter supports two portal level roles for defining the privilege levels of a certain user: -**Admin:** the admin user is created by default on initial project setup and can log into the portal using the credentials `admin/litmus` once the server pod (auth container) is up. +**Admin:** The admin user is created by default upon setup and can be used for logging in to the ChaosCenter using the credentials once the server pod (auth container) is up. -**Non-admin users:** The admin of the portal has the exclusive ability to create any number of non-admin users. +**Non-admin users:** The admin of the ChaosCenter can exclusively create any number of non-admin users. -## Role Privileges +## Role privileges -**Admin** is the highest privilege level offered in the portal and the admin has complete access to all the features offered by the portal. +**Admin:** It is the highest privilege role offered in the ChaosCenter which provides complete access to all the features. -**Non-admin users:** Non-admin users get all the same privileges as an admin-level user, with the exception of the user management feature which is an admin-exclusive feature to facilitate an admin to manage their teams on the portal. (Example: In an organization, multiple different teams might be formed to inject chaos into different chaos infrastructures that have no layover between each other.) +**Non-admin users:** Non-admin users get all the same privileges as an admin-level user, with the exception of the user management feature which is an admin-exclusive feature to facilitate an admin to manage their teams on the ChaosCenter. For example, in an organization there can be different teams who'd utilize different chaos infrastructures that have no layover between each other. ## Learn more diff --git a/website/docs/concepts/visualize-experiment.md b/website/docs/concepts/visualize-experiment.md index d0129178..be2c02fe 100644 --- a/website/docs/concepts/visualize-experiment.md +++ b/website/docs/concepts/visualize-experiment.md @@ -1,32 +1,31 @@ --- id: visualize-experiment -title: Visualize the Chaos Experiment Execution -sidebar_label: Visualize Chaos Experiment +title: Visualize chaos experiment +sidebar_label: Visualize chaos experiment --- --- -Visualization is an important aspect while doing chaos engineering. It allows the user to discover and inspect different changes that occur during a Chaos Experiment execution.
    -With ChaosCenter, the real-time data and status of the chaos experiments can be observed. Valuable information like pod logs, chaos experiment status, and chaos results can also be viewed. +Visualization is an important aspect while doing chaos engineering. It allows the user to discover and inspect different changes that occur during a Chaos Experiment execution. With ChaosCenter, the real-time data and status of the chaos experiments can be observed. Valuable information like pod logs, chaos experiment status, and chaos results can also be viewed. ## Prerequisites -The following should be required before creating a Chaos Experiment: +The following is required before visualizing a chaos experiment: - ChaosCenter - [Chaos Experiments](chaos-workflow.md) -## Litmus Chaos Experiment +## Create chaos experiment -If the user chooses to 'Save' and 'Run' the experiment, they will be redirected directly to the experiment execution page where the experiment can be visualised else they will be taken Chaos Experiment Page. +If the user chooses to **Save** and **Run** the experiment, they will be directed to the experiment execution page, where the experiment can be visualized. Otherwise, they will be taken to the chaos experiment page. -## Visualize a Litmus Chaos Experiment +## Visualize chaos experiment -To observe a chaos experiment, user needs to select the highlighted experiment run box from the heatmap, it will redirect to experiment run execution page.
    +To observe a chaos experiment, user needs to select the highlighted experiment run box from the heatmap, it will redirect to experiment run execution page. -In the chaos experiment, a realtime graph of the chaos experiment is displayed. This graph contains valuable information regarding the status of individual steps of the chaos experiment.

    -

    +In the chaos experiment, a realtime graph of the chaos experiment is displayed. This graph contains valuable information regarding the status of individual steps of the chaos experiment. + To view the details of each step, the user can click on the individual nodes and the right side pane will display the node details, results(once the execution is complete), and the logs related to it.

    diff --git a/website/docs/getting-started/installation.md b/website/docs/getting-started/installation.md index 98596bf6..6707764d 100644 --- a/website/docs/getting-started/installation.md +++ b/website/docs/getting-started/installation.md @@ -1,6 +1,6 @@ --- id: installation -title: ChaosCenter Cluster Scope Installation +title: ChaosCenter cluster scope installation sidebar_label: Installation --- @@ -8,15 +8,13 @@ sidebar_label: Installation ## Prerequisites -Before deploying LitmusChaos, make sure the following items are there - - Kubernetes 1.17 or later - A Persistent volume of 20GB - :::note - 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 install would use the default storage class to allocate the PV. Provide this value - ::: +:::note +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 install would use the default storage class to allocate the PV. Provide this value +::: - [Helm3](https://v3.helm.sh/) or [kubectl](https://kubernetes.io/docs/tasks/tools/#kubectl) diff --git a/website/docs/getting-started/resources.md b/website/docs/getting-started/resources.md index 3896c0f8..4a686853 100644 --- a/website/docs/getting-started/resources.md +++ b/website/docs/getting-started/resources.md @@ -7,51 +7,33 @@ sidebar_label: Resources --- ## ChaosCenter +ChaosCenter is a unified pane that controls all the functions provided by Litmus. It can be used for managing the entire lifecycle of the chaos experiments, including all the components within. -ChaosCenter is a single source of truth to control all the functions provided by Litmus. From ChaosCenter, you get the freedom to manage every single part of Litmus and shape your chaos experiments exactly the way you want it. - -**ChaosCenter comes pre-packaged** as a part of LitmusChaos installation and can be easily accessed via [Ingress](../user-guides/setup-with-ingress.md), [NodePort](../user-guides/setup-without-ingress.md#with-nodeport) or [LoadBalancer](../user-guides/setup-without-ingress.md#with-loadbalancer). Since Litmus has Cross-Cloud support, you get seamless access to the ChaosCenter irrespectively of where you deploy it. - -> [Get a broader view of which Platforms are supported by Litmus](https://github.com/litmuschaos/litmus/tree/master/litmus-portal#platforms-support) +ChaosCenter comes pre-packaged as a part of LitmusChaos installation and can be easily accessed via [Ingress](../user-guides/setup-with-ingress.md), [NodePort](../user-guides/setup-without-ingress.md#with-nodeport) or [LoadBalancer](../user-guides/setup-without-ingress.md#with-loadbalancer). Since Litmus has Cross-Cloud support, you get seamless access to the ChaosCenter irrespectively of where you deploy it. ChaosCenter gives you access to a plethora of features, the major ones include: -- Chaos Experiment Creation - -
      -
    • From Templates, Custom Chaos Experiments from Scratch (using ChaosHubs), From pre-created YAMLs
      • -
    • Chaos Experiments Sequence Control (Parallel as well as Sequential steps creation)
      • -
    • Creation of either Singular or Cron Chaos Experiments as Schedules
      • -
    • Attaching priority to Chaos Experiments based on your use cases
      • -
    -     -- Users & Teams - -
      -
    • Creation of Users with Role Based Access Control
      • -
    • Creating a Team of multiple Users
      • -
    • Authenticating Users
      • -
    -     -- Chaos Experiment Management - -
      -
    • Rolling out automated changes using GitOps
      • -
    • Allowing image addition from custom image server (both public and private)
      • -
    • Measure and Analyze the Resilience Score of each chaos scenario
      • -
    -     +- **Chaos experiment creation** + - From templates, custom experiments from scratch (using ChaosHubs), from pre-created YAMLs + - Experiments sequence control (parallel as well as sequential steps creation) + - Creation of either singular or cron experiments as schedules + - Attaching priority to experiments based on your use cases +- **Users and teams** + - Creation of users with Role Based Access Control + - Creating a team of multiple users + - Authenticating users +- **Chaos experiment management** + - Rolling out automated changes using GitOps + - Allowing image addition from custom image server (both public and private) + - Measure and analyze the Resilience Score of each chaos scenario ## Chaos Infrastructures -Chaos infrastructure is a service that runs in your target environment and aids Litmus in accessing and injecting chaos to your target environment. There should always be at least one or more than one chaos infrastructure connected to the ChaosCenter. +Chaos infrastructure is a service that runs in your target environment and aids Litmus in accessing and injecting chaos to your target environment. There should always be at least one or more than one chaos infrastructure connected to the ChaosCenter to execute an experiment. ## Types of Chaos Infrastructures -In Litmus, chaos infrastructures can be classified into two types - -- Self Chaos Infrastructures -- External Chaos Infrastructures +In Litmus, chaos infrastructures can be classified into two types: -As part of the Litmus installation, a Self Chaos Infrastructure would be registered as a default Chaos Infrastructure in the ChaosCenter. The same cluster where Litmus is installed is chosen as the Self Chaos Infrastructure by the installer. From the ChaosCenter you can now induce chaos into this Self Chaos Infrastructure and observe the results. +- **Self Chaos Infrastructures:** A Chaos Infrastructure that is connected to the same cluster and namespace where the ChaosCenter is deployed. It can be used to target the workloads executing on that cluster only. -Since the ChaosCenter is Cross Cloud, you can connect multiple External Chaos Infrastructure to the same ChaosCenter with the help of the command line utility [litmusctl](../litmusctl/installation.md). Once connected you can manage, monitor, observe and induce chaos from the ChaosCenter to the respective Chaos Infrastructures. +- **External Chaos Infrastructures:** A Chaos Infrastructure that is connected to a remote Kubernetes cluster. ChaosCenter can be operated in a cross-cloud manner, which allows connecting multiple External Chaos Infrastructure to the same ChaosCenter with the help of the [litmusctl](../litmusctl/installation.md) CLI. Once connected you can manage, monitor, observe and induce chaos from the ChaosCenter to the respective External Chaos Infrastructures. diff --git a/website/versioned_docs/version-3.0.0/architecture/architecture-summary.md b/website/versioned_docs/version-3.0.0/architecture/architecture-summary.md index 670571ac..76db8e86 100644 --- a/website/versioned_docs/version-3.0.0/architecture/architecture-summary.md +++ b/website/versioned_docs/version-3.0.0/architecture/architecture-summary.md @@ -1,7 +1,7 @@ --- id: architecture-summary -title: Architecture Summary -sidebar_label: Architecture Summary +title: Architecture summary +sidebar_label: Architecture summary --- --- @@ -10,16 +10,19 @@ sidebar_label: Architecture Summary The Litmus architecture can be segregated into two parts: -1. **Control Plane:** Contains the components required for the functioning of ChaosCenter, the website-based portal for Litmus. +1. **Control plane:** Contains the components required for the functioning of ChaosCenter, the website-based portal for Litmus. -2. **Execution Plane:** Contains the components required for the injection of chaos in the target resources. +2. **Execution plane:** Contains the components required for the injection of chaos in the target resources. -ChaosCenter can be used for creating and scheduling Chaos Experiments, a set of chaos faults defined in a definitive sequence to achieve desired chaos impact on the target resources upon execution. Users can log in to the ChaosCenter using valid login credentials and leverage the interactive web UI to define their chaos experiment to target multiple aspects of their infrastructure. Once the user creates a Chaos Experiment using the ChaosCenter, it is passed on to the Execution Plane. The Execution Plane can be present either in the host cluster containing the Control Plane if the self chaos infrastructure is being used, or in the target cluster if an external chaos infrastructure is being used. The Execution Plane interprets the Chaos Experiment as a list of steps required for injecting chaos into the target resources. It ensures efficient orchestration of chaos in cloud-native environments using various Kubernetes CRs. Once the Chaos Experiment is executed, Execution Plane sends the chaos result to the Control Plane for their post-processing using either the built-in monitoring dashboard of Litmus or using external observability tools such as Prometheus DB and Grafana dashboard. Litmus also achieves automated Chaos Experiment runs to execute chaos as part of the CI/CD pipeline based on a set of defined conditions using GitOps. +- Control plane can be used for creating and scheduling chaos experiments, which is a set of chaos faults defined in a definitive sequence to achieve desired chaos impact on the target resources upon execution. Users can log in to the ChaosCenter using the web UI or the APIs to define a chaos experiment and assess the resilience of target workloads. + +- Once the user creates a chaos experiment using the ChaosCenter, it is passed on to the execution plane. The Execution plane can be present either in the same cluster as the ChaosCenter if the self chaos infrastructure is being used, or in a remote cluster if an external chaos infrastructure is being used. The Execution plane interprets the chaos experiment as a list of actions that will inject chaos into the target workloads. It ensures efficient orchestration of chaos in various cloud-native environments using Kubernetes custom resources. + +- Once the chaos experiment is executed, Execution plane sends the chaos result to the control plane for their post-processing using either the built-in monitoring dashboard of Litmus or using external observability tools such as Prometheus DB and Grafana dashboard. Litmus also achieves automated chaos experiment runs to execute chaos as part of the CI/CD pipeline based on a set of defined conditions using GitOps. :::note With the latest release of LitmusChaos 3.0.0: - -
  • The term Chaos Delegate/Agent has been changed to Chaos Infrastructure.
    • -
  • The term Chaos Experiment has been changed to Chaos Fault.
    • -
  • The term Chaos Scenario/Workflow has been changed to Chaos Experiment.
    • +- The term **Chaos Delegate/Agent** has been changed to **Chaos Infrastructure**. +- The term **Chaos Experiment** has been changed to **Chaos Fault**. +- The term **Chaos Scenario/Workflow** has been changed to **Chaos Experiment**. ::: diff --git a/website/versioned_docs/version-3.0.0/architecture/chaos-control-plane.md b/website/versioned_docs/version-3.0.0/architecture/chaos-control-plane.md index 2bdd3fbb..84e44821 100644 --- a/website/versioned_docs/version-3.0.0/architecture/chaos-control-plane.md +++ b/website/versioned_docs/version-3.0.0/architecture/chaos-control-plane.md @@ -1,16 +1,16 @@ --- id: chaos-control-plane -title: Chaos Control Plane -sidebar_label: Chaos Control Plane +title: Chaos control plane +sidebar_label: Chaos control plane --- --- Chaos Control Plane -Chaos Control Plane consists of micro-services responsible for the functioning of the ChaosCenter, the website-based portal that can be used for interacting with Litmus, apart from the CLI. Chaos Plane facilitates the creation and scheduling of chaos experiments, system observability during the event of chaos, and post-processing and analysis of fault results. +Chaos control plane consists of micro-services responsible for the functioning of the ChaosCenter, the website-based portal that can be used for interacting with Litmus, apart from the CLI. Chaos Plane facilitates the creation and scheduling of chaos experiments, system observability during the event of chaos, and post-processing and analysis of fault results. -## Chaos Control Plane Components +## Chaos control plane components - **Authentication Server:** A Golang micro-service that is responsible for authorizing, authenticating the requests received from ChaosCenter and managing users along with their projects. It primarily serves the cause of user creation, user login, resetting the password, updating user information, creating project, managing project related operations. diff --git a/website/versioned_docs/version-3.0.0/architecture/chaos-execution-plane.md b/website/versioned_docs/version-3.0.0/architecture/chaos-execution-plane.md index fc3010fe..b870ee8a 100644 --- a/website/versioned_docs/version-3.0.0/architecture/chaos-execution-plane.md +++ b/website/versioned_docs/version-3.0.0/architecture/chaos-execution-plane.md @@ -1,7 +1,7 @@ --- id: chaos-execution-plane -title: Chaos Execution Plane -sidebar_label: Chaos Execution Plane +title: Chaos execution plane +sidebar_label: Chaos execution plane --- --- @@ -65,8 +65,7 @@ It is worth noticing that: :::note With the latest release of LitmusChaos 3.0.0: - -
  • The term Chaos Delegate/Agent has been changed to Chaos Infrastructure.
    • -
  • The term Chaos Experiment has been changed to Chaos Fault.
    • -
  • The term Chaos Experiment/Workflow has been changed to Chaos Experiment.
    • +- The term **Chaos Delegate/Agent** has been changed to **Chaos Infrastructure**. +- The term **Chaos Experiment** has been changed to **Chaos Fault**. +- The term **Chaos Scenario/Workflow** has been changed to **Chaos Experiment**. ::: diff --git a/website/versioned_docs/version-3.0.0/architecture/chaos-experiment-flow.md b/website/versioned_docs/version-3.0.0/architecture/chaos-experiment-flow.md index 18829215..62437069 100644 --- a/website/versioned_docs/version-3.0.0/architecture/chaos-experiment-flow.md +++ b/website/versioned_docs/version-3.0.0/architecture/chaos-experiment-flow.md @@ -1,7 +1,7 @@ --- id: chaos-fault-flow -title: Chaos Fault Flow -sidebar_label: Chaos Fault Flow +title: Chaos fault flow +sidebar_label: Chaos fault flow --- --- @@ -31,7 +31,7 @@ The fault execution is triggered upon the creation of a ChaosEngine resource. Th :::note With the latest release of LitmusChaos 3.0.0: - -
  • The term Chaos Experiment has been changed to Chaos Fault.
    • -
  • The term Chaos Experiment/Workflow has been changed to Chaos Experiment.
    • +- The term **Chaos Delegate/Agent** has been changed to **Chaos Infrastructure**. +- The term **Chaos Experiment** has been changed to **Chaos Fault**. +- The term **Chaos Scenario/Workflow** has been changed to **Chaos Experiment**. ::: diff --git a/website/versioned_docs/version-3.0.0/concepts/chaos-workflow.md b/website/versioned_docs/version-3.0.0/concepts/chaos-workflow.md index c2c69abb..824590e6 100644 --- a/website/versioned_docs/version-3.0.0/concepts/chaos-workflow.md +++ b/website/versioned_docs/version-3.0.0/concepts/chaos-workflow.md @@ -1,20 +1,23 @@ --- id: chaos-workflow -title: Chaos Experiment -sidebar_label: Chaos Experiment +title: Chaos experiment +sidebar_label: Chaos experiment --- --- -**Chaos Experiment** is a set of different operations coupled together to achieve desired chaos impact on a Kubernetes Cluster.
    -It is useful in automating a series of pre-conditioning steps or action which is necessary to be performed before triggering the chaos injection.
    -A Chaos Experiment can also be used to perform different operations parallelly to achieve a desired chaos impact. +Chaos experiments gives you the flexibility to create complex, real-life failure scenarios that are used to validate your target workloads. At the same time, chaos experiments are declarative and can be constructed using the ChaosCenter UI without any programmatic intervention. + +A chaos experiment is composed of chaos faults that are arranged in a specific order to create a failure scenario. The chaos faults target various aspects of an application, including the constituent microservices and underlying infrastructure. You can tune the parameters associated with these faults to impart the desired chaos behavior. + +- It is useful in automating a series of pre-conditioning steps or action which is necessary to be performed before triggering the chaos injection. + +- A Chaos Experiment can also be used to perform different operations parallelly to achieve a desired chaos impact. :::note 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.
    • +The term **Chaos Experiment** has been changed to **Chaos Fault**. +The term **Chaos Scenario/Workflow** has been changed to **Chaos Experiment**. ::: ## Prerequisites @@ -25,12 +28,13 @@ The following should be required before creating a Chaos Experiment: - [Chaos Infrastructure](../getting-started/resources.md#chaosagents) - [Probes](probes.md) -## How do we define and execute a Chaos Experiment ? +## Defining and executing a chaos experiment + +LitmusChaos leverages the popular GitOps tool **Argo** to achieve this goal. Argo enables the creation of different chaos experiments together in form of chaos experiments which are extremely simple and efficient to use. -LitmusChaos leverages the popular GitOps tool **Argo** to achieve this goal. Argo enables the creation of different chaos experiments together in form of chaos experiments which are extremely simple and efficient to use.
    With the help of **ChaosCenter**, chaos experiments with different types of faults can be created. In a Chaos Experiment, the faults can be set to execute in parallel to each other and the user can tune the chaos experiment by adding additional steps to simulate a desired fault that might occur in the production stage. -### Life Cycle of a Chaos Experiment +### Chaos experiment life cycle Here is a sample pod-delete chaos experiment from ChaosCenter. @@ -232,11 +236,11 @@ These include installing the chaos faults, executing the chaos engine of the fau Some additional checks can be added with the faults in the form of probes. These probes are defined in the ChaosEngines of the faults and are updated when the fault execution takes place. The overall chaos experiment result can be viewed with the ChaosResult CRD which contains the `verdict` and the `probeSuccessPercentage` (a ratio of successful checks v/s total probes). -## What is a run? +## Chaos experiment run A chaos experiment run can be defined as a single/one-time execution of the chaos experiment. There can be multiple runs of a single chaos experiment. If the chaos experiment consists of a cron syntax, it will run periodically according to the cron provided in the chaos experiment. -## What is Resilience Score? +## Resilience Score **Resiliency score** is an overall measure of the resiliency of a system for a given chaos experiment, which is obtained upon executing the constituent experiment faults on that system. @@ -255,7 +259,7 @@ Total Resilience for one single fault = (Weight Given to that fault * Probe Succ Overall Resilience Score = Total Test Result / Sum of the assigned weights of the faults ``` -## What is a Cron Chaos Experiment? +## Cron chaos experiment Cron Chaos Experiment is a type of chaos experiment that runs on a pre-defined schedule. It consists of a mandatory field `spec.schedule`. A cron syntax is provided in this field at which the chaos experiment execution takes place. diff --git a/website/versioned_docs/version-3.0.0/concepts/chaoshub.md b/website/versioned_docs/version-3.0.0/concepts/chaoshub.md index 66351540..15ccac93 100644 --- a/website/versioned_docs/version-3.0.0/concepts/chaoshub.md +++ b/website/versioned_docs/version-3.0.0/concepts/chaoshub.md @@ -6,7 +6,11 @@ sidebar_label: ChaosHub --- -ChaosHub allows you to orchestrate chaos experiments from the Public **[ChaosHub](http://hub.litmuschaos.io/)** or an alternate source for the Experiments (basically, a **[fork](https://github.com/litmuschaos/chaos-charts)** of the public hub with custom faults). +A ChaosHub is a collection of experiment templates and faults that you can use to create and launch chaos experiments. Both experiments and faults are stored as manifests in an appropriate directory structure. This way, new experiment templates and faults can be added directly to the repository as files. In addition, the experiment templates can be derived from the existing experiments to be saved in ChaosHub from the web UI. + +- ChaosHub is accessed using a Git service provider such as GitHub, where ChaosHub exists as a repository. This allows native version control and management of the faults and experiment artifacts. + +- Chaos experiments can be created from the public [ChaosHub](http://hub.litmuschaos.io/) which is already connected to your ChaosCenter, or a custom ChaosHub which is a [fork](https://github.com/litmuschaos/chaos-charts) of the public ChaosHub where custom faults can be stored. ## Prerequisites @@ -18,37 +22,37 @@ The following are the prerequisites for creating a Chaos Experiment: An active internet connection is required to clone the git repository for the first time installation. ::: -## Connecting a Git repository using ChaosHub +## Connecting to a Git repository using ChaosHub With ChaosHub, you can construct chaos experiments by selecting, tuning and sequencing different faults together from their connected ChaosHubs. You can make changes in your forked repositories and sync it with the Portal to get the latest changes from the fork. -By default, a Public ChaosHub is provided when the ChaosCenter is installed for the first time. +By default, a public ChaosHub is provided when the ChaosCenter is installed for the first time. -### 1. Connect a Public Git Repository +### 1. Connect a public Git repository You can connect to a public Git repository by simply providing the following details: -- Hub Name +- Hub name - Git URL of the forked repository -- Branch Name +- Branch name -### 2. Connect a Private Git Repository +### 2. Connect a private Git repository -To add a Private Hub, you need provide the Hub name, Git URL of the forked repository and the Branch name similar to that of Public Hub and the repository can be connected by 2 methods: +To add a private ChaosHub, you need provide the hub name, Git URL of the forked repository and the branch name similar to that of public hub and the repository can be connected in two ways: -#### a. Access Token +#### a. Access token Personal Access Tokens are used as an alternative to the password for authentication to Git services. -#### b. SSH Key +#### b. SSH key Just like the Access Token , SSH keys are used for the authentication. These keys come in pairs, a public key that is shared with the Git Services and a private key that is stored with you. SSH link of the repository should be provided if you select this method. @@ -57,13 +61,13 @@ SSH link of the repository should be provided if you select this method. ## Syncing a ChaosHub -If some changes are made into the git repository, you can reflect these changes in the hub by selecting the **Refresh Hub** option from the ChaosHub card. +If some changes are made into the Git repository, you can reflect these changes in the hub by selecting the **Refresh Hub** option from the ChaosHub card. ## Editing a ChaosHub To make changes in a hub like changing the name, branch, access token etc, you can select the **Edit Hub** option from the ChaosHub card. -## Chaos Experiments and Experiments in a ChaosHub +## Chaos experiments and experiments in a ChaosHub ### 1. View the PreDefined Chaos Experiments @@ -73,16 +77,16 @@ After connecting a ChaosHub, you can view the different pre-defined chaos experi ### 2. View the Chaos Faults -Similarly, you can view the different charts and the fault. These charts are sorted according to different categories like generic, aws, azure, kube-components etc. +Similarly, you can view the different charts and the fault. These charts are sorted according to different categories like generic, AWS, Azure, Kube-Components etc. ### 3. View the fault details -You can select one of the chaos faults and can examine the fault details. -The fault page consists of all the important details like the description of the fault, a tutorial video, the maintainer of the fault, etc. -You can also find the fault yaml link, RBAC link, and the ChaosEngine yaml link of the fault. -These yaml links are required for the creation of Custom Chaos Experiments. +You can select one of the chaos faults and can examine the fault details. The fault page consists of all the important details like the description of the fault, a tutorial video, the maintainer of the fault, etc. + +You can also find the Experiment manifest URL, RBAC URL, and the ChaosEngine URLs of the fault. +These URLs are required for the creation of custom chaos experiments. @@ -92,10 +96,9 @@ To remove a ChaosHub from a project, you can select the **Disconnect Hub** optio ## Summary -You can select one of the chaos faults and can examine the fault details. -The fault page consists of all the important details like the description of the fault, a tutorial video, the maintainer of the fault, etc. -You can also find the fault yaml link, RBAC link, and the ChaosEngine yaml link of the fault. -These yaml links are required for the creation of Custom Chaos Experiments. +You can select one of the chaos faults and can examine the fault details.The fault page consists of all the important details like the description of the fault, a tutorial video, the maintainer of the fault, etc. +You can also find the Experiment URL URL, RBAC URL, and the ChaosEngine yaml URL of the fault. +These yaml URLs are required for the creation of Custom Chaos Experiments. ## Learn More diff --git a/website/versioned_docs/version-3.0.0/concepts/infrastructure.md b/website/versioned_docs/version-3.0.0/concepts/infrastructure.md index c48381db..32f743d1 100644 --- a/website/versioned_docs/version-3.0.0/concepts/infrastructure.md +++ b/website/versioned_docs/version-3.0.0/concepts/infrastructure.md @@ -1,34 +1,31 @@ --- id: chaos-infrastructure -title: Chaos Infrastructure -sidebar_label: Chaos Infrastructure +title: Chaos infrastructure +sidebar_label: Chaos infrastructure --- -Chaos infrastructure is a service that runs in your target environment and aids the Litmus control plane in accessing and injecting chaos at a cloud-native scale. All the chaos infrastructure services adhere to the principle of least privilege, where the services execute with the minimum number of required permissions. A Chaos Infrastructure can be created under a Chaos Environment. +Chaos infrastructure is a service that runs in your target environment and aids the Litmus control plane in accessing and injecting chaos at a cloud-native scale. All the chaos infrastructure services adhere to the principle of least privilege, where the services execute with the minimum number of required permissions. A chaos infrastructure can be created under a Chaos Environment. :::note -With the latest release of LitmusChaos 3.0.0 the term **Chaos Delegate/Agent** has been changed to **Chaos Infrastructure** +With the latest release of LitmusChaos 3.0.0 the term **Chaos Delegate/Agent** has been changed to **Chaos Infrastructure**. ::: -## Chaos Environment +## Chaos environment -An environment represents where you are installing your Chaos Infrastructure and acts as an additional level of abstraction for the same. You categorize each environment as prod or non-prod. +An environment represents where you are installing your chaos infrastructure and acts as an additional level of abstraction for the same. You categorize each environment as prod or non-prod. -### Access Types +### Access types -Chaos Infrastructure can be created in two modes: +Chaos infrastructure can be created in two modes: -
  • Cluster Wide: This mode of infrastructure installation allows targeting resources across the entire cluster, in all the namespaces, as part of an experiment.
    • -
  • Namespace Mode: This mode of infrastructure installation allows targeting resources only in the namespace where the chaos infrastructure is deployed.
    • - -

    +- **Cluster Wide:** This mode of infrastructure installation allows targeting resources across the entire cluster, in all the namespaces, as part of an experiment. +- **Namespace Mode:** This mode of infrastructure installation allows targeting resources only in the namespace where the chaos infrastructure is deployed. :::note - -
  • There can only be one cluster-wide chaos infrastructure per cluster.
    • -
  • There may be multiple namespace-scoped chaos infrastructures per cluster.
    • +- There can only be one cluster-wide chaos infrastructure per cluster. +- There may be multiple namespace-scoped chaos infrastructures per cluster. ::: -## Learn More +## Learn more - [How to connect a Chaos Infrastructure](../user-guides/chaos-infrastructure-installation.md) diff --git a/website/versioned_docs/version-3.0.0/concepts/oauth-dex-concept.md b/website/versioned_docs/version-3.0.0/concepts/oauth-dex-concept.md index b40be005..0ac2cd33 100644 --- a/website/versioned_docs/version-3.0.0/concepts/oauth-dex-concept.md +++ b/website/versioned_docs/version-3.0.0/concepts/oauth-dex-concept.md @@ -1,6 +1,6 @@ --- id: oauth-dex-concept -title: Authentication process in ChaosCenter +title: Authentication in ChaosCenter sidebar_label: Authentication in ChaosCenter --- @@ -13,7 +13,7 @@ sidebar_label: Authentication in ChaosCenter ChaosCenter allows OAuth as well as local authentication using Dex and the authentication server. -## Authentication Architecture +## Authentication architecture

    @@ -23,11 +23,11 @@ Litmus portal uses two components for authentication of users: - Authentication Server - Dex OIDC Server (Optional) -By default litmus-portal comes with then authentication server as part of the `litmusportal-server` deployment and it allows local authentication that is based of mongo database. Client services such as `litmus-ctl` and `litmusportal-frontend` make use of this server. +By default litmus-portal comes with then authentication server as part of the **litmusportal-server** deployment and it allows local authentication that is based of mongo database. Client services such as **litmusctl** and **litmusportal-frontend** make use of this server. In order to provide enhanced and seamless login features, we wanted to integrate OAuth and other authentication mechanisms such as OpenID connect. To have flexibility, litmus-portal makes use of an additional component, [Dex OIDC server](https://dexidp.io/). -Dex is a highly extensible cloud-native OIDC provider that is able to take care of various authentication mechanisms. With Dex being deployed, the authentication-server can communicate with the dex-server, enabling integration of various OAuth providers. GitHub and Google auth has been tested at present. +Dex is a highly extensible cloud-native OIDC provider that is able to take care of various authentication mechanisms. With Dex being deployed, the authentication-server can communicate with the dex-server which enables the integration of various OAuth providers. GitHub and Google auth has been tested at present. ## Resources diff --git a/website/versioned_docs/version-3.0.0/concepts/probes.md b/website/versioned_docs/version-3.0.0/concepts/probes.md index c28b22b5..0b37d464 100644 --- a/website/versioned_docs/version-3.0.0/concepts/probes.md +++ b/website/versioned_docs/version-3.0.0/concepts/probes.md @@ -50,11 +50,11 @@ If probe needs any additional RBAC permissions other than the fault's serviceAcc ### httpProbe -The `httpProbe` allows developers to specify a URL which the fault uses to gauge health/service availability (or other custom conditions) as part of the entry/exit criteria. The received status code is mapped against an expected status. It supports http `Get` and `Post` methods. +The `httpProbe` allows developers to specify a URL which the fault uses to gauge health/service availability (or other custom conditions) as part of the entry/exit criteria. The received status code is mapped against an expected status. It supports HTTP `Get` and `Post` methods. -In HTTP `Get` method it sends a http `GET` request to the provided url and matches the response code based on the given criteria(`==`, `!=`, `oneOf`). +In HTTP `Get` method, it sends an HTTP `GET` request to the provided URL and matches the response code based on the given criteria (`==`, `!=`, `oneOf`). -In HTTP `Post` method it sends a http `POST` request to the provided url. The http body can be provided in the `body` field. In the case of a complex POST request in which the body spans multiple lines, the `bodyPath` attribute can be used to provide the path to a file consisting of the same. This file can be made available to the fault pod via a ConfigMap resource, with the ConfigMap name being defined in the [ChaosEngine](glossary.md) OR the ChaosExperiment CR. +In HTTP `Post` method, it sends an HTTP `POST` request to the provided URL. The http body can be provided in the `body` field. In the case of a complex POST request in which the body spans multiple lines, the `bodyPath` attribute can be used to provide the path to a file consisting of the same. This file can be made available to the fault pod via a ConfigMap resource, with the ConfigMap name being defined in the [ChaosEngine](glossary.md) OR the ChaosExperiment CR. It can be defined at `.spec.experiments[].spec.probe` inside ChaosEngine. > `body` and `bodyPath` are mutually exclusive diff --git a/website/versioned_docs/version-3.0.0/concepts/projects.md b/website/versioned_docs/version-3.0.0/concepts/projects.md index 18bd1d2f..548cb9b7 100644 --- a/website/versioned_docs/version-3.0.0/concepts/projects.md +++ b/website/versioned_docs/version-3.0.0/concepts/projects.md @@ -10,7 +10,7 @@ The ChaosCenter comes with a project management system that can be used for work ## Prerequisites -Before learning about the concept of `projects`, it is important to note that a `project` signifies a separation between Chaos infrastructures, Schedules, [Visualization](visualize-experiment.md), and Teams (discussed in the next section) configurations, and prior knowledge of these will prove fruitful in understanding the concept of `projects` in-depth. +Before learning about the concept of projects, it is important to note that a project signifies a separation between Chaos infrastructures, Schedules, [Visualization](visualize-experiment.md), and Teams (discussed in the next section) configurations, and prior knowledge of these will prove fruitful in understanding the concept of projects in-depth. ## Projects diff --git a/website/versioned_docs/version-3.0.0/concepts/teaming.md b/website/versioned_docs/version-3.0.0/concepts/teaming.md index 2ab89eab..b684ca80 100644 --- a/website/versioned_docs/version-3.0.0/concepts/teaming.md +++ b/website/versioned_docs/version-3.0.0/concepts/teaming.md @@ -1,6 +1,6 @@ --- id: teaming -title: Collaborate with Teams +title: Collaborate with teams sidebar_label: Teaming --- @@ -8,7 +8,7 @@ sidebar_label: Teaming The ChaosCenter has a built in teaming feature to facilitate collaboration between users using project level role access, the core concepts of which are discussed below. -## Project level roles (Owner, Editor, Viewer) +## Project level roles Each user has a default project created on user creation by the admin for which they maintain a project level `Owner` access. Every `Owner` has the ability to invite other users into their project with different permission levels, namely `Editor`, and `Viewer`. diff --git a/website/versioned_docs/version-3.0.0/concepts/user-management.md b/website/versioned_docs/version-3.0.0/concepts/user-management.md index b4146745..f339c178 100644 --- a/website/versioned_docs/version-3.0.0/concepts/user-management.md +++ b/website/versioned_docs/version-3.0.0/concepts/user-management.md @@ -1,28 +1,28 @@ --- id: user-management -title: User Management -sidebar_label: User Management +title: User management +sidebar_label: User management --- --- -The ChaosCenter supports two different levels of hierarchy, a portal level access, and a project level access. +The ChaosCenter supports two different levels of hierarchy, a portal level access and a project level access. -> This section discusses the detailed breakdown of the portal level roles a user may have. For project level roles refer [here](teaming.md). +> This section discusses the detailed breakdown of the portal level roles a user may have. For project level roles, refer [here](teaming.md). -## Portal level user Roles (Admin, Non-Admins) +## Portal level user roles ChaosCenter supports two portal level roles for defining the privilege levels of a certain user: -**Admin:** the admin user is created by default on initial project setup and can log into the portal using the credentials `admin/litmus` once the server pod (auth container) is up. +**Admin:** The admin user is created by default upon setup and can be used for logging in to the ChaosCenter using the credentials once the server pod (auth container) is up. -**Non-admin users:** The admin of the portal has the exclusive ability to create any number of non-admin users. +**Non-admin users:** The admin of the ChaosCenter can exclusively create any number of non-admin users. -## Role Privileges +## Role privileges -**Admin** is the highest privilege level offered in the portal and the admin has complete access to all the features offered by the portal. +**Admin:** It is the highest privilege role offered in the ChaosCenter which provides complete access to all the features. -**Non-admin users:** Non-admin users get all the same privileges as an admin-level user, with the exception of the user management feature which is an admin-exclusive feature to facilitate an admin to manage their teams on the portal. (Example: In an organization, multiple different teams might be formed to inject chaos into different chaos infrastructures that have no layover between each other.) +**Non-admin users:** Non-admin users get all the same privileges as an admin-level user, with the exception of the user management feature which is an admin-exclusive feature to facilitate an admin to manage their teams on the ChaosCenter. For example, in an organization there can be different teams who'd utilize different chaos infrastructures that have no layover between each other. ## Learn more diff --git a/website/versioned_docs/version-3.0.0/concepts/visualize-experiment.md b/website/versioned_docs/version-3.0.0/concepts/visualize-experiment.md index d0129178..be2c02fe 100644 --- a/website/versioned_docs/version-3.0.0/concepts/visualize-experiment.md +++ b/website/versioned_docs/version-3.0.0/concepts/visualize-experiment.md @@ -1,32 +1,31 @@ --- id: visualize-experiment -title: Visualize the Chaos Experiment Execution -sidebar_label: Visualize Chaos Experiment +title: Visualize chaos experiment +sidebar_label: Visualize chaos experiment --- --- -Visualization is an important aspect while doing chaos engineering. It allows the user to discover and inspect different changes that occur during a Chaos Experiment execution.
    -With ChaosCenter, the real-time data and status of the chaos experiments can be observed. Valuable information like pod logs, chaos experiment status, and chaos results can also be viewed. +Visualization is an important aspect while doing chaos engineering. It allows the user to discover and inspect different changes that occur during a Chaos Experiment execution. With ChaosCenter, the real-time data and status of the chaos experiments can be observed. Valuable information like pod logs, chaos experiment status, and chaos results can also be viewed. ## Prerequisites -The following should be required before creating a Chaos Experiment: +The following is required before visualizing a chaos experiment: - ChaosCenter - [Chaos Experiments](chaos-workflow.md) -## Litmus Chaos Experiment +## Create chaos experiment -If the user chooses to 'Save' and 'Run' the experiment, they will be redirected directly to the experiment execution page where the experiment can be visualised else they will be taken Chaos Experiment Page. +If the user chooses to **Save** and **Run** the experiment, they will be directed to the experiment execution page, where the experiment can be visualized. Otherwise, they will be taken to the chaos experiment page. -## Visualize a Litmus Chaos Experiment +## Visualize chaos experiment -To observe a chaos experiment, user needs to select the highlighted experiment run box from the heatmap, it will redirect to experiment run execution page.
    +To observe a chaos experiment, user needs to select the highlighted experiment run box from the heatmap, it will redirect to experiment run execution page. -In the chaos experiment, a realtime graph of the chaos experiment is displayed. This graph contains valuable information regarding the status of individual steps of the chaos experiment.

    -

    +In the chaos experiment, a realtime graph of the chaos experiment is displayed. This graph contains valuable information regarding the status of individual steps of the chaos experiment. + To view the details of each step, the user can click on the individual nodes and the right side pane will display the node details, results(once the execution is complete), and the logs related to it.

    diff --git a/website/versioned_docs/version-3.0.0/getting-started/installation.md b/website/versioned_docs/version-3.0.0/getting-started/installation.md index 98596bf6..432b6b82 100644 --- a/website/versioned_docs/version-3.0.0/getting-started/installation.md +++ b/website/versioned_docs/version-3.0.0/getting-started/installation.md @@ -1,6 +1,6 @@ --- id: installation -title: ChaosCenter Cluster Scope Installation +title: ChaosCenter cluster scope installation sidebar_label: Installation --- diff --git a/website/versioned_docs/version-3.0.0/getting-started/resources.md b/website/versioned_docs/version-3.0.0/getting-started/resources.md index 3896c0f8..4a686853 100644 --- a/website/versioned_docs/version-3.0.0/getting-started/resources.md +++ b/website/versioned_docs/version-3.0.0/getting-started/resources.md @@ -7,51 +7,33 @@ sidebar_label: Resources --- ## ChaosCenter +ChaosCenter is a unified pane that controls all the functions provided by Litmus. It can be used for managing the entire lifecycle of the chaos experiments, including all the components within. -ChaosCenter is a single source of truth to control all the functions provided by Litmus. From ChaosCenter, you get the freedom to manage every single part of Litmus and shape your chaos experiments exactly the way you want it. - -**ChaosCenter comes pre-packaged** as a part of LitmusChaos installation and can be easily accessed via [Ingress](../user-guides/setup-with-ingress.md), [NodePort](../user-guides/setup-without-ingress.md#with-nodeport) or [LoadBalancer](../user-guides/setup-without-ingress.md#with-loadbalancer). Since Litmus has Cross-Cloud support, you get seamless access to the ChaosCenter irrespectively of where you deploy it. - -> [Get a broader view of which Platforms are supported by Litmus](https://github.com/litmuschaos/litmus/tree/master/litmus-portal#platforms-support) +ChaosCenter comes pre-packaged as a part of LitmusChaos installation and can be easily accessed via [Ingress](../user-guides/setup-with-ingress.md), [NodePort](../user-guides/setup-without-ingress.md#with-nodeport) or [LoadBalancer](../user-guides/setup-without-ingress.md#with-loadbalancer). Since Litmus has Cross-Cloud support, you get seamless access to the ChaosCenter irrespectively of where you deploy it. ChaosCenter gives you access to a plethora of features, the major ones include: -- Chaos Experiment Creation - -
      -
    • From Templates, Custom Chaos Experiments from Scratch (using ChaosHubs), From pre-created YAMLs
      • -
    • Chaos Experiments Sequence Control (Parallel as well as Sequential steps creation)
      • -
    • Creation of either Singular or Cron Chaos Experiments as Schedules
      • -
    • Attaching priority to Chaos Experiments based on your use cases
      • -
    -     -- Users & Teams - -
      -
    • Creation of Users with Role Based Access Control
      • -
    • Creating a Team of multiple Users
      • -
    • Authenticating Users
      • -
    -     -- Chaos Experiment Management - -
      -
    • Rolling out automated changes using GitOps
      • -
    • Allowing image addition from custom image server (both public and private)
      • -
    • Measure and Analyze the Resilience Score of each chaos scenario
      • -
    -     +- **Chaos experiment creation** + - From templates, custom experiments from scratch (using ChaosHubs), from pre-created YAMLs + - Experiments sequence control (parallel as well as sequential steps creation) + - Creation of either singular or cron experiments as schedules + - Attaching priority to experiments based on your use cases +- **Users and teams** + - Creation of users with Role Based Access Control + - Creating a team of multiple users + - Authenticating users +- **Chaos experiment management** + - Rolling out automated changes using GitOps + - Allowing image addition from custom image server (both public and private) + - Measure and analyze the Resilience Score of each chaos scenario ## Chaos Infrastructures -Chaos infrastructure is a service that runs in your target environment and aids Litmus in accessing and injecting chaos to your target environment. There should always be at least one or more than one chaos infrastructure connected to the ChaosCenter. +Chaos infrastructure is a service that runs in your target environment and aids Litmus in accessing and injecting chaos to your target environment. There should always be at least one or more than one chaos infrastructure connected to the ChaosCenter to execute an experiment. ## Types of Chaos Infrastructures -In Litmus, chaos infrastructures can be classified into two types - -- Self Chaos Infrastructures -- External Chaos Infrastructures +In Litmus, chaos infrastructures can be classified into two types: -As part of the Litmus installation, a Self Chaos Infrastructure would be registered as a default Chaos Infrastructure in the ChaosCenter. The same cluster where Litmus is installed is chosen as the Self Chaos Infrastructure by the installer. From the ChaosCenter you can now induce chaos into this Self Chaos Infrastructure and observe the results. +- **Self Chaos Infrastructures:** A Chaos Infrastructure that is connected to the same cluster and namespace where the ChaosCenter is deployed. It can be used to target the workloads executing on that cluster only. -Since the ChaosCenter is Cross Cloud, you can connect multiple External Chaos Infrastructure to the same ChaosCenter with the help of the command line utility [litmusctl](../litmusctl/installation.md). Once connected you can manage, monitor, observe and induce chaos from the ChaosCenter to the respective Chaos Infrastructures. +- **External Chaos Infrastructures:** A Chaos Infrastructure that is connected to a remote Kubernetes cluster. ChaosCenter can be operated in a cross-cloud manner, which allows connecting multiple External Chaos Infrastructure to the same ChaosCenter with the help of the [litmusctl](../litmusctl/installation.md) CLI. Once connected you can manage, monitor, observe and induce chaos from the ChaosCenter to the respective External Chaos Infrastructures.