refactors getting-started, architecture and concepts sections (#263)

Signed-off-by: neelanjan00 <neelanjan.manna@harness.io>

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:
-
-<li>The term <b>Chaos Delegate/Agent</b> has been changed to <b>Chaos Infrastructure.</b> </li>
-<li>The term <b>Chaos Experiment</b> has been changed to <b>Chaos Fault.</b> </li>
-<li>The term <b>Chaos Scenario/Workflow</b> has been changed to <b>Chaos Experiment.</b></li>
+- 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**.
 :::

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
 ---
 
 ---
 
 <img src={require("../assets/chaos-control-plane.png").default} alt="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.
 

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:
-
-<li>The term <b>Chaos Delegate/Agent</b> has been changed to <b>Chaos Infrastructure.</b> </li>
-<li>The term <b>Chaos Experiment</b> has been changed to <b>Chaos Fault.</b> </li>
-<li>The term <b>Chaos Experiment/Workflow</b> has been changed to <b>Chaos Experiment.</b></li>
+- 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**.
 :::

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:
-
-<li>The term <b>Chaos Experiment</b> has been changed to <b>Chaos Fault.</b> </li>
-<li>The term <b>Chaos Experiment/Workflow</b> has been changed to <b>Chaos Experiment.</b></li>
+- 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**.
 :::

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. <br/>
-It is useful in automating a series of pre-conditioning steps or action which is necessary to be performed before triggering the chaos injection.<br/>
-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:
-
-<li>The term <b>Chaos Experiment</b> has been changed to <b>Chaos Fault.</b> </li>
-<li>The term <b>Chaos Scenario/Workflow</b> has been changed to <b>Chaos Experiment.</b></li>
+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.<br/>
 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.

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.
 
 <img src={require('../assets/concepts/chaoshub/chaoshub-default.png').default} width="800" />
 
-### 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
 
 <img src={require('../assets/concepts/chaoshub/chaoshub-add-public.png').default} width="800" />
 
-### 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:
 
 <img src={require('../assets/concepts/chaoshub/chaoshub-add-private.png').default} width="800" />
 
-#### 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.
 
 <img src={require('../assets/concepts/chaoshub/chaoshub-chaos-charts.png').default} width="800" />
 
 ### 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.
 
 <img src={require('../assets/concepts/chaoshub/chaoshub-exp-details.png').default} width="800" />
 
@@ -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