diff --git a/website/docs/litmusctl/installation.md b/website/docs/litmusctl/installation.md
index d93efa3..617b19a 100644
--- a/website/docs/litmusctl/installation.md
+++ b/website/docs/litmusctl/installation.md
@@ -23,7 +23,6 @@ For more information including a complete list of litmusctl operations, see the
- For v0.12.0 or latest: Click here
- For v0.2.0 or earlier: Click here
-
## Compatibility matrix
To check compatibility of litmusctl with Chaos Center
@@ -50,15 +49,19 @@ To check compatibility of litmusctl with Chaos Center
0.10.0
-
2.9.0, 2.10.0, 2.11.0, 2.12.0
+
2.9.0, 2.10.0, 2.11.0, 2.12.0, 2.13.0
0.11.0
-
2.9.0, 2.10.0, 2.11.0, 2.12.0
+
2.9.0, 2.10.0, 2.11.0, 2.12.0, 2.13.0
-
+
0.12.0
-
2.9.0, 2.10.0, 2.11.0, 2.12.0
+
2.9.0, 2.10.0, 2.11.0, 2.12.0, 2.13.0
+
+
+
0.13.0
+
2.9.0, 2.10.0, 2.11.0, 2.12.0, 2.13.0
@@ -68,6 +71,7 @@ To install the latest version of litmusctl follow the below steps:
Platforms
+
0.13.0
0.12.0
v0.11.0
v0.10.0
@@ -78,6 +82,7 @@ To install the latest version of litmusctl follow the below steps:
diff --git a/website/docs/user-guides/chaoscenter-namespace-scope-installation.md b/website/docs/user-guides/chaoscenter-namespace-scope-installation.md
index 8b7b621..d1090d5 100644
--- a/website/docs/user-guides/chaoscenter-namespace-scope-installation.md
+++ b/website/docs/user-guides/chaoscenter-namespace-scope-installation.md
@@ -217,12 +217,12 @@ service/mongo-headless-service created
mongo-headless-service ClusterIP None 27017/TCP 101s
```
-> Note: With the namespace mode of the control panel, we need to set the endpoint of the chaos center server according to the use case. By default, it is `http://litmusportal-server-service:9002`
+> Note: With the namespace mode of the control panel, we need to set the endpoint of the chaos center ui according to the use case for external Chaos Delegates. By default, it is `http://litmusportal-frontend-service:9091`
To alter, Apply:
```bash
-kubectl set env deployment/litmusportal-server -n litmus --containers="graphql-server" PORTAL_ENDPOINT="http://172.132.44.44:3231"
+kubectl set env deployment/litmusportal-server -n litmus --containers="graphql-server" CHAOS_CENTER_UI_ENDPOINT="http://172.132.44.44:3231"
```
---
diff --git a/website/versioned_docs/version-2.13.0/architecture/architecture-summary.md b/website/versioned_docs/version-2.13.0/architecture/architecture-summary.md
new file mode 100644
index 0000000..e6c554f
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/architecture/architecture-summary.md
@@ -0,0 +1,17 @@
+---
+id: architecture-summary
+title: Architecture Summary
+sidebar_label: Architecture Summary
+---
+
+---
+
+
+
+The Litmus architecture can be segregated into two parts:
+
+1. **Control Plane:** Contains the components required for the functioning of Chaos Center, the website-based portal for Litmus.
+
+2. **Execution Plane:** Contains the components required for the injection of chaos in the target resources.
+
+Chaos Center can be used for creating, scheduling, and monitoring Chaos Scenarios, a set of chaos experiments defined in a definitive sequence to achieve desired chaos impact on the target resources upon execution. Users can log in to the Chaos Center using valid login credentials and leverage the interactive web UI to define their chaos scenario to target multiple aspects of their infrastructure. Once the user creates a Chaos Scenario using the Chaos Center, 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 delegate is being used, or in the target cluster if an external chaos delegate is being used. The Execution Plane interprets the Chaos Scenario 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 Scenario 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 Scenario runs to execute chaos as part of the CI/CD pipeline based on a set of defined conditions using GitOps.
diff --git a/website/versioned_docs/version-2.13.0/architecture/chaos-control-plane.md b/website/versioned_docs/version-2.13.0/architecture/chaos-control-plane.md
new file mode 100644
index 0000000..5a83e0b
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/architecture/chaos-control-plane.md
@@ -0,0 +1,40 @@
+---
+id: chaos-control-plane
+title: Chaos Control Plane
+sidebar_label: Chaos Control Plane
+---
+
+---
+
+
+
+Chaos Control Plane consists of micro-services responsible for the functioning of the Chaos Center, the website-based portal that can be used for interacting with Litmus, apart from the CLI. Chaos Plane facilitates the creation and scheduling of chaos scenarios, system observability during the event of chaos, and post-processing and analysis of experiment results.
+
+## Chaos Control Plane Components
+
+- **Authentication Server:** A Golang micro-service that is responsible for authorizing, authenticating the requests received from Chaos Center 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.
+
+- **Backend Server:** A GraphQL based Golang micro-service that serves the requests received from Chaos Center, by either querying the database for the relevant information or by fetching information from the Execution Plane.
+
+- **Database:** A NoSQL MongoDB database micro-service that is accountable for storing users' information, past chaos scenarios, saved chaos scenario templates, user projects, ChaosHubs, and GitOps details, among the other information.
+
+- **Chaos Center:** Refers to the interfaces used by Litmus for creation and scheduling of chaos scenarios, system observability during chaos injection, and post chaos result analysis. It includes:
+
+ - **Web UI:** A React.js based frontend application micro-service with built-in system observability capabilities and an analytics dashboard. It also facilitates teams of users to collaborate over chaos scenarios using role-based user accounts.
+
+ - **Litmusctl:** A command-line tool that allows management of Litmus Chaos Delegate Infrastructure components. It can be used to create chaos delegates, project, and manage multiple Litmus accounts.
+
+ - **Litmus API:** Refers to two different Litmus APIs, namely Litmus Authentication API and Litmus Portal API:
+
+ - **Litmus Authentication API:** Used to authenticate the identity of a user and to perform several user and project specific tasks like create new users, update profile, update password, create project, invite users to project, get project details etc. It uses the Authentication Server to perform these tasks.
+
+ - **Litmus Portal API:** Provides command-line and UI experience for managing and monitoring the events around chaos scenarios. It uses the Backend Server to perform its functions.
+
+## Standard Chaos Control Plane Flow
+
+1. The User logs in to the ChaosCenter using a valid login credential. A default project is created for the user on initial login. Every user is a part of a project and has a role assigned to them. To schedule a chaos scenario, the user needs to have an Editor or Owner role assigned in the project.
+2. The user uploads a Chaos Scenario manifest using the ChaosCenter, which is received by the Backend Server.
+3. Backend Server stores the manifest in the Database and also sends it to the Chaos Delegate.
+4. Chaos Delegate uses the Chaos Scenario manifest to inject chaos into the target resources. The steps of the Chaos Scenario execution can be visualized using the ChaosCenter.
+5. Chaos Delegate returns the results of the chaos experiments that were a part of the chaos scenario back to the Backend Server, along with the experiment logs.
+6. Backend Server then sends the chaos experiment results and logs to the ChaosCenter. It also stores the results into the Database for generating post-chaos scenario statistics and information.
diff --git a/website/versioned_docs/version-2.13.0/architecture/chaos-execution-plane.md b/website/versioned_docs/version-2.13.0/architecture/chaos-execution-plane.md
new file mode 100644
index 0000000..4b8a888
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/architecture/chaos-execution-plane.md
@@ -0,0 +1,64 @@
+---
+id: chaos-execution-plane
+title: Chaos Execution Plane
+sidebar_label: Chaos Execution Plane
+---
+
+---
+
+
+
+Chaos Execution Plane contains the components responsible for orchestrating the chaos injection in the target resources. They get installed in either an external target cluster if an external chaos delegate is being used or in the host cluster containing the control plane if a self chaos delegate is being used. It can be further segregated into Litmus Chaos Delegate Infrastructure components and Litmus Backend Execution Infrastructure components.
+
+## Litmus Execution Plane Components
+
+Litmus Chaos Delegate Infrastructure components help facilitate the chaos injection, manage chaos observability, and enable chaos automation for target resources. These components include:
+
+1. **Workflow Controller:** The Argo Workflow Controller responsible for the creation of Chaos Scenarios using the Chaos Scenario CR.
+
+2. **Subscriber:** Serves as the link between the Chaos Execution Plane and the Control Plane. It has a few distinct responsibilities such as performing health check of all the components in Chaos Execution Plane, creation of a Chaos Scenario CR from a Chaos Scenario template, watching for Chaos Scenario events during its execution, and sending the chaos scenario result to the Control Plane.
+
+3. **Event Tracker:** An optional component that is capable of triggering automated chaos scenario runs based on a set of defined conditions for any given resources in the cluster. It is a controller that manages EventTrackerPolicy CR, which is basically the set of defined conditions that is validated by Event Tracker. If the current state of the tracked resources match with the state defined in the EventTrackerPolicy CR, the chaos scenario run run gets triggered. This feature can only be used if GitOps is enabled.
+
+4. **Chaos Exporter:** An optional component that facilitates external observability in Litmus by exporting the chaos metrics generated during the chaos injection as time-series data to the Prometheus DB for its processing and analysis.
+
+Litmus Backend Execution Infrastructure components orchestrate the execution of Chaos Scenario in target resources. These components include:
+
+1. **Chaos Scenario CR:** Refers to the Argo Workflow CR which describes the steps that are executed as a part of the chaos scenario. It is used to define failures during a certain workload condition (such as, say, percentage load), multiple (parallel) failures of dependent and independent services etc.
+
+2. **ChaosExperiment CR:** Used for defining the low-level execution information for any Litmus chaos experiment as well as to store the various experiment tunables.
+
+3. **ChaosEngine CR:** Used to hold information about how the chaos experiments are executed. It connects an application instance with one or more chaos experiments while allowing the users to specify run-level details.
+
+4. **Chaos Operator:** A Kubernetes custom-controller that manages the lifecycle of certain resources or applications intending to validate their "desired state". It helps reconcile the state of the ChaosEngine by performing specific actions upon CRUD of the ChaosEngine. It also defines a secondary resource (the ChaosEngine Runner pod), which is created & managed by it to implement the reconcile functions.
+
+
+
+
+
+5. **ChaosResult CR:** Holds the results of a chaos experiment, such as ChaosEngine reference, Experiment State, Verdict of the experiment (on completion), salient application/result attributes. It also acts as a source for metrics collection for observability.
+
+6. **Chaos Runner:** Acts as a bridge between the Chaos Operator and Chaos Experiments. It is a lifecycle manager for the chaos experiments that creates Experiment Jobs for the execution of experiment business logic and monitors the experiment pods (jobs) until completion.
+
+
+
+
+
+7. **Experiment Jobs:** Refers to the pods that execute the experiment logic. One experiment pod is created per chaos experiment in the chaos scenario.
+
+## Standard Chaos Execution Plane Flow
+
+1. Subscriber receives the Chaos Scenario manifest from the Control Plane and applies the manifest to create a Chaos Scenario CR.
+2. Chaos Scenario CRs are tracked by the Argo Workflow Controller. When the Workflow Controller finds a new Chaos Scenario CR, it creates the ChaosExperiment CRs and the ChaosEngine CRs for the chaos experiments that are a part of the chaos scenario.
+3. ChaosEngine CRs are tracked by the Chaos Operator. Once a ChaosEngine CR is ready, the Chaos Operator updates the ChaosEngine state to reflect that the particular ChaosEngine is now being executed.
+4. For each ChaosEngine resource, a Chaos Runner is created by the Chaos Operator.
+5. Chaos Runner firstly reads the chaos parameters from the ChaosExperiment CR and overrides them with values from the ChaosEngine CR. It then constructs the Experiment Jobs and monitors them until their completion.
+6. Experiment Jobs execute the experiment business logic and undertake chaos injection on target resources. Once done, the ChaosResult is updated with the experiment verdict.
+7. Chaos Runner then fetches the updated ChaosResult and updates the ChaosEngine status as well as the verdict.
+8. Once the ChaosEngine is updated, Subscriber fetches the ChaosEngine details and the ChaosResult and forwards them to Chaos Control Plane.
+
+It is worth noticing that:
+
+- If configured, Chaos Exporter fetches data from the ChaosResult CR and converts it in a time-series format to be consumed by the Prometheus DB.
+
+- An Event Tracker Policy can also be set up as part of the Backend GitOps, where the Backend GitOps Controller tracks a set of specified resources in the target cluster for any change. If any of the tracked resources undergo any change and their resulting state matches the state defined in the Event Tracker Policy, then a pre-defined Chaos Scenario is executed.
diff --git a/website/versioned_docs/version-2.13.0/architecture/chaos-experiment-flow.md b/website/versioned_docs/version-2.13.0/architecture/chaos-experiment-flow.md
new file mode 100644
index 0000000..6e79bb4
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/architecture/chaos-experiment-flow.md
@@ -0,0 +1,30 @@
+---
+id: chaos-experiment-flow
+title: Chaos Experiment Flow
+sidebar_label: Chaos Experiment Flow
+---
+
+---
+
+
+
+The experiment execution is triggered upon the creation of a ChaosEngine resource. The ChaosEngine resource interacts with Chaos Runner, which is created by the Chaos Operator. The Chaos Runner creates Experiment Jobs that execute the experiment business logic. Typically, these ChaosEngines are embedded within the 'steps' of a Litmus Chaos Scenario. However, one may also create and apply the Chaos Engines manually, and then the chaos-operator reconciles this resource and triggers the experiment execution. Chaos experiments are classified as:
+
+- Kubernetes Experiments
+ - Pod-Level Chaos
+ - Node-Level Chaos
+- Application Chaos
+- Cloud Infrastructure
+
+## Chaos Experiment Flow Steps
+
+1. Chaos experiment execution gets triggered by the Experiment Job.
+2. Experiment tunables and low-level execution details are fetched.
+3. ChaosResult gets initialized and its verdict is updated as "Awaited" to indicate that the experiment is currently running.
+4. Steady-state condition for the respective experiment is validated. If the condition is found to be invalid, the experiment execution is stopped and the ChaosResult is updated as "Fail".
+5. Once the steady-state condition is validated, experiment resources are created to facilitate the chaos injection.
+6. Chaos injection is performed on the target resources for the specified chaos duration.
+7. Chaos injection gets reverted.
+8. Post chaos status-check is performed to ensure that the steady-state is still maintained.
+9. If the check is invalid, the ChaosEngine and ChaosResult verdicts are updated as "Fail", otherwise they are updated as "Pass".
+10. Experiment execution ends.
diff --git a/website/versioned_docs/version-2.13.0/architecture/chaos-observability-flow-analytics.md b/website/versioned_docs/version-2.13.0/architecture/chaos-observability-flow-analytics.md
new file mode 100644
index 0000000..82ce547
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/architecture/chaos-observability-flow-analytics.md
@@ -0,0 +1,23 @@
+---
+id: chaos-observability-flow-analytics
+title: Analytics
+sidebar_label: Analytics
+---
+
+---
+
+
+
+Analytics is an integral part of Chaos Engineering, as it offers key insights that are required to fully understand a system during the chaos and functions as a decision-making tool for improving system resiliency.
+
+In Litmus, chaos scenario run statistics and information are generated post the chaos scenario execution, which can be accessed directly using the ChaosCenter.
+
+## Observability Flow for Analytics
+
+1. In the Chaos Execution Plane, the ChaosEngine Details and ChaosResult are fetched by the Chaos Delegate.
+2. Chaos Delegate then forwards them to the Backend Server in the Chaos Control Plane and later they get stored into the Database.
+3. User specifies the Chaos Scenario Schedule for which the Chaos Scenario statistics and information is to be fetched as an input in the ChaosCenter.
+4. The request for the Chaos Scenario statistics and information is received by the Backend Server.
+5. Backend Server queries the Database for the details of past Chaos Scenario Runs.
+6. Aggregated Chaos Scenario statistics based on the ChaosResult verdict and probe success percentage are fetched from the Database by Backend Server.
+7. Chaos Scenario statistics and information are forwarded to ChaosCenter by Backend Server.
diff --git a/website/versioned_docs/version-2.13.0/architecture/chaos-observability-flow-logging.md b/website/versioned_docs/version-2.13.0/architecture/chaos-observability-flow-logging.md
new file mode 100644
index 0000000..ffc57fe
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/architecture/chaos-observability-flow-logging.md
@@ -0,0 +1,23 @@
+---
+id: chaos-observability-flow-logging
+title: Logging
+sidebar_label: Logging
+---
+
+---
+
+
+
+Logging is a pivotal observability aspect in LitmusChaos as it allows the user to track the exact system behavior during the scenario of a chaos. The logs can be classified into one of the following:
+
+- **Litmus Checker Logs:** Logs generated as part of the validation for chaos resources that are required to execute a chaos experiment.
+- **Experiment Logs:** Logs generated as part of the steps performed during the chaos experiment, including pre-chaos check logs, chaos injection logs, chaos probes logs, and post-chaos check logs.
+- **Non-Chaos Scenario Step Logs:** Logs generated as part of the chaos scenario steps that facilitate the execution of the chaos experiment, such as chaos experiment installation step logs, chaos revert step logs, etc.
+
+## Observability Flow for Logging
+
+1. User requests the logs for any particular chaos scenario step using the ChaosCenter.
+2. The request for the logs is received by the Backend Server and is forwarded to the Subscriber.
+3. The subscriber checks if the chaos scenario step is a Chaos Experiment step or not.
+4. If the chaos scenario step is a Chaos Experiment step, then the Litmus Checker logs and the Chaos Experiment Logs are fetched from the ChaosEngine CR by the subscriber. Else, the logs of the chaos scenario step pod is fetched from the respective chaos scenario step pod by the subscriber.
+5. The fetched logs are returned to the Backend Server, which returns them to the ChaosCenter.
diff --git a/website/versioned_docs/version-2.13.0/architecture/chaos-observability-flow-monitoring.md b/website/versioned_docs/version-2.13.0/architecture/chaos-observability-flow-monitoring.md
new file mode 100644
index 0000000..968a44a
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/architecture/chaos-observability-flow-monitoring.md
@@ -0,0 +1,38 @@
+---
+id: chaos-observability-flow-monitoring
+title: Monitoring
+sidebar_label: Monitoring
+---
+
+---
+
+Monitoring is a key part to effectively watch and understand the state of the systems. In Litmus, the monitoring is split into a two-fold approach:
+- Metrics Monitoring
+- Events Monitoring
+
+## Metrics Monitoring
+
+
+
+
+
+Metrics Monitoring enables the users to monitor the chaos metrics generated during chaos injection, which is exported by the chaos exporter to be consumed as time-series information.
+
+### Observability Flow for Metrics Monitoring
+1. During the event of chaos, the ChaosResult CR and the ChaosEngine CR are fetched by the Chaos Exporter.
+2. If ChaosResult verdict is "Awaited", then the Continuous Event Metrics are fetched by Chaos Exporter. Else, if the verdict is "Pass" or "Fail" or "Stopped", then the Gauge Metrics are fetched by Chaos Exporter at a fixed TSDB Scrape Interval.
+3. The fetched metrics are then exposed at the Chaos Exporter Kubernetes service.
+4. TSDBs consume these metrics and store them as time-series value.
+5. APMs and Visualisation Tools query and fetch the chaos metric from the TSDBs.
+
+## Events Monitoring
+
+
The engineState in the spec is a user defined flag to trigger chaos. Setting it to active ensures successful execution of chaos. Patching it with stop aborts ongoing experiments. It has a corresponding flag in the chaosengine status field, called engineStatus which is updated by the controller based on actual state of the ChaosEngine.
+
+
+
+### Application Specification
+
+
+
+
Field
+
.spec.appinfo.appns
+
+
+
Description
+
Flag to specify namespace of application under test
+
+
+
Type
+
Optional
+
+
+
Range
+
user-defined (type: string)
+
+
+
Default
+
n/a
+
+
+
Notes
+
The appns in the spec specifies the namespace of the AUT. Usually provided as a quoted string. It is optional for the infra chaos.
+
+
+
+
+
+
Field
+
.spec.appinfo.applabel
+
+
+
Description
+
Flag to specify unique label of application under test
The applabel in the spec specifies a unique label of the AUT. Usually provided as a quoted string of pattern key=value. Note that if multiple applications share the same label within a given namespace, the AUT is filtered based on the presence of the chaos annotation litmuschaos.io/chaos: "true". If, however, the annotationCheck is disabled, then a random application (pod) sharing the specified label is selected for chaos. It is optional for the infra chaos.
+
+
+
+
+
+
Field
+
.spec.appinfo.appkind
+
+
+
Description
+
Flag to specify resource kind of application under test
The appkind in the spec specifies the Kubernetes resource type of the app deployment. The Litmus ChaosOperator supports chaos on deployments, statefulsets and daemonsets. Application health check routines are dependent on the resource types, in case of some experiments. It is optional for the infra chaos
+
+
+
+
+
+
Field
+
.spec.auxiliaryAppInfo
+
+
+
Description
+
Flag to specify one or more app namespace-label pairs whose health is also monitored as part of the chaos experiment, in addition to a primary application specified in the .spec.appInfo. NOTE: If the auxiliary applications are deployed in namespaces other than the AUT, ensure that the chaosServiceAccount is bound to a cluster role and has adequate permissions to list pods on other namespaces.
The auxiliaryAppInfo in the spec specifies a (comma-separated) list of namespace-label pairs for downstream (dependent) apps of the primary app specified in .spec.appInfo in case of pod-level chaos experiments. In case of infra-level chaos experiments, this flag specifies those apps that may be directly impacted by chaos and upon which health checks are necessary.
+
+
+
+**Note**: Irrespective of the nature of the chaos experiment, i.e., pod-level (single-app impact/lesser blast radius) or infra-level(multi-app impact/higher blast radius), the `.spec.appinfo` is a must-fill where the experiment is pointed to at least one primary app whose health is measured as an indicator of the resiliency / success of the chaos experiment.
+
+### RBAC Specification
+
+
+
+
Field
+
.spec.chaosServiceAccount
+
+
+
Description
+
Flag to specify serviceaccount used for chaos experiment
+
+
+
Type
+
Mandatory
+
+
+
Range
+
user-defined (type: string)
+
+
+
Default
+
n/a
+
+
+
Notes
+
The chaosServiceAccount in the spec specifies the name of the serviceaccount mapped to a role/clusterRole with enough permissions to execute the desired chaos experiment. The minimum permissions needed for any given experiment is provided in the .spec.definition.permissions field of the respective chaosexperiment CR.
+
+
+
+### Runtime Specification
+
+
+
+
Field
+
.spec.annotationCheck
+
+
+
Description
+
Flag to control annotationChecks on applications as prerequisites for chaos
+
+
+
Type
+
Optional
+
+
+
Range
+
true, false
+
+
+
Default
+
true
+
+
+
Notes
+
The annotationCheck in the spec controls whether or not the operator checks for the annotation "litmuschaos.io/chaos" to be set against the application under test (AUT). Setting it to true ensures the check is performed, with chaos being skipped if the app is not annotated, while setting it to false suppresses this check and proceeds with chaos injection.
+
+
+
+
+
+
Field
+
.spec.terminationGracePeriodSeconds
+
+
+
Description
+
Flag to control terminationGracePeriodSeconds for the chaos pods(abort case)
+
+
+
Type
+
Optional
+
+
+
Range
+
integer value
+
+
+
Default
+
30
+
+
+
Notes
+
The terminationGracePeriodSeconds in the spec controls the terminationGracePeriodSeconds for the chaos resources in abort case. Chaos pods contains chaos revert upon abortion steps, which continuously looking for the termination signals. The terminationGracePeriodSeconds should be provided in such a way that the chaos pods got enough time for the revert before completely terminated.
+
+
+
+
+
+
Field
+
.spec.jobCleanupPolicy
+
+
+
Description
+
Flag to control cleanup of chaos experiment job post execution of chaos
+
+
+
Type
+
Optional
+
+
+
Range
+
delete, retain
+
+
+
Default
+
delete
+
+
+
Notes
+
The jobCleanupPolicy controls whether or not the experiment pods are removed once execution completes. Set to retain for debug purposes (in the absence of standard logging mechanisms).
+
+
+
+### Component Specification
+
+
+
+
Field
+
.spec.components.runner.image
+
+
+
Description
+
Flag to specify image of ChaosRunner pod
+
+
+
Type
+
Optional
+
+
+
Range
+
user-defined (type: string)
+
+
+
Default
+
n/a (refer Notes)
+
+
+
Notes
+
The .components.runner.image allows developers to specify their own debug runner images. Defaults for the runner image can be enforced via the operator env CHAOS_RUNNER_IMAGE
+
+
+
+
+
+
Field
+
.spec.components.runner.imagePullPolicy
+
+
+
Description
+
Flag to specify imagePullPolicy for the ChaosRunner
+
+
+
Type
+
Optional
+
+
+
Range
+
Always, IfNotPresent
+
+
+
Default
+
IfNotPresent
+
+
+
Notes
+
The .components.runner.imagePullPolicy allows developers to specify the pull policy for chaos-runner. Set to Always during debug/test.
+
+
+
+
+
+
Field
+
.spec.components.runner.imagePullSecrets
+
+
+
Description
+
Flag to specify imagePullSecrets for the ChaosRunner
The .spec.components.runner.secrets provides for a means to push secrets (typically project ids, access credentials etc.,) into the chaos runner pod. These are especially useful in case of platform-level/infra-level chaos experiments.
+
+
+
+
+
+
Field
+
.spec.components.runner.nodeSelector
+
+
+
Description
+
Node selectors for the runner pod
+
+
+
Type
+
Optional
+
+
+
Range
+
Labels in the from of label key=value
+
+
+
Default
+
n/a
+
+
+
Notes
+
The .spec.components.runner.nodeSelector The nodeselector contains labels of the node on which runner pod should be scheduled. Typically used in case of infra/node level chaos.
+
+
+
+
+
+
Field
+
.spec.components.runner.resources
+
+
+
Description
+
Specify the resource requirements for the ChaosRunner pod
+
+
+
Type
+
Optional
+
+
+
Range
+
user-defined (type: corev1.ResourceRequirements)
+
+
+
Default
+
n/a
+
+
+
Notes
+
The .spec.components.runner.resources contains the resource requirements for the ChaosRunner Pod, where we can provide resource requests and limits for the pod.
+
+
+
+
+
+
Field
+
.spec.components.runner.tolerations
+
+
+
Description
+
Toleration for the runner pod
+
+
+
Type
+
Optional
+
+
+
Range
+
user-defined (type: []corev1.Toleration)
+
+
+
Default
+
n/a
+
+
+
Notes
+
The .spec.components.runner.tolerations Provides tolerations for the runner pod so that it can be scheduled on the respective tainted node. Typically used in case of infra/node level chaos.
+
+
+
+### Experiment Specification
+
+
+
+
Field
+
.spec.experiments[].name
+
+
+
Description
+
Name of the chaos experiment CR
+
+
+
Type
+
Mandatory
+
+
+
Range
+
user-defined (type: string)
+
+
+
Default
+
n/a
+
+
+
Notes
+
The experiment[].name specifies the chaos experiment to be executed by the ChaosOperator.
+
+
+
+
+
+
Field
+
.spec.experiments[].spec.components.env
+
+
+
Description
+
Environment variables passed to the chaos experiment
The experiment[].spec.components.env specifies the array of tunables passed to the experiment pods. Though the field is optional from a chaosengine definition viewpoint, it is almost always necessary to provide experiment tunables via this definition. While some of the env variables override the defaults in the experiment CR and some of the env are mandatory additions filling in for placeholders/empty values in the experimet CR. For a list of "mandatory" & "optional" env for an experiment, refer to the respective experiment documentation.
The experiment[].spec.components.configMaps provides for a means to insert config information into the experiment. The configmaps definition is validated for correctness and those specified are checked for availability (in the cluster/namespace) before being mounted into the experiment pods.
The experiment[].spec.components.secrets provides for a means to push secrets (typically project ids, access credentials etc.,) into the experiment pods. These are especially useful in case of platform-level/infra-level chaos experiments. The secrets definition is validated for correctness and those specified are checked for availability (in the cluster/namespace) before being mounted into the experiment pods.
The .components.runner.experimentImagePullSecrets allows developers to specify the imagePullSecret name for ChaosExperiment.
+
+
+
+
+
+
Field
+
.spec.experiments[].spec.components.nodeSelector
+
+
+
Description
+
Provide the node selector for the experiment pod
+
+
+
Type
+
Optional
+
+
+
Range
+
Labels in the from of label key=value
+
+
+
Default
+
n/a
+
+
+
Notes
+
The experiment[].spec.components.nodeSelector The nodeselector contains labels of the node on which experiment pod should be scheduled. Typically used in case of infra/node level chaos.
Provides the timeout and retry values for the status checks. Defaults to 180s & 90 retries (2s per retry)
+
+
+
Type
+
Optional
+
+
+
Range
+
It contains values in the form {`delay: int, timeout: int`}
+
+
+
Default
+
delay: 2s and timeout: 180s
+
+
+
Notes
+
The experiment[].spec.components.statusCheckTimeouts The statusCheckTimeouts override the status timeouts inside chaosexperiments. It contains timeout & delay in seconds.
+
+
+
+
+
+
Field
+
.spec.experiments[].spec.components.resources
+
+
+
Description
+
Specify the resource requirements for the ChaosExperiment pod
+
+
+
Type
+
Optional
+
+
+
Range
+
user-defined (type: corev1.ResourceRequirements)
+
+
+
Default
+
n/a
+
+
+
Notes
+
The experiment[].spec.components.resources contains the resource requirements for the ChaosExperiment Pod, where we can provide resource requests and limits for the pod.
Annotations that needs to be provided in the pod which will be created (experiment-pod)
+
+
+
Type
+
Optional
+
+
+
Range
+
user-defined (type: label key=value)
+
+
+
Default
+
n/a
+
+
+
Notes
+
The .spec.components.experimentAnnotation allows developers to specify the custom annotations for the experiment pod.
+
+
+
+
+
+
Field
+
.spec.experiments[].spec.components.tolerations
+
+
+
Description
+
Toleration for the experiment pod
+
+
+
Type
+
Optional
+
+
+
Range
+
user-defined (type: []corev1.Toleration)
+
+
+
Default
+
n/a
+
+
+
Notes
+
The .spec.components.tolerationsTolerations for the experiment pod so that it can be scheduled on the respective tainted node. Typically used in case of infra/node level chaos.
+
+
+
+
+
+
Field
+
.spec.experiments[].spec.probe
+
+
+
Description
+
Declarative way to define the chaos hypothesis
+
+
+
Type
+
Optional
+
+
+
Range
+
user-defined
+
+
+
Default
+
n/a
+
+
+
Notes
+
The .probe allows developers to specify the chaos hypothesis. It supports four types: cmdProbe, k8sProbe, httpProbe, promProbe. For more details refer
+
+
+
+## Summary
+
+The ChaosEngine CR is the user-facing CR which helps in binding the application instance with the ChaosExperiment. It defines the Run Policies and also holds the status of your experiment. This CR helps you customize the experiment according to your need since it can override some of the default characteristics/tunables in your experiment CR.
+
+This CR is also updated/patched with status of the chaos experiments, making it the single source of truth with respect to the chaos.
+
+## Resources
+
+
+
+## Learn More
+
+- [Explore Probes](probes.md)
+- [What is a Chaos Scenario](chaos-workflow.md)
+- [Examine the ChaosResult](chaos-result.md)
diff --git a/website/versioned_docs/version-2.13.0/concepts/chaos-experiment.md b/website/versioned_docs/version-2.13.0/concepts/chaos-experiment.md
new file mode 100644
index 0000000..acb7a0f
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/concepts/chaos-experiment.md
@@ -0,0 +1,424 @@
+---
+id: chaos-experiment
+title: ChaosExperiment
+sidebar_label: ChaosExperiment
+---
+
+---
+
+ChaosExperiment CR is the heart of litmus and contains the low-level execution information. They serve as off-the-shelf templates that one needs to "pull" (install on the cluster.md) before including them as part of a chaos run against any target applications (the binding being defined in the [ChaosEngine](chaos-engine.md)). The experiments are installed on the cluster as Kubernetes custom resources and are designed to hold granular details of the experiment such as image, library, necessary permissions, chaos parameters (set to their default values). Most of the ChaosExperiment parameters, are essentially tunables that can be overridden from the ChaosEngine resource. The ChaosExperiment CRs are the primary artifacts hosted on the [ChaosHub](https://hub.litmuschaos.io)
+
+This section describes the fields in the ChaosExperiment spec and the possible values that can be set against the same.
+
+## Scope Specification
+
+
+
+
Field
+
.spec.definition.scope
+
+
+
Description
+
Flag to specify the scope of the ChaosExperiment
+
+
+
Type
+
Optional
+
+
+
Range
+
Namespaced, Cluster
+
+
+
Default
+
n/a (depends on experiment type)
+
+
+
Notes
+
The .spec.definition.scope specifies the scope of the experiment. It can be Namespaced scope for pod level experiments and Cluster for the experiments having a cluster wide impact.
+
+
+
+
+
+
Field
+
.spec.definition.permissions
+
+
+
Description
+
Flag to specify the minimum permission to run the ChaosExperiment
+
+
+
Type
+
Optional
+
+
+
Range
+
user-defined (type: list)
+
+
+
Default
+
n/a
+
+
+
Notes
+
The .spec.definition.permissions specify the minimum permission that is required to run the ChaosExperiment. It also helps to estimate the blast radius for the ChaosExperiment.
+
+
+
+## Component Specification
+
+
+
+
Field
+
.spec.definition.image
+
+
+
Description
+
Flag to specify the image to run the ChaosExperiment
+
+
+
Type
+
Mandatory
+
+
+
Range
+
user-defined (type: string)
+
+
+
Default
+
n/a (refer Notes)
+
+
+
Notes
+
The .spec.definition.image allows the developers to specify their experiment images. Typically set to the Litmus go-runner or the ansible-runner. This feature of the experiment enables BYOC (BringYourOwnChaos), where developers can implement their own variants of a standard chaos experiment
+
+
+
+
+
+
Field
+
.spec.definition.imagePullPolicy
+
+
+
Description
+
Flag that helps the developers to specify imagePullPolicy for the ChaosExperiment
+
+
+
Type
+
Mandatory
+
+
+
Range
+
IfNotPresent, Always (type: string)
+
+
+
Default
+
Always
+
+
+
Notes
+
The .spec.definition.imagePullPolicy allows developers to specify the pull policy for ChaosExperiment image. Set to Always during debug/test
+
+
+
+
+
+
Field
+
.spec.definition.args
+
+
+
Description
+
Flag to specify the entrypoint for the ChaosExperiment
+
+
+
Type
+
Mandatory
+
+
+
Range
+
user-defined (type:list of string)
+
+
+
Default
+
n/a
+
+
+
Notes
+
The .spec.definition.args specifies the entrypoint for the ChaosExperiment. It depends on the language used in the experiment. For litmus-go the .spec.definition.args contains a single binary of all experiments and managed via -name flag to indicate experiment to run(-name (exp-name)).
+
+
+
+
+
+
Field
+
.spec.definition.command
+
+
+
Description
+
Flag to specify the shell on which the ChaosExperiment will execute
+
+
+
Type
+
Mandatory
+
+
+
Range
+
user-defined (type: list of string).
+
+
+
Default
+
/bin/bash
+
+
+
Notes
+
The .spec.definition.command specifies the shell used to run the experiment /bin/bash is the most common shell to be used.
The .spec.definition.env specifies the array of tunables passed to the experiment pods as environment variables. It is used to manage the experiment execution. We can set the default values for all the variables (tunable) here which can be overridden by ChaosEngine from .spec.experiments[].spec.components.env if required. To know about the variables that need to be overridden check the list of "mandatory" & "optional" env for an experiment as provided within the respective experiment documentation.
The .spec.definition.securityContext.podSecurityContext allows the developers to specify the security context for the ChaosPod which applies to all containers inside the Pod.
+
+
+
+
+
+
Field
+
.spec.definition.configMaps
+
+
+
Description
+
Flag to specify the configmap for ChaosPod
+
+
+
Type
+
Optional
+
+
+
Range
+
user-defined
+
+
+
Default
+
n/a
+
+
+
Notes
+
The .spec.definition.configMaps allows the developers to mount the ConfigMap volume into the experiment pod.
+
+
+
+
+
+
Field
+
.spec.definition.secrets
+
+
+
Description
+
Flag to specify the secrets for ChaosPod
+
+
+
Type
+
Optional
+
+
+
Range
+
user-defined
+
+
+
Default
+
n/a
+
+
+
Notes
+
The .spec.definition.secrets specify the secret data to be passed for the ChaosPod. The secrets typically contains confidential information like credentials.
+
+
+
+
+
+
Field
+
.spec.definition.experimentAnnotations
+
+
+
Description
+
Flag to specify the custom annotation to the ChaosPod
+
+
+
Type
+
Optional
+
+
+
Range
+
user-defined (type:map[string]string)
+
+
+
Default
+
n/a
+
+
+
Notes
+
The .spec.definition.experimentAnnotations allows the developer to specify the Custom annotation for the chaos pod.
+
+
+
+
+
+
Field
+
.spec.definition.hostFileVolumes
+
+
+
Description
+
Flag to specify the host file volumes to the ChaosPod
+
+
+
Type
+
Optional
+
+
+
Range
+
user-defined (type:map[string]string)
+
+
+
Default
+
n/a
+
+
+
Notes
+
The .spec.definition.hostFileVolumes allows the developer to specify the host file volumes to the ChaosPod.
+
+
+
+
+
+
Field
+
.spec.definition.hostPID
+
+
+
Description
+
Flag to specify the host PID for the ChaosPod
+
+
+
Type
+
Optional
+
+
+
Range
+
true, false (type:bool)
+
+
+
Default
+
n/a
+
+
+
Notes
+
The .spec.definition.hostPID allows the developer to specify the host PID for the ChaosPod.
+
+
diff --git a/website/versioned_docs/version-2.13.0/concepts/chaos-result.md b/website/versioned_docs/version-2.13.0/concepts/chaos-result.md
new file mode 100644
index 0000000..37f1758
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/concepts/chaos-result.md
@@ -0,0 +1,349 @@
+---
+id: chaos-result
+title: ChaosResult
+sidebar_label: ChaosResult
+---
+
+---
+
+ChaosResult resource holds the results of a ChaosExperiment with a namespace scope. It is created or updated at runtime by the experiment itself. It holds important information like the ChaosEngine reference, Experiment State, Verdict of the experiment (on completion), salient application/result attributes. It is also a source for metrics collection. It is updated/patched with the status of the experiment run. It is not removed as part of the default cleanup procedures to allow for extended reference.
+
+## Prerequisites
+
+To understand the concept of ChaosResult, make sure you have good knowledge of the [ChaosEngine](chaos-engine.md) CR and
+[Chaos Scenario](chaos-workflow.md).
+
+## ChaosResult Spec
+
+This section describes the fields/details provided by the ChaosResult spec.
+
+### Component Details
+
+
+
+
Field
+
.spec.engine
+
+
+
Description
+
Flag to hold the ChaosEngine name for the experiment
+
+
+
Type
+
Optional
+
+
+
Range
+
n/a (type: string)
+
+
+
Notes
+
The .spec.engine holds the engine name for the current course of the experiment.
+
+
+
+
+
+
Field
+
.spec.experiment
+
+
+
Description
+
Flag to hold the ChaosExperiment name which induces chaos.
+
+
+
Type
+
Optional
+
+
+
Range
+
n/a (type: string)
+
+
+
Notes
+
The .spec.experiment holds the ChaosExperiment name for the current course of the experiment.
+
+
+
+### Status Details
+
+
+
+
Field
+
.status.experimentStatus.failstep
+
+
+
Description
+
Flag to show the failure step of the ChaosExperiment
+
+
+
Type
+
Mandatory
+
+
+
Range
+
n/a(type: string)
+
+
+
Notes
+
The .status.experimentStatus.failstep Show the step at which the experiment failed. It helps in faster debugging of failures in the experiment execution.
+
+
+
+
+
+
Field
+
.status.experimentStatus.phase
+
+
+
Description
+
Flag to show the current phase of the experiment
+
+
+
Type
+
Mandatory
+
+
+
Range
+
Awaited,Running,Completed,Aborted (type: string)
+
+
+
Notes
+
The .status.experimentStatus.phase shows the current phase in which the experiment is. It gets updated as the experiment proceeds.If the experiment is aborted then the status will be Aborted.
+
+
+
+
+
+
Field
+
.status.experimentStatus.probesuccesspercentage
+
+
+
Description
+
Flag to show the probe success percentage
+
+
+
Type
+
Mandatory
+
+
+
Range
+
1 to 100 (type: int)
+
+
+
Notes
+
The .status.experimentStatus.probesuccesspercentage shows the probe success percentage which is a ratio of successful checks v/s total probes.
+
+
+
+
+
+
Field
+
.status.experimentStatus.verdict
+
+
+
Description
+
Flag to show the verdict of the experiment.
+
+
+
Type
+
Mandatory
+
+
+
Range
+
Awaited,Pass,Fail,Stopped (type: string)
+
+
+
Notes
+
The .status.experimentStatus.verdict shows the verdict of the experiment. It is Awaited when the experiment is in progress and ends up with Pass or Fail according to the experiment result.
+
+
+
+
+
+
Field
+
.status.history.passedRuns
+
+
+
Description
+
It contains cumulative passed run count
+
+
+
Type
+
Mandatory
+
+
+
Range
+
ANY NON NEGATIVE INTEGER
+
+
+
Notes
+
The .status.history.passedRuns contains cumulative passed run counts for a specific ChaosResult.
+
+
+
+
+
+
Field
+
.status.history.failedRuns
+
+
+
Description
+
It contains cumulative failed run count
+
+
+
Type
+
Mandatory
+
+
+
Range
+
ANY NON NEGATIVE INTEGER
+
+
+
Notes
+
The .status.history.failedRuns contains cumulative failed run counts for a specific ChaosResult.
+
+
+
+
+
+
Field
+
.status.history.stoppedRuns
+
+
+
Description
+
It contains cumulative stopped run count
+
+
+
Type
+
Mandatory
+
+
+
Range
+
ANY NON NEGATIVE INTEGER
+
+
+
Notes
+
The .status.history.stoppedRuns contains cumulative stopped run counts for a specific ChaosResult.
+
+
+
+### Probe Details
+
+
+
+
Field
+
.status.probestatus.name
+
+
+
Description
+
Flag to show the name of probe used in the experiment
+
+
+
Type
+
Mandatory
+
+
+
Range
+
n/a n/a (type: string)
+
+
+
Notes
+
The .status.probestatus.name shows the name of the probe used in the experiment.
+
+
+
+
+
+
Field
+
.status.probestatus.status.continuous
+
+
+
Description
+
Flag to show the result of probe in continuous mode
+
+
+
Type
+
Optional
+
+
+
Range
+
Awaited,Passed,Better Luck Next Time (type: string)
+
+
+
Notes
+
The .status.probestatus.status.continuous helps to get the result of the probe in the continuous mode. The httpProbe is better used in the Continuous mode.
+
+
+
+
+
+
Field
+
.status.probestatus.status.postchaos
+
+
+
Description
+
Flag to show the probe result post chaos
+
+
+
Type
+
Optional
+
+
+
Range
+
Awaited,Passed,Better Luck Next Time (type:map[string]string)
+
+
+
Notes
+
The .status.probestatus.status.postchaos shows the result of probe setup in EOT mode executed at the End of Test as a post-chaos check.
+
+
+
+
+
+
Field
+
.status.probestatus.status.prechaos
+
+
+
Description
+
Flag to show the probe result pre chaos
+
+
+
Range
+
Awaited,Passed,Better Luck Next Time (type:string)
+
+
+
Notes
+
The .status.probestatus.status.prechaos shows the result of probe setup in SOT mode executed at the Start of Test as a pre-chaos check.
+
+
+
+
+
+
Field
+
.status.probestatus.type
+
+
+
Description
+
Flag to show the type of probe used
+
+
+
Range
+
+HTTPProbe,K8sProbe,CmdProbe(type:string)
+
+
+
Notes
+
The .status.probestatus.type shows the type of probe used.
+
+
+
+## Summary
+
+Just like the ChaosExperiment CR and ChaosEngine CR, ChaosResult is a Custom Resource provided by Litmus.
+ChaosResult resource holds the results of a ChaosExperiment. It comprises of some important information related to the experiment execution like Experiment Details, Verdict, Phase, ProbeSuccessPercentage etc. It is updated/patched with every experiment run. It can also be used as a source for matrics collection.
+
+## Learn More
+
+- [Run a Chaos Scenario](../getting-started/run-your-first-workflow.md)
+- [Observe a chaos scenario](visualize-workflow.md)
diff --git a/website/versioned_docs/version-2.13.0/concepts/chaos-workflow.md b/website/versioned_docs/version-2.13.0/concepts/chaos-workflow.md
new file mode 100644
index 0000000..24b4a03
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/concepts/chaos-workflow.md
@@ -0,0 +1,426 @@
+---
+id: chaos-workflow
+title: Chaos Scenario
+sidebar_label: Chaos Scenario
+---
+
+---
+
+**Chaos Scenario** 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 Scenario can also be used to perform different operations parallelly to achieve a desired chaos injection scenario.
+
+## Prerequisites
+
+The following should be required before creating a Chaos Scenario:
+
+- [ChaosCenter](../getting-started/resources.md#chaoscenter)
+- [Chaos Delegate](../getting-started/resources.md#chaosagents)
+- [Chaos Experiment CR](chaos-experiment.md)
+- [ChaosEngine CR](chaos-engine.md)
+- [Probes](probes.md)
+
+## How do we define and execute a Chaos Scenario ?
+
+LitmusChaos leverages the popular chaos scenario and GitOps tool **Argo** to achieve this goal. Argo enables the creation of different chaos scenarios together in from of chaos scenarios which are extremly simple and efficient to use.
+With the help of **ChaosCenter**, chaos scenarios with different type of experiments can be created. In a Chaos Scenario, the experiments can be added in a parallel way and the user can tune the chaos scenario by adding additional steps to simulate a desired fault that might occur in production stage.
+
+### Life Cycle of a Chaos Scenario
+
+Here is a sample pod-delete chaos scenario from ChaosCenter.
+
+```yaml
+apiVersion: argoproj.io/v1alpha1
+kind: Workflow
+metadata:
+ name: custom-chaos-workflow-1627980541
+ namespace: litmus
+ labels:
+ subject: custom-chaos-workflow_litmus
+spec:
+ arguments:
+ parameters:
+ - name: adminModeNamespace
+ value: litmus
+ entrypoint: custom-chaos
+ securityContext:
+ runAsNonRoot: true
+ runAsUser: 1000
+ serviceAccountName: argo-chaos
+ templates:
+ - name: custom-chaos
+ steps:
+ - - name: install-chaos-experiments
+ template: install-chaos-experiments
+ - - name: pod-delete
+ template: pod-delete
+ - - name: revert-chaos
+ template: revert-chaos
+ - name: install-chaos-experiments
+ inputs:
+ artifacts:
+ - name: pod-delete
+ path: /tmp/pod-delete.yaml
+ raw:
+ data: >
+ apiVersion: litmuschaos.io/v1alpha1
+
+ description:
+ message: |
+ Deletes a pod belonging to a deployment/statefulset/daemonset
+ kind: ChaosExperiment
+
+ metadata:
+ name: pod-delete
+ labels:
+ name: pod-delete
+ app.kubernetes.io/part-of: litmus
+ app.kubernetes.io/component: chaosexperiment
+ app.kubernetes.io/version: 1.13.8
+ spec:
+ definition:
+ scope: Namespaced
+ permissions:
+ - apiGroups:
+ - ""
+ - apps
+ - apps.openshift.io
+ - argoproj.io
+ - batch
+ - litmuschaos.io
+ resources:
+ - deployments
+ - jobs
+ - pods
+ - pods/log
+ - replicationcontrollers
+ - deployments
+ - statefulsets
+ - daemonsets
+ - replicasets
+ - deploymentconfigs
+ - rollouts
+ - pods/exec
+ - events
+ - chaosengines
+ - chaosexperiments
+ - chaosresults
+ verbs:
+ - create
+ - list
+ - get
+ - patch
+ - update
+ - delete
+ - deletecollection
+ image: litmuschaos/go-runner:1.13.8
+ imagePullPolicy: Always
+ args:
+ - -c
+ - ./experiments -name pod-delete
+ command:
+ - /bin/bash
+ env:
+ - name: TOTAL_CHAOS_DURATION
+ value: "15"
+ - name: RAMP_TIME
+ value: ""
+ - name: FORCE
+ value: "true"
+ - name: CHAOS_INTERVAL
+ value: "5"
+ - name: PODS_AFFECTED_PERC
+ value: ""
+ - name: LIB
+ value: litmus
+ - name: TARGET_PODS
+ value: ""
+ - name: SEQUENCE
+ value: parallel
+ labels:
+ name: pod-delete
+ app.kubernetes.io/part-of: litmus
+ app.kubernetes.io/component: experiment-job
+ app.kubernetes.io/version: 1.13.8
+ container:
+ args:
+ - kubectl apply -f /tmp/pod-delete.yaml -n
+ {{workflow.parameters.adminModeNamespace}} | sleep 30
+ command:
+ - sh
+ - -c
+ image: litmuschaos/k8s:latest
+ - name: pod-delete
+ inputs:
+ artifacts:
+ - name: pod-delete
+ path: /tmp/chaosengine-pod-delete.yaml
+ raw:
+ data: |
+ apiVersion: litmuschaos.io/v1alpha1
+ kind: ChaosEngine
+ metadata:
+ namespace: "{{workflow.parameters.adminModeNamespace}}"
+ generateName: pod-delete
+ labels:
+ instance_id: 86a4f130-d99b-4e91-b34b-8f9eee22cb63
+ spec:
+ appinfo:
+ appns: default
+ applabel: app=nginx
+ appkind: deployment
+ jobCleanUpPolicy: retain
+ engineState: active
+ chaosServiceAccount: litmus-admin
+ experiments:
+ - name: pod-delete
+ spec:
+ components:
+ env:
+ - name: TOTAL_CHAOS_DURATION
+ value: "30"
+ - name: CHAOS_INTERVAL
+ value: "10"
+ - name: FORCE
+ value: "false"
+ - name: PODS_AFFECTED_PERC
+ value: ""
+ container:
+ args:
+ - -file=/tmp/chaosengine-pod-delete.yaml
+ - -saveName=/tmp/engine-name
+ image: litmuschaos/litmus-checker:latest
+ - name: revert-chaos
+ container:
+ image: litmuschaos/k8s:latest
+ command:
+ - sh
+ - -c
+ args:
+ - "kubectl delete chaosengine -l 'instance_id in
+ (86a4f130-d99b-4e91-b34b-8f9eee22cb63, )' -n
+ {{workflow.parameters.adminModeNamespace}} "
+ podGC:
+ strategy: OnWorkflowCompletion
+```
+
+The structure of a chaos scenario is similar to that of a Kubernetes Object. It consists of the mandatory fields like `apiVersion`, `kind`, `metadata`, `spec`.
+
+The **spec** in a Chaos Scenario is where the different steps are mentioned and the overall life cycle of the chaos scenario is described.
+We can see different `templates` are present in the spec of a chaos scenario.
+
+```
+templates:
+ - name: custom-chaos
+ steps:
+ - - name: install-chaos-experiments
+ template: install-chaos-experiments
+ - - name: pod-delete
+ template: pod-delete
+ - - name: revert-chaos
+ template: revert-chaos
+```
+
+Here in this template, we can see different steps are present.
+These include installing the chaos experiments, executing the chaos engine of the experiment and at the end we have the revert chaos step which deletes/removes the resources that were created as part of the chaos scenario.
+
+Some additional checks can be added with the experiments in the form of probes. These probes are defined in the ChaosEngines of the experiment and are updated when the experiment execution takes place.
+The overall chaos scenario 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?
+
+A chaos scenario run can be defined as single/one-time execution of the chaos scenario. There can be multiple runs of a single chaos scenario. If the chaos scenario consists of a cron syntax, it will run periodically according to the cron provided in the chaos scenario.
+
+## What is Resiliency Score?
+
+**Resiliency score** is the measure of how resilient is the chaos scenario when different chaos scenarios are performed on the Kubernetes System.
+
+While creating a chaos scenario, certain weights are assigned to all the experiments present in the chaos scenario. These weights signify the priority/importance of the experiment. The higher the weight, the more significant is the experiment.
+
+In ChaosCenter, the weight priority is generally divided into three sections:
+
+- 0-3: Low Priority
+- 4-6: Medium Priority
+- 7-10: High Priority
+
+Once a weight has been assigned to the experiment, we look for the Probe Success Percentage for that experiment itself (Post Chaos) and calculate the total resilience result for that experiment as a multiplication of the weight given and the probe success percentage returned after the Chaos Run.
+
+```
+Total Resilience for one single experiment = (Weight Given to that experiment * Probe Success Percentage)
+Overall Resilience Score = Total Test Result / Sum of the assigned weights of the experiments
+```
+
+## What is a Cron Chaos Scenario?
+
+Cron Chaos Scenario is a type of chaos scenario 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 scenario execution takes
+place.
+
+Here's a sample Cron Chaos Scenario for Podtato-Head application:
+
+```yaml
+apiVersion: argoproj.io/v1alpha1
+kind: CronWorkflow
+metadata:
+ name: podtato-head-1628058291
+ namespace: litmus
+ labels:
+ subject: podtato-head_litmus
+spec:
+ schedule: 10 0-23 * * *
+ concurrencyPolicy: Forbid
+ startingDeadlineSeconds: 0
+ workflowSpec:
+ entrypoint: argowf-chaos
+ serviceAccountName: argo-chaos
+ securityContext:
+ runAsUser: 1000
+ runAsNonRoot: true
+ arguments:
+ parameters:
+ - name: adminModeNamespace
+ value: litmus
+ templates:
+ - name: argowf-chaos
+ steps:
+ - - name: install-application
+ template: install-application
+ - - name: install-chaos-experiments
+ template: install-chaos-experiments
+ - - name: pod-delete
+ template: pod-delete
+ - - name: revert-chaos
+ template: revert-chaos
+ - name: delete-application
+ template: delete-application
+ - name: install-application
+ container:
+ image: litmuschaos/litmus-app-deployer:latest
+ args:
+ - -namespace={{workflow.parameters.adminModeNamespace}}
+ - -typeName=resilient
+ - -operation=apply
+ - -timeout=400
+ - -app=podtato-head
+ - -scope=namespace
+ - name: install-chaos-experiments
+ container:
+ image: litmuschaos/k8s:latest
+ command:
+ - sh
+ - -c
+ args:
+ - kubectl apply -f
+ https://hub.litmuschaos.io/api/chaos/1.13.7?file=charts/generic/experiments.yaml
+ -n {{workflow.parameters.adminModeNamespace}} ; sleep 30
+ - name: pod-delete
+ inputs:
+ artifacts:
+ - name: pod-delete
+ path: /tmp/chaosengine.yaml
+ raw:
+ data: >
+ apiVersion: litmuschaos.io/v1alpha1
+
+ kind: ChaosEngine
+
+ metadata:
+ namespace: "{{workflow.parameters.adminModeNamespace}}"
+ labels:
+ instance_id: 1b7ec920-75f9-4398-b4c3-9c3a5d7fd5c2
+ generateName: podtato-main-pod-delete-chaos
+ spec:
+ appinfo:
+ appns: "{{workflow.parameters.adminModeNamespace}}"
+ applabel: name=podtato-main
+ appkind: deployment
+ engineState: active
+ chaosServiceAccount: litmus-admin
+ jobCleanUpPolicy: retain
+ components:
+ runner:
+ imagePullPolicy: Always
+ experiments:
+ - name: pod-delete
+ spec:
+ probe:
+ - name: check-podtato-main-access-url
+ type: httpProbe
+ httpProbe/inputs:
+ url: http://podtato-main.{{workflow.parameters.adminModeNamespace}}.svc.cluster.local:9000
+ insecureSkipVerify: false
+ method:
+ get:
+ criteria: ==
+ responseCode: "200"
+ mode: Continuous
+ runProperties:
+ probeTimeout: 1
+ interval: 1
+ retry: 1
+ components:
+ env:
+ - name: TOTAL_CHAOS_DURATION
+ value: "30"
+ - name: CHAOS_INTERVAL
+ value: "10"
+ - name: FORCE
+ value: "false"
+ container:
+ image: litmuschaos/litmus-checker:latest
+ args:
+ - -file=/tmp/chaosengine.yaml
+ - -saveName=/tmp/engine-name
+ - name: delete-application
+ container:
+ image: litmuschaos/litmus-app-deployer:latest
+ args:
+ - -namespace={{workflow.parameters.adminModeNamespace}}
+ - -typeName=resilient
+ - -operation=delete
+ - -app=podtato-head
+ - name: revert-chaos
+ container:
+ image: litmuschaos/k8s:latest
+ command:
+ - sh
+ - -c
+ args:
+ - "kubectl delete chaosengine -l 'instance_id in
+ (1b7ec920-75f9-4398-b4c3-9c3a5d7fd5c2, )' -n
+ {{workflow.parameters.adminModeNamespace}} "
+ timezone: Asia/Calcutta
+```
+
+In the above chaos scenario, we can see the cron syntax at `spec.schedule` is
+
+```
+spec:
+ schedule: 10 0-23 * * *
+```
+
+This means the chaos scenario will be executed at the 10th minute of every hour.
+
+A chaos scenario can be changed into Cron Chaos Scenario from the ChaosCenter.
+While scheduling a chaos scenario, in the `Schedule` step, there are few options as part of Recurring Schedules. These include:
+
+- Every hour
+- Every Day
+- Every Week
+- Every Month
+
+## Summary
+
+Chaos Scenario is combination of different steps combined together to perfrom a specific chaos use-case on a Kubernetes system. These steps can include install experiment steps, ChaosEngine CR for target selection, revert-chaos steps etc. Chaos Scenarios can be scheduled for a later time with the help of Cron Chaos Scenarios.
+These chaos scenarios consist of a cron syntax that is used for scheduling a chaos scenario. Once the chaos scenario execution is completed, the resiliency of the targeted application is calculated. Several weights are assigned to different experiments in the chaos scenario. These weights are used along with the ProbeSuccessPercentage to find out the resiliency score.
+
+## Resources
+
+
+
+
+
+## Learn More
+
+- [Explore Probes](probes.md)
+- [Visualize a Chaos Scenario](visualize-workflow.md)
+- [Examine the ChaosResult](chaos-result.md)
diff --git a/website/versioned_docs/version-2.13.0/concepts/chaoshub.md b/website/versioned_docs/version-2.13.0/concepts/chaoshub.md
new file mode 100644
index 0000000..a0ac4d8
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/concepts/chaoshub.md
@@ -0,0 +1,104 @@
+---
+id: chaoshub
+title: ChaosHub
+sidebar_label: ChaosHub
+---
+
+---
+
+ChaosHub allows you to orchestrate chaos scenarios 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 experiments).
+
+## Prerequisites
+
+The following are the prerequisites for creating a Chaos Scenario:
+
+- Fork of [Chaos-Charts](https://github.com/litmuschaos/chaos-charts) repository
+
+:::note
+An active internet connection is required to clone the git repository for the first time installation.
+:::
+
+## Connecting a Git repository using ChaosHub
+
+With ChaosHub, you can construct chaos scenarios by selecting, tuning and sequencing different experiments 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.
+
+
+
+### 1. Connect a Public Git Repository
+
+You can connect to a public Git repository by simply providing the following details:
+
+- Hub Name
+- Git URL of the forked repository
+- Branch Name
+
+
+
+### 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:
+
+
+
+#### a. Access Token
+
+Personal Access Tokens are used as an alternative to the password for authentication to Git services.
+
+#### 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.
+
+
+
+## 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.
+
+## 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 Scenarios and Experiments in a ChaosHub
+
+### 1. View the PreDefined Chaos Scenarios
+
+After connecting a ChaosHub, you can view the different pre-defined chaos scenarios present in the ChaosHub.
+
+
+
+### 2. View the Chaos-Experiments
+
+Similarly, you can view the different charts and the experiment. These charts are sorted according to different categories like generic, aws, azure, kube-components etc.
+
+
+
+### 3. View the experiment details
+
+You can select one of the chaos experiment and can examine the experiment details.
+The experiment page consists of all the important details like the description of the experiment, a tutorial video, the maintainer of the experiment etc.
+You can also find experiment yaml link, RBAC link and the ChaosEngine yaml link of the experiment.
+These yaml links are required for the creation of Custom Chaos Scenarios.
+
+
+
+## Disconnect a ChaosHub
+
+To remove a ChaosHub from a project, you can select the **Disconnect Hub** option from the ChaosHub card.
+
+## Summary
+
+ChaosHubs are basically a collection of different clones of the Chaos-Charts repository, which consists of a variety of experiments and pre-defined chaos scenarios. You can use a ChaosHub to construct a custom chaos scenarios and tune it according to the use-case. These ChaosHubs can also be synced with the latest changes. New experiments and pre-defined chaos scenarios can also be added in the repository which can be directly used in the ChaosCenter.
+
+## Resources
+
+
+
+## Learn More
+
+- [What is a Chaos Scenario](chaos-workflow.md)
+- [Examine the ChaosResult](chaos-result.md)
diff --git a/website/versioned_docs/version-2.13.0/concepts/datasource.md b/website/versioned_docs/version-2.13.0/concepts/datasource.md
new file mode 100644
index 0000000..9faaf4b
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/concepts/datasource.md
@@ -0,0 +1,51 @@
+---
+id: datasource
+title: Manage Datasources
+sidebar_label: Datasource
+---
+
+---
+
+The primary stateful data store for litmus's chaos center is a mongoDB statefulset. It powers all the features in chaos center including authentication, chaos injection and analysis, chaos delegate connections etc. Apart from the primary data store, the portal provides a way to add Prometheus (TSDB) data sources for time series data visualization and monitoring. The principle of Open observability drives the chaos center and allows users to manage the data sources for a project in multiple topologies for chaos delegate specific and cross chaos delegate dashboards. The system allows to either have multiple data sources or a single data source scraping metrics and events from all target chaos delegates for monitoring chaos impact on
+application OR infrastructure.
+
+## Prerequisites
+
+The following should be required before knowing about managing data sources in chaos center:
+
+- [Running Chaos Scenarios](../getting-started/run-your-first-workflow.md)
+- [Prometheus TSDB](https://prometheus.io/)
+
+## Data flow architecture
+
+The chaos center provides the functionality to connect multiple prometheus data sources across projects to harness insights on application or system behavior during chaos manifested on real-time monitoring dashboards. Litmus follows an open observability model which enables users to plug metrics from any Prometheus exporter into the data source connected to a chaos center project to visualize the same on dashboards. Along with system and application metrics the metrics exposed by `chaos-exporter` service (a prometheus metrics exporter for chaos injection events and results or verdicts) on the execution plane or target chaos delegate's cluster is necessary to be ingested into the same data source to be connected to the project in order to facilitate chaos interleaving. Existing monitoring infrastructure for observing the target chaos delegate's cluster can also be used if it is prometheus based, plugging the metrics from `chaos-exporter` in such cases should be sufficient.
+
+
+
+Data flow from data sources
+
+
+## Health check for Time-series database
+
+The query timeout is used for all the queries associated with all the dashboards connected to the given data source, including querying data while editing the dashboard queries, although the default request timeout for the health check of the data source while connecting, updating or listing it is `5 seconds`.
+
+## Scrape interval
+
+The scrape interval is used to control the lower limit of minStep for queries multiplying by denominator of query resolution for a dashboard consuming the data source; the same might be used for limiting the refresh rate for dashboard views with relative time range in later versions of the Litmus center.
+
+## Supported versions
+
+The Litmus center supports Prometheus 2.1 or later.
+
+## Summary
+
+LitmusChaos facilitates in-house real-time monitoring for `events` and `verdicts` metrics exposed by the native `chaos-exporter` for each target chaos delegate. These events and metrics can be scraped from a Prometheus TSDB connected to chaos center to overlay on top of application performance and infrastructure monitoring graphs. Some considerations for health-check, metrics scraping interval and version support have been stated.
+
+## Resources
+
+
+
+## Learn More
+
+- [Visualize a Chaos Scenario](visualize-workflow.md)
+- [Application and infrastructure monitoring](app-infra-monitoring.md)
diff --git a/website/versioned_docs/version-2.13.0/concepts/gitops.md b/website/versioned_docs/version-2.13.0/concepts/gitops.md
new file mode 100644
index 0000000..30dc885
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/concepts/gitops.md
@@ -0,0 +1,48 @@
+---
+id: gitops
+title: Litmus with GitOps
+sidebar_label: GitOps
+---
+
+---
+
+## Prerequisites
+
+- Chaos Delegate
+- [Chaos Scenario](chaos-workflow.md)
+
+GitOps feature in Litmus enables you to configure a single source of truth for your chaos scenarios and experiments, any changes made either to the artifacts stored in the configured git repository or the portal will be synced. This allows you to create and execute chaos scenarios directly from git enabling a vast scope of automation in CI/CD pipelines.
+
+## Event-Driven Chaos Injection
+
+Besides the sync feature, GitOps in Litmus provides a way of using Event-Driven Chaos Injection, where target resources(stateful sets, deployments, etc.) can be configured to automatically trigger chaos scenarios with any changes in the resource spec. Currently, the event supported for chaos injection is resource image change, configuration change, change in replicas, and many more.
+The event-driven chaos injection allows Litmus to be integrated with traditional GitOps flow that involves automated deployment of applications or workloads, for example, you can now automatically trigger chaos scenarios whenever a new release is created for your application and is deployed by a continuous delivery system.
+
+
+
+In Litmus, there are two components, the external cluster(blue cluster) which is the target chaos delegate and can be more than one, other is the self chaos delegate where the Litmus(red cluster) is installed. After an chaos delegate is connected to Litmus, an event-tracker pod will be installed which is responsible for event-driven chaos injection by tracking the changes in your target application.
+
+> Event tracker is a policy-driven Kubernetes controller, where one can define N number of policies. It can track updates to statefulset, deployment, daemonset and it notifies the graphql server regarding the updates.
+
+
+
+In the above architecture, the Event-tracker pod tracks the Web App continuously, if any change occurs (for eg: App version changes from V1 to V2), it gets triggered and informs the graphql-server pod, the server will then try to look for the chaos scenario using `workflow_id` from the git repository. Once it gets the required chaos scenario, it will send it to the subscriber which is responsible for applying the chaos scenario into the target cluster. After the chaos scenario run is completed you can check the resiliency of your application.
+
+The event-tracker is not tracking all the applications, you need to annotate the particular application:
+
+- `litmuschaos.io/gitops=true` , to enable the GitOps.
+- `litmuschaos.io/workflow="WORKFLOW-ID"`, where `WORKFLOW-ID` is chaos scenario identity which will be subscribed by the target application deployment and it is present in the chaos scenario label.
+
+GitOps is by default disabled for the projects created in Litmus, but it can be enabled and configured from the `GitOps` tab in `Settings` in ChaosCenter.
+
+## Resources
+
+
+
+
+
+## Learn More
+
+- [Configuring GitOps](../user-guides/gitops-configuration.md)
+- [Schedule a chaos scenario](../user-guides/schedule-workflow.md)
+- [Observe a Chaos Scenario](../user-guides/observe-workflow.md)
diff --git a/website/versioned_docs/version-2.13.0/concepts/oauth-dex-concept.md b/website/versioned_docs/version-2.13.0/concepts/oauth-dex-concept.md
new file mode 100644
index 0000000..eef0d15
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/concepts/oauth-dex-concept.md
@@ -0,0 +1,44 @@
+---
+id: oauth-dex-concept
+title: Authentication process in ChaosCenter
+sidebar_label: Authentication in ChoasCenter
+---
+
+---
+
+## Prerequisites
+
+- [OAuth](https://oauth.net/specs/)
+
+ChaosCenter allows OAuth as well as local authentication using Dex and the authentication server.
+
+
+## Authentication Architecture
+
+
+
+
+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.
+
+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.
+
+
+## Resources
+
+- [Deploying OAuth in ChaosCenter](../user-guides/chaoscenter-oauth-dex-installation.md)
+
+
+
+
+
+
+
+
+
diff --git a/website/versioned_docs/version-2.13.0/concepts/open-observability.md b/website/versioned_docs/version-2.13.0/concepts/open-observability.md
new file mode 100644
index 0000000..62f2015
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/concepts/open-observability.md
@@ -0,0 +1,71 @@
+---
+id: open-observability
+title: Open Observability
+sidebar_label: Open Observability
+---
+
+---
+
+Litmus 2.0 builds on principle of Open observability through observability hooks such as probes to validate steady state hypothesis along with chaos injection. Chaos exporter also provides prometheus metrics which can be used to generate alerts based on events and also to view chaos impact and application performance in terms of probe success percentage and experiment verdict. It provides for several integration points with Prometheus's alert manager and Grafana, also for the in-house application and infrastructure monitoring capabilities with chaos events, metadata and results.
+
+## Prerequisites
+
+The following should be required before knowing about Open observability hooks in litmus 2.0:
+
+- [Probes](probes.md)
+- [Application / Infra. monitoring](app-infra-monitoring.md)
+
+## Probes
+
+Litmus probes are pluggable checks that can be defined within the ChaosEngine for any chaos experiment. The experiment pods execute these checks based on the mode they are defined in & factor their success as necessary conditions in determining the verdict of the experiment (along with the standard `in-built` checks).
+
+_Litmus currently supports four types of probes:_
+
+- **httpProbe:** To query health/downstream URIs
+- **cmdProbe:** To execute any user-desired health-check function implemented as a shell command
+- **k8sProbe:** To perform CRUD operations against native & custom Kubernetes resources
+- **promProbe:** To execute promql queries and match prometheus metrics for specific criteria
+
+These probes can be used in isolation or in several combinations to achieve the desired checks.
+
+More about Probes can be found [here](probes.md)
+
+## Chaos exporter
+
+Chaos exporter is a custom `Prometheus` and `CloudWatch` exporter to expose Litmus Chaos metrics. Typically deployed along with the chaos-operator deployment, which, in-turn is associated with all `chaosresults` in the cluster.
+
+_Two types of metrics are exposed:_
+
+#### AggregateMetrics:
+
+These metrics are derived from all the `chaosresults` present inside WATCH_NAMESPACE. If WATCH_NAMESPACE is not defined then it derives metrics from all namespaces. It exposes total_passed_experiment, total_failed_experiment, total_awaited_experiment, experiment_run_count, experiment_installed_count metrics.
+
+#### ExperimentScoped:
+
+Individual experiment run status. It exposes passed_experiment, failed_experiment, awaited_experiment, probe_success_percentage, startTime, endTime, totalDuration, chaosInjectTime metrics
+
+All metrics exported from chaos exporter can be found [here](https://github.com/litmuschaos/chaos-exporter)
+
+## Integrations
+
+- [Prometheus](../integrations/prometheus)
+
+- [Grafana](../integrations/grafana)
+
+- [AlertManager](https://github.com/litmuschaos/tutorials/issues/6)
+
+## Summary
+
+Litmus supports several kinds of `probes` and also has a `chaos-exporter` on it's execution plane on the chaos delegate's cluster which is essential for interleaved monitoring, integrated alerts and to hook into existing observability infrastructure. Chaos experimentation is a lot about hypothesizing around the application and/or infrastructure behavior, controlling blast radius & measuring SLOs. SREs love to visualize the impact of chaos - either actively (live) or recorded (as with automated chaos tests)
+
+## Resources
+
+[Observability Considerations in Chaos: The Metrics Story](https://dev.to/ksatchit/observability-considerations-in-chaos-the-metrics-story-6cb)
+
+[Monitoring Litmus Chaos Experiments](https://dev.to/ksatchit/monitoring-litmus-chaos-experiments-198a)
+
+## Learn More
+
+- [Prometheus](../integrations/prometheus)
+- [Grafana](../integrations/grafana)
+- [Application and infrastructure monitoring](app-infra-monitoring.md)
diff --git a/website/versioned_docs/version-2.13.0/concepts/overview.md b/website/versioned_docs/version-2.13.0/concepts/overview.md
new file mode 100644
index 0000000..34233aa
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/concepts/overview.md
@@ -0,0 +1,53 @@
+---
+id: overview
+title: Overview
+sidebar_label: Overview
+---
+
+---
+
+The Concepts section contains Definitions, Design principles, Terminology and Working technical theory. This section will not have the actual usage instructions or guides those will be made available in the [User Guides](../user-guides/overview.md) section.
+
+### [Chaos Experiment](chaos-experiment.md)
+
+ChaosExperiment CR is the heart of litmus and contains the low-level execution information.
+
+### [Probes](probes.md)
+
+Probes are pluggable checks that can be defined within the ChaosEngine for any Chaos Experiment.
+
+### [ChaosEngine](chaos-engine.md)
+
+The ChaosEngine CR is the main user-facing chaos custom resource with a namespace scope and is designed to hold information around how the chaos experiments are executed.
+
+### [ChaosResult](chaos-result.md)
+
+ChaosResult resource holds the results of a ChaosExperiment with a namespace scope.
+
+### [ChaosHub](chaoshub.md)
+
+ChaosHub allows you to orchestrate chaos scenarios from the Public **[ChaosHub](http://hub.litmuschaos.io/)** or an alternate source for the Experiments.
+
+### [Chaos Scenario](chaos-workflow.md)
+
+Chaos Scenario is a set of different operations coupled together to achieve desired chaos impact on a Kubernetes Cluster.
+
+### [Observability](workflow-statistics.md)
+
+Monitoring and observability during and post chaos using built-in Litmus analytics dashboard as well as external observability tools.
+
+### [User Management](user-management.md)
+
+Role Privileges of different users in the ChaosCenter.
+
+### [Projects](projects.md)
+
+Project management system which can be used for working on chaos scenario with multiple different projects across different chaos delegates.
+
+### [Teaming](probes.md)
+
+Teaming feature to facilitate collaboration between users using project level role access.
+
+### [GitOps](gitops.md)
+
+GitOps feature in Litmus enables you to configure a single source of truth for your chaos scenarios and experiments.
diff --git a/website/versioned_docs/version-2.13.0/concepts/probes.md b/website/versioned_docs/version-2.13.0/concepts/probes.md
new file mode 100644
index 0000000..9a6a3d2
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/concepts/probes.md
@@ -0,0 +1,1133 @@
+---
+id: probes
+title: Probes
+sidebar_label: Probes
+---
+
+---
+
+In Litmus, Probes are pluggable checks that can be defined within the ChaosEngine for any Chaos Experiment. The experiment pods execute these checks based on the mode they are defined in & factor their success as necessary conditions in determining the verdict of the experiment (along with the standard `in-built` checks).
+
+## Prerequisites
+
+To understand the concepts of Probes better make sure you are aware of the [ChaosEngine](chaos-engine.md) Custom Resources and promql queries (for Prometheus Probes)
+
+## Probes
+
+Litmus currently supports four types of Probes:
+
+- **httpProbe**: To query health/downstream URIs
+- **cmdProbe**: To execute any user-desired health-check function implemented as a shell command
+- **k8sProbe**: To perform CRUD operations against native & custom Kubernetes resources
+- **promProbe**: To execute promql queries and match prometheus metrics for specific criteria
+
+These probes can be used in isolation or in several combinations to achieve the desired checks. While the **httpProbe** and **k8sProbe** are **fully declarative** in the way they are conceived, the **cmdProbe** expects the user to provide a shell command to implement checks that are highly specific to the application use case. **promProbe** expects the user to provide a promql query along with Prometheus service endpoints to check for specific criteria.
+
+The probes can be set up to run in different modes:
+
+- **SoT**: Executed at the Start of Test as a pre-chaos check
+- **EoT**: Executed at the End of Test as a post-chaos check
+- **Edge**: Executed both, before and after the chaos
+- **Continuous**: The probe is executed continuously, with a specified polling interval during the chaos injection.
+- **OnChaos**: The probe is executed continuously, with a specified polling interval strictly for chaos duration of chaos
+
+Some common attributes shared between the Probes:
+
+- **probeTimeout**: Represents the time limit for the probe to execute the check specified and return the expected data.
+- **retry**: The number of times a check is re-run upon failure in the first attempt before declaring the probe status as failed.
+- **interval**: The period between subsequent retries
+- **probePollingInterval**: The time interval for which continuous probe should be sleep after each iteration
+- **initialDelaySeconds**: Represents the initial waiting time interval for the probes.
+- **stopOnFailure**: It can be set to true/false to stop or continue the experiment execution after probe fails
+
+:::note
+If probe needs any additional RBAC permissions other than the experiment's serviceAccount `(-sa)` permissions, then the additional permissions should be provided inside the corresponding Role/ClusterRole bind with the serviceAccount `(-sa)`.
+:::
+
+---
+
+## Detailed View of the Probes
+
+### httpProbe
+
+The `httpProbe` allows developers to specify a URL which the experiment 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 `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 experiment pod via a ConfigMap resource, with the ConfigMap name being defined in the [ChaosEngine](chaos-engine.md) OR the ChaosExperiment CR.
+It can be defined at `.spec.experiments[].spec.probe` inside ChaosEngine.
+
+> `body` and `bodyPath` are mutually exclusive
+
+```yaml
+probe:
+ - name: 'check-frontend-access-url'
+ type: 'httpProbe'
+ httpProbe/inputs:
+ url: ''
+ insecureSkipVerify: false
+ responseTimeout: # in milli seconds
+ method:
+ get:
+ criteria: == # supports == & != and oneof operations
+ responseCode: ''
+ mode: 'Continuous'
+ runProperties:
+ probeTimeout: 5
+ interval: 5
+ retry: 1
+ probePollingInterval: 2
+```
+
+The `httpProbe` is better used in the Continuous mode of operation as a parallel liveness indicator of a target or downstream application. It uses the `probePollingInterval` property to specify the polling interval for the access checks.
+
+> `insecureSkipVerify` can be set to true to skip the certificate checks.
+
+### cmdProbe
+
+The `cmdProbe` allows developers to run shell commands and match the resulting output as part of the entry/exit criteria. The intent behind this probe was to allow users to implement a non-standard & imperative way for expressing their hypothesis. For example, the cmdProbe enables you to check for specific data within a database, parse the value out of a JSON blob being dumped into a certain path or check for the existence of a particular string in the service logs.
+
+In order to enable this behaviour, the probe supports an inline mode in which the command is run from within the experiment image as well as a source mode, where the command execution is carried out from within a new pod whose image can be specified. While inline is preferred for simple shell commands, source mode can be used when application-specific binaries are required. The cmdProbe can be defined at `.spec.experiments[].spec.probe` the path inside the ChaosEngine.
+
+```yaml
+probe:
+ - name: 'check-database-integrity'
+ type: 'cmdProbe'
+ cmdProbe/inputs:
+ command: ''
+ comparator:
+ type: 'string' # supports: string, int, float
+ criteria: 'contains' #supports >=,<=,>,<,==,!= for int and contains,equal,notEqual,matches,notMatches for string values
+ value: ''
+ source: # omit this tag to "inline" the probe
+ image: '/'
+ hostNetwork: false
+ mode: 'Edge'
+ runProperties:
+ probeTimeout: 5
+ interval: 5
+ retry: 1
+ initialDelaySeconds: 5
+```
+
+> `source.hostNetwork` can be set to `true` to allow access to the node network namespace for the pod executing the probe
+
+### k8sProbe
+
+With the proliferation of custom resources & operators, especially in the case of stateful applications, the steady-state is manifested as status parameters/flags within Kubernetes resources. k8sProbe addresses verification of the desired resource state by allowing users to define the Kubernetes GVR (group-version-resource) with appropriate filters (field selectors/label selectors). The experiment makes use of the Kubernetes Dynamic Client to achieve this.The `k8sProbe` can be defined at `.spec.experiments[].spec.probe` the path inside ChaosEngine.
+
+It supports following CRUD operations which can be defined at probe.k8sProbe/inputs.operation.
+
+- **create**: It creates kubernetes resource based on the data provided inside `probe.data` field.
+- **delete**: It deletes matching kubernetes resource via GVR and filters (field selectors/label selectors).
+- **present**: It checks for the presence of kubernetes resource based on GVR and filters (field selectors/labelselectors).
+- **absent**: It checks for the absence of kubernetes resource based on GVR and filters (field selectors/labelselectors).
+
+```yaml
+probe:
+ - name: 'check-app-cluster-cr-status'
+ type: 'k8sProbe'
+ k8sProbe/inputs:
+ group: ''
+ version: ''
+ resource: ''
+ namespace: 'default'
+ fieldSelector: 'metadata.name=,status.phase=Running'
+ labelSelector: ''
+ operation: 'present' # it can be present, absent, create, delete
+ mode: 'EOT'
+ runProperties:
+ probeTimeout: 5
+ interval: 5
+ retry: 1
+```
+
+### **promProbe**
+
+The `promProbe` allows users to run Prometheus queries and match the resulting output against specific conditions. The intent behind this probe is to allow users to define metrics-based SLOs in a declarative way and determine the experiment verdict based on its success. The probe runs the query on a Prometheus server defined by the `endpoint`, and checks whether the output satisfies the specified `criteria`.
+
+The promql query can be provided in the `query` field. In the case of complex queries that span multiple lines, the `queryPath` attribute can be used to provide the link to a file consisting of the query. This file can be made available in the experiment pod via a ConfigMap resource, with the ConfigMap being passed in the ChaosEngine OR the ChaosExperiment CR.
+
+> **NOTE:** `query` and `queryPath` are mutually exclusive.
+
+```yaml
+probe:
+ - name: 'check-probe-success'
+ type: 'promProbe'
+ promProbe/inputs:
+ endpoint: ''
+ query: ''
+ comparator:
+ criteria: '==' #supports >=,<=,>,<,==,!= comparision
+ value: ''
+ mode: 'Edge'
+ runProperties:
+ probeTimeout: 5
+ interval: 5
+ retry: 1
+```
+
+
+
+---
+
+## Probe Status & Deriving Inferences
+
+The litmus chaos experiments run the probes defined in the ChaosEngine and update their stage-wise success in the ChaosResult custom resource, with details including the overall `probeSuccessPercentage` (a ratio of successful checks v/s total probes) and failure step, where applicable. The success of a probe is dependent on whether the expected status/results are met and also on whether it is successful in all the experiment phases defined by the probeβs execution mode. For example, probes that are executed in βEdgeβ mode, need the checks to be successful both during the pre-chaos & post-chaos phases to be declared as successful.
+
+The pass criteria for an experiment is the logical conjunction of all probes defined in the ChaosEngine and an inbuilt entry/exit criteria. Failure of either indicates a failed hypothesis and is deemed experiment failure.
+
+Provided below is a ChaosResult snippet containing the probe status for a mixed-probe ChaosEngine.
+
+```yaml
+Name: app-pod-delete
+Namespace: test
+Labels: name=app-pod-delete
+Annotations:
+API Version: litmuschaos.io/v1alpha1
+Kind: ChaosResult
+Metadata:
+ Creation Timestamp: 2020-08-29T08:28:26Z
+ Generation: 36
+ Resource Version: 50239
+ Self Link: /apis/litmuschaos.io/v1alpha1/namespaces/test/ChaosResults/app-pod-delete
+ UID: b9e3638a-b7a4-4b93-bfea-bd143d91a5e8
+Spec:
+ Engine: probe
+ Experiment: pod-delete
+Status:
+ Experimentstatus:
+ Fail Step: N/A
+ Phase: Completed
+ Probe Success Percentage: 100
+ Verdict: Pass
+
+ Probe Status:
+ Name: check-frontend-access-url
+ Status:
+ Continuous: Passed π
+ Type: HTTPProbe
+
+ Name: check-app-cluster-cr-status
+ Status:
+ Post Chaos: Passed π #EoT
+ Type: K8sProbe
+
+ Name: check-database-integrity
+ Status:
+ Post Chaos: Passed π #Edge
+ Pre Chaos: Passed π
+ Type: CmdProbe
+Events:
+ Type Reason Age From Message
+ ---- ------ ---- ---- -------
+ Normal Summary 7s pod-delete-0s2jt6-s4rdx pod-delete experiment has been Passed
+```
+
+
+
+---
+
+## Probe Chaining
+
+Probe chaining enables reuse of probe a result represented by the template function `{{ ..probeArtifact.Register}})` in subsequent "downstream" probes defined in the ChaosEngine. Note that the order of execution of probes in the experiment depends purely on the order in which they are defined in the ChaosEngine.
+
+Probe chaining is currently supported only for `cmdProbes`.
+
+```yaml
+probe:
+ - name: 'probe1'
+ type: 'cmdProbe'
+ cmdProbe/inputs:
+ command: ''
+ comparator:
+ type: 'string'
+ criteria: 'equals'
+ value: ''
+ source: 'inline'
+ mode: 'SOT'
+ runProperties:
+ probeTimeout: 5
+ interval: 5
+ retry: 1
+ - name: 'probe2'
+ type: 'cmdProbe'
+ cmdProbe/inputs:
+ ## probe1's result being used as one of the args in probe2
+ command: ' {{ .probe1.ProbeArtifacts.Register }} '
+ comparator:
+ type: 'string'
+ criteria: 'equals'
+ value: ''
+ source: 'inline'
+ mode: 'SOT'
+ runProperties:
+ probeTimeout: 5
+ interval: 5
+ retry: 1
+```
+
+---
+
+## Probe Schema
+
+This section describes the different fields of the litmus probes and the possible values that can be set against the same. The probes can be defined at `.spec.experiments[].spec.probe` path inside chaosengine.
+
+### Basic Details
+
+
+
+
Field
+
.name
+
+
+
Description
+
Flag to hold the name of the probe
+
+
+
Type
+
Mandatory
+
+
+
Range
+
n/a type: string
+
+
+
Notes
+
The .name holds the name of the probe. It can be set based on the usecase
+
+
+
+
+
+
Field
+
.type
+
+
+
Description
+
Flag to hold the type of the probe
+
+
+
Type
+
Mandatory
+
+
+
Range
+
httpProbe, k8sProbe, cmdProbe, promProbe
+
+
+
Notes
+
The .type supports four type of probes. It can one of the httpProbe, k8sProbe, cmdProbe, promProbe
+
+
+
+
+
+
Field
+
.mode
+
+
+
Description
+
Flag to hold the mode of the probe
+
+
+
Type
+
Mandatory
+
+
+
Range
+
SOT, EOT, Edge, Continuous, OnChaos
+
+
+
Notes
+
The .mode supports five modes of probes. It can one of the SOT, EOT, Edge, Continuous, OnChaos
+
+
+
+
+
+
Field
+
.data
+
+
+
Description
+
Flag to hold the data for the create operation of the k8sProbe
+
+
+
Type
+
Optional
+
+
+
Range
+
n/a type: string
+
+
+
Notes
+
The .data contains the manifest/data for the resource, which need to be created. It supported for create operation of k8sProbe only
+
+
+
+### K8sProbeInputs
+
+
+
+
Field
+
.k8sProbe/inputs.group
+
+
+
Description
+
Flag to hold the group of the kubernetes resource for the k8sProbe
+
+
+
Type
+
Mandatory
+
+
+
Range
+
n/a type: string
+
+
+
Notes
+
The .k8sProbe/inputs.group contains group of the kubernetes resource on which k8sProbe performs the specified operation
+
+
+
+
+
+
Field
+
.k8sProbe/inputs.version
+
+
+
Description
+
Flag to hold the apiVersion of the kubernetes resource for the k8sProbe
+
+
+
Type
+
Mandatory
+
+
+
Range
+
n/a type: string
+
+
+
Notes
+
The .k8sProbe/inputs.version contains apiVersion of the kubernetes resource on which k8sProbe performs the specified operation
+
+
+
+
+
+
Field
+
.k8sProbe/inputs.resource
+
+
+
Description
+
Flag to hold the kubernetes resource name for the k8sProbe
+
+
+
Type
+
Mandatory
+
+
+
Range
+
n/a type: string
+
+
+
Notes
+
The .k8sProbe/inputs.resource contains the kubernetes resource name on which k8sProbe performs the specified operation
+
+
+
+
+
+
Field
+
.k8sProbe/inputs.namespace
+
+
+
Description
+
Flag to hold the namespace of the kubernetes resource for the k8sProbe
+
+
+
Type
+
Mandatory
+
+
+
Range
+
n/a type: string
+
+
+
Notes
+
The .k8sProbe/inputs.namespace contains namespace of the kubernetes resource on which k8sProbe performs the specified operation
+
+
+
+
+
+
Field
+
.k8sProbe/inputs.fieldSelector
+
+
+
Description
+
Flag to hold the fieldSelectors of the kubernetes resource for the k8sProbe
+
+
+
Type
+
Optional
+
+
+
Range
+
n/a type: string
+
+
+
Notes
+
The .k8sProbe/inputs.fieldSelector contains fieldSelector to derived the kubernetes resource on which k8sProbe performs the specified operation
+
+
+
+
+
+
Field
+
.k8sProbe/inputs.labelSelector
+
+
+
Description
+
Flag to hold the labelSelectors of the kubernetes resource for the k8sProbe
+
+
+
Type
+
Optional
+
+
+
Range
+
n/a type: string
+
+
+
Notes
+
The .k8sProbe/inputs.labelSelector contains labelSelector to derived the kubernetes resource on which k8sProbe performs the specified operation
+
+
+
+
+
+
Field
+
.k8sProbe/inputs.operation
+
+
+
Description
+
Flag to hold the operation type for the k8sProbe
+
+
+
Type
+
Mandatory
+
+
+
Range
+
create, delete, present, absent
+
+
+
Notes
+
The .k8sProbe/inputs.operation contains operation which should be applied on the kubernetes resource as part of k8sProbe. It supports four type of operation. It can be one of create, delete, present, absent.
+
+
+
+### CmdProbeInputs
+
+
+
+
Field
+
.cmdProbe/inputs.command
+
+
+
Description
+
Flag to hold the command for the cmdProbe
+
+
+
Type
+
Mandatory
+
+
+
Range
+
n/a type: string
+
+
+
Notes
+
The .cmdProbe/inputs.command contains the shell command, which should be run as part of cmdProbe
+
+
+
+
+
+
Field
+
.cmdProbe/inputs.source.image
+
+
+
Description
+
Flag to hold the image for the cmdProbe
+
+
+
Type
+
Optional
+
+
+
Range
+
any source docker image
+
+
+
Notes
+
The .cmdProbe/inputs.source.image provides the source image which can be used to launch a external pod where the command execution is carried out.
+
+
+
+
+
+
Field
+
.cmdProbe/inputs.source.hostNetwork
+
+
+
Description
+
Flag to allow or deny the .cmdProbe/inputs.source.image access to the node network namespace
+
+
+
Type
+
Optional
+
+
+
Range
+
true, false
+
+
+
Notes
+
The .cmdProbe/inputs.source.hostNetwork provides a possibility to allow the pod executing the cmdProbe access to the network of the node he is running on. For more details refer to the offical Kubernetes documentation.
+
+
+
+### HTTPProbeInput
+
+
+
+
Field
+
.httpProbe/inputs.url
+
+
+
Description
+
Flag to hold the URL for the httpProbe
+
+
+
Type
+
Mandatory
+
+
+
Range
+
n/a type: string
+
+
+
Notes
+
The .httpProbe/inputs.url contains the URL which the experiment uses to gauge health/service availability (or other custom conditions) as part of the entry/exit criteria.
+
+
+
+
+
+
Field
+
.httpProbe/inputs.insecureSkipVerify
+
+
+
Description
+
Flag to hold the flag to skip certificate checks for the httpProbe
+
+
+
Type
+
Optional
+
+
+
Range
+
true, false
+
+
+
Notes
+
The .httpProbe/inputs.insecureSkipVerify contains flag to skip certificate checks.
+
+
+
+
+
+
Field
+
.httpProbe/inputs.responseTimeout
+
+
+
Description
+
Flag to hold the flag to response timeout for the httpProbe
+
+
+
Type
+
Optional
+
+
+
Range
+
n/a type: integer
+
+
+
Notes
+
The .httpProbe/inputs.responseTimeout contains flag to provide the response timeout for the http Get/Post request.
+
+
+
+
+
+
Field
+
.httpProbe/inputs.method.get.criteria
+
+
+
Description
+
Flag to hold the criteria for the http get request
+
+
+
Type
+
Mandatory
+
+
+
Range
+
==, !=, oneOf
+
+
+
Notes
+
The .httpProbe/inputs.method.get.criteria contains criteria to match the http get request's response code with the expected responseCode, which need to be fulfill as part of httpProbe run
+
+
+
+
+
+
Field
+
.httpProbe/inputs.method.get.responseCode
+
+
+
Description
+
Flag to hold the expected response code for the get request
+
+
+
Type
+
Mandatory
+
+
+
Range
+
HTTP_RESPONSE_CODE
+
+
+
Notes
+
The .httpProbe/inputs.method.get.responseCode contains the expected response code for the http get request as part of httpProbe run
+
+
+
+
+
+
Field
+
.httpProbe/inputs.method.post.contentType
+
+
+
Description
+
Flag to hold the content type of the post request
+
+
+
Type
+
Mandatory
+
+
+
Range
+
n/a type: string
+
+
+
Notes
+
The .httpProbe/inputs.method.post.contentType contains the content type of the http body data, which need to be passed for the http post request
+
+
+
+
+
+
Field
+
.httpProbe/inputs.method.post.body
+
+
+
Description
+
Flag to hold the body of the http post request
+
+
+
Type
+
Mandatory
+
+
+
Range
+
n/a type: string
+
+
+
Notes
+
The .httpProbe/inputs.method.post.body contains the http body, which is required for the http post request. It is used for the simple http body. If the http body is complex then use .httpProbe/inputs.method.post.bodyPath field.
+
+
+
+
+
+
Field
+
.httpProbe/inputs.method.post.bodyPath
+
+
+
Description
+
Flag to hold the path of the http body, required for the http post request
+
+
+
Type
+
Optional
+
+
+
Range
+
n/a type: string
+
+
+
Notes
+
The .httpProbe/inputs.method.post.bodyPath This field is used in case of 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 experiment pod via a ConfigMap resource, with the ConfigMap name being defined in the ChaosEngine OR the ChaosExperiment CR.
+
+
+
+
+
+
Field
+
.httpProbe/inputs.method.post.criteria
+
+
+
Description
+
Flag to hold the criteria for the http post request
+
+
+
Type
+
Mandatory
+
+
+
Range
+
==, !=, oneOf
+
+
+
Notes
+
The .httpProbe/inputs.method.post.criteria contains criteria to match the http post request's response code with the expected responseCode, which need to be fulfill as part of httpProbe run
+
+
+
+
+
+
Field
+
.httpProbe/inputs.method.post.responseCode
+
+
+
Description
+
Flag to hold the expected response code for the post request
+
+
+
Type
+
Mandatory
+
+
+
Range
+
HTTP_RESPONSE_CODE
+
+
+
Notes
+
The .httpProbe/inputs.method.post.responseCode contains the expected response code for the http post request as part of httpProbe run
+
+
+
+### PromProbeInputs
+
+
+
+
Field
+
.promProbe/inputs.endpoint
+
+
+
Description
+
Flag to hold the prometheus endpoints for the promProbe
+
+
+
Type
+
Mandatory
+
+
+
Range
+
n/a type: string
+
+
+
Notes
+
The .promProbe/inputs.endpoint contains the prometheus endpoints
+
+
+
+
+
+
Field
+
.promProbe/inputs.query
+
+
+
Description
+
Flag to hold the promql query for the promProbe
+
+
+
Type
+
Mandatory
+
+
+
Range
+
n/a type: string
+
+
+
Notes
+
The .promProbe/inputs.query contains the promql query to extract out the desired prometheus metrics via running it on the given prometheus endpoint
+
+
+
+
+
+
Field
+
.promProbe/inputs.queryPath
+
+
+
Description
+
Flag to hold the path of the promql query for the promProbe
+
+
+
Type
+
Optional
+
+
+
Range
+
n/a type: string
+
+
+
Notes
+
The .promProbe/inputs.queryPath This field is used in case of complex queries that spans multiple lines, the queryPath attribute can be used to provide the path to a file consisting of the same. This file can be made available to the experiment pod via a ConfigMap resource, with the ConfigMap name being defined in the ChaosEngine OR the ChaosExperiment CR.
+
+
+
+### Runproperties
+
+
+
+
Field
+
.runProperties.probeTimeout
+
+
+
Description
+
Flag to hold the timeout for the probes
+
+
+
Type
+
Mandatory
+
+
+
Range
+
n/a type: integer
+
+
+
Notes
+
The .runProperties.probeTimeout represents the time limit for the probe to execute the specified check and return the expected data
+
+
+
+
+
+
Field
+
.runProperties.retry
+
+
+
Description
+
Flag to hold the retry count for the probes
+
+
+
Type
+
Mandatory
+
+
+
Range
+
n/a type: integer
+
+
+
Notes
+
The .runProperties.retry contains the number of times a check is re-run upon failure in the first attempt before declaring the probe status as failed.
+
+
+
+
+
+
Field
+
.runProperties.interval
+
+
+
Description
+
Flag to hold the interval for the probes
+
+
+
Type
+
Mandatory
+
+
+
Range
+
n/a type: integer
+
+
+
Notes
+
The .runProperties.interval contains the interval for which probes waits between subsequent retries
+
+
+
+
+
+
Field
+
.runProperties.probePollingInterval
+
+
+
Description
+
Flag to hold the polling interval for the probes(applicable for Continuous mode only)
+
+
+
Type
+
Optional
+
+
+
Range
+
n/a type: integer
+
+
+
Notes
+
The .runProperties.probePollingInterval contains the time interval for which continuous probe should be sleep after each iteration
+
+
+
+
+
+
Field
+
.runProperties.initialDelaySeconds
+
+
+
Description
+
Flag to hold the initial delay interval for the probes
+
+
+
Type
+
Optional
+
+
+
Range
+
n/a type: integer
+
+
+
Notes
+
The .runProperties.initialDelaySeconds represents the initial waiting time interval for the probes.
+
+
+
+
+
+
Field
+
.runProperties.stopOnFailure
+
+
+
Description
+
Flags to hold the stop or continue the experiment on probe failure
+
+
+
Type
+
Optional
+
+
+
Range
+
false type: boolean
+
+
+
Notes
+
The .runProperties.stopOnFailure can be set to true/false to stop or continue the experiment execution after probe fails
+
+
+
+### Comparator
+
+
+
+
Field
+
type
+
+
+
Description
+
Flag to hold type of the data used for comparision
+
+
+
Type
+
Mandatory
+
+
+
Range
+
string, int, float
+
+
+
Notes
+
The type contains type of data, which should be compare as part of comparision operation
+
+
+
+
+
+
Field
+
criteria
+
+
+
Description
+
Flag to hold criteria for the comparision
+
+
+
Type
+
Mandatory
+
+
+
Range
+
it supports {`>=, <=, ==, >, <, !=, oneOf, between`} for int & float type. And equal, notEqual, contains, matches, notMatches, oneOf for string type.
+
+
+
Notes
+
The criteria contains criteria of the comparision, which should be fulfill as part of comparision operation.
+
+
+
+
+
+
Field
+
value
+
+
+
Description
+
Flag to hold value for the comparision
+
+
+
Type
+
Mandatory
+
+
+
Range
+
n/a type: string
+
+
+
Notes
+
The value contains value of the comparision, which should follow the given criteria as part of comparision operation.
+
+
+
+## Resources
+
+
+
+## Summary
+
+Probes are pluggable checks that can be defined within the ChaosEngine for any Chaos Experiment. There are four kinds of probes `httpProbe` (allows developers to specify a URL which the experiment uses to gauge health/service availability as part of the entry/exit criteria), `cmdProbe` (allows developers to run shell commands and match the resulting output as part of the entry/exit criteria), `k8sProbe` (addresses verification of the desired resource state by allowing users to define the Kubernetes GVR with appropriate filters) and `promProbe` (allows users to run Prometheus queries and match the resulting output against specific conditions).
+
+The different modes these probes can be used in are `SoT`, `EoT`, `Edge`, `Continuous` and `OnChaos`. The litmus chaos experiments run the probes defined in the ChaosEngine and update their stage-wise success in the ChaosResult custom resource with `probeSuccessPercentage`. A `probeSuccessPercentage` is the ratio of successful checks v/s total probes.
+
+Probes can be Chained, Probe chaining enables reuse of probe, the order of execution of probes in the experiment depends purely on the order in which they are defined in the ChaosEngine.
+
+## Learn more
+
+- [Explore the ChaosResult Custom Resource](chaos-result.md)
+- [Explore the ChaosEngine Custom Resource](chaos-engine.md)
diff --git a/website/versioned_docs/version-2.13.0/concepts/projects.md b/website/versioned_docs/version-2.13.0/concepts/projects.md
new file mode 100644
index 0000000..2ea59ea
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/concepts/projects.md
@@ -0,0 +1,35 @@
+---
+id: projects
+title: Projects
+sidebar_label: Projects
+---
+
+---
+
+The ChaosCenter comes with a project management system which can be used for working on chaos scenarios with multiple different projects across different chaos delegates.
+
+## Prerequisites
+
+Before learning abpout the concept of `projects`, it is important to note that a `project` signifies a separation between Chaos Delegates,Schedules, [Visualization](visualize-workflow.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
+
+The project management feature is the second level of privilege layer delivered by the ChaosCenter and a breakdown can be observed in the below diagram:
+
+
+
+The specifics of project management with respect to different first layer privilege levels (Admin/non-admin users) are discussed below:
+
+The **Admin** user of the portal has a default project (named as `adminβs project`) created on the initial login, and by default has the `owner` privileges in this project.
+
+The Admin can [create a user](../user-guides/create-user.md) (these users will be treated as **non-admin** users), and each of these users will have their own projects created on completion of their initial login. The `Owner` of a project can invite multiple users to their project, and a user can be a part of multiple projects, these features are covered under the [teaming](teaming.md) section.
+
+## Summary
+
+Projects can be imagined as separations between multiple different configurations for your chaos and help you manage collaborations between multiple teams.
+
+## Learn more
+
+- [More about project management](../user-guides/change-project-name.md)
+- [More about Teaming](teaming.md)
+- [Invite a member to your project](../user-guides/invite-team-member.md)
diff --git a/website/versioned_docs/version-2.13.0/concepts/teaming.md b/website/versioned_docs/version-2.13.0/concepts/teaming.md
new file mode 100644
index 0000000..a8abfae
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/concepts/teaming.md
@@ -0,0 +1,50 @@
+---
+id: teaming
+title: Collaborate with Teams
+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)
+
+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`.
+
+Teaming is based on the following principles and each user can have one of the 3 project roles:
+
+- **Owner:** One who created the project and owns it. Only the owner has permission to manage(invite or remove) the members in his/her project. The owner can schedule chaos scenarios, update chaos scenarios, delete chaos scenarios and view the analytics.
+- **Editor:** Members invited with the editor role can do everything an owner can except for managing the project.
+- **Viewer:** Members having a viewer role can only view the analytics related to the chaos scenarios and the chaos scenarios themselves, but are not given the permission to schedule chaos scenarios in the project.
+
+## Role privileges
+
+> Note: A user will be the owner of his/her project by default.
+
+**_As the Project Owner you can:_**
+
+- Invite other users for the following roles:
+ - Viewer
+ - Editor
+- View the list of team members with other details including their role in the project, email-id, date-time of joining the project team.
+- Rename your project.
+- Remove a member from your project.
+- Check the status of the invitation you sent to other members.
+- Edit the user role in case the invitation is pending.
+- Cancel the invitation.
+
+**_As a Viewer or Editor you can:_**
+
+- Check and Accept/Decline the received invitations.
+- Switch and browse any project you are a member of.
+- Can leave the project you are a part of, except your own.
+
+> Note: The settings page will not be visible to you if you are browsing someone elseβs project. You can only view it if you are the project owner.
+
+## Learn more
+
+- [Invite a team member](../user-guides/invite-team-member.md)
+- [Edit/Cancel an invite](../user-guides/edit-invite.md)
+- [Accept an invite](../user-guides/accept-invite.md)
+- [Remove a team member](../user-guides/remove-team-member.md)
diff --git a/website/versioned_docs/version-2.13.0/concepts/user-management.md b/website/versioned_docs/version-2.13.0/concepts/user-management.md
new file mode 100644
index 0000000..9930d58
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/concepts/user-management.md
@@ -0,0 +1,32 @@
+---
+id: 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.
+
+> 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)
+
+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.
+
+**Non-admin users:** The admin of the portal has the exclusive ability to create any number of non-admin users.
+
+## 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.
+
+**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 on different chaos delegates which have no layover between each other.)
+
+## Learn more
+
+- [View Users](../user-guides/view-user.md)
+- [Create a user](../user-guides/create-user.md)
+- [Reset password of a user](../user-guides/reset-password.md)
+- [Deactivate a user](../user-guides/deactivate-user.md)
diff --git a/website/versioned_docs/version-2.13.0/concepts/visualize-workflow.md b/website/versioned_docs/version-2.13.0/concepts/visualize-workflow.md
new file mode 100644
index 0000000..f6629d3
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/concepts/visualize-workflow.md
@@ -0,0 +1,71 @@
+---
+id: visualize-workflow
+title: Visualize the Chaos Scenario Execution
+sidebar_label: Visualize Chaos Scenario
+---
+
+---
+
+Visualization is an important aspect while doing chaos engineering. It allows the user to discover and inspect different changes that occur during a Chaos Scenario execution.
+With ChaosCenter, the real-time data and status of the chaos scenarios can be observed. Valuable information like pod logs, chaos scenario status, chaos results can also be viewed.
+
+## Prerequisites
+
+The following should be required before creating a Chaos Scenario:
+
+- ChaosCenter
+- [Chaos Scenarios](chaos-workflow.md)
+
+## Litmus Chaos Scenario
+
+After scheduling a chaos scenario, you are redirected to the Litmus Chaos Scenario page which is divided into 2 sections `Runs` and `Schedules`.
+
+### Runs
+
+This section consists the list of individual chaos scenario
+runs and its related data like `Chaos Scenario Name`, `Status`, `Reliability Score` etc.
+This table displays the real-time status of the chaos scenarios.
+
+### Schedules
+
+This section consists the list of chaos scenario schedules.
+These schedules can consist one time chaos scenario runs or Cron Chaos Scenarios. User can perfom serveral operations in this table, few of them are listed below:
+
+- Disable a Cron Chaos Scenario
+- Download the chaos scenario manifest
+- Save the chaos scenarios as a template
+- Edit a schedule
+- Re-run a chaos scenario etc
+
+## Visualize a Litmus Chaos Scenario
+
+To observe a chaos scenario, user can either click on the chaos scenario name or click on the three dots and select `Show the chaos scenario` option in the runs table.
+
+
+The Chaos Scenario Details page is divided into 2 sections:
+
+- **Graph View**: In this section a realtime graph of the chaos scenario is displayed. This graph contains valuable information regarding the status of individual steps of the chaos scenario.
+
+ To view the details of the step, you can click on the individual nodes. This will open a field which displays the node details and the logs related to it.
+
+
+
+:::note
+If the selected node is an experiment pod which consists of ChaosEngine CRD, a button to Download the logs will be available. Similarly, a tab named `Chaos Results` will also be available, which displays the ChaosResult of the experiment once the chaos scenario execution is completed.
+:::
+
+- **Table View** : Similar to the Graph View, this tab consists the table view of the chaos scenario. The table consists of the different chaos scenario steps along with their status.
+
+
+ On clicking the View Logs & Results button in the table, a pop-over is displayed with the logs of the selected step.
+
+
+## Summary
+
+After scheduling a chaos scenario, a user can view the details of the running chaos scenario from the ChaosCenter. ChaosCenter provides a realtime graph that is used to visualise the chaos scenario and get the details of individual step of the chaos scenario. Important details like the logs and target applications can be viewed from ChaosCenter. These logs are also downloadable. User can view the details in 2 different ways i.e `Graph View` and `Table View`. Once the chaos scenario exection is completed, the resiliency score is calcualted and the ChaosResult for the ChaosEngine pods are available now.
+
+## Learn More
+
+- [Explore Probes](probes.md)
+- [What is a Chaos Scenario](chaos-workflow.md)
+- [Examine the ChaosResult](chaos-result.md)
diff --git a/website/versioned_docs/version-2.13.0/concepts/workflow-statistics.md b/website/versioned_docs/version-2.13.0/concepts/workflow-statistics.md
new file mode 100644
index 0000000..8ab4714
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/concepts/workflow-statistics.md
@@ -0,0 +1,50 @@
+---
+id: workflow-statistics
+title: Chaos Scenarios Statistics
+sidebar_label: Scenarios Statistics
+---
+
+---
+
+Chaos injections often tends to disrupt tightly coupled micro-services and processes. Visualizing the results and plotting analytical graphs prove to be useful under such circumstances. An analytical overview of chaos scenarios for an entire month or a year can help in benchmarking release cycles and building a viable cloud-native product. Also a comparative study over time or rather just being able to observe and plot resiliency scores across different types of chaos scenarios on different subsystems provide a conclusive summary of the reliability metrics for an application under test (AUT) and the supporting platform or infrastructure.
+
+## Prerequisites
+
+The following should be required before knowing about chaos scenario statistics:
+
+- [Chaos Scenarios](chaos-workflow.md)
+- [Visualize Chaos Scenarios](visualize-workflow.md)
+
+## Data flow architecture
+
+The chaos center automatically detects scheduled chaos scenario runs on all connected chaos delegates for a project and provides statistical graphs and visualizations. Data for chaos scenarios runs and chaos results from all the chaos delegates are stored in a mongoDB database which is then ingested into analytical pipelines in the control plane server to transform the raw data into meaningful insights for browsing and reporting.
+
+
+
+Data flow for statistical analysis
+
+
+## Chaos engine context
+
+The `context` is a user defined label for a chaos engine to indicate the intent or the target of chaos. Some of it's uses are for naming AUT, micro-service, infrastructure resource etc. Engine context can be added or updated by the user via the UI. It is used to filter chaos experiments, results, tests during statistical analysis and for filtering chaos injection events during real time monitoring of application or infrastructure metrics interleaved with chaos. It defaults to the target application label and namespace separated by `_` while using chaos center for scheduling chaos scenarios.
+
+## Chaos scenario subject
+
+The `subject` is a user defined label for a chaos scenario to indicate the intent or the target of chaos. Some of it's uses are for naming AUT, micro-service, infrastructure resource etc. Chaos Scenarios subject can be added or updated by the user via the UI. It is used to filter chaos scenarios during statistical analysis and is stored as a metadata for referencing to a particular application group or version on a given target cluster with chaos delegate. It defaults to the target application name and namespace separated by `_` while using chaos center for scheduling chaos scenarios.
+
+## Summary
+
+Statistics of a chaos scenarios schedule across its runs and analyzing application performance across chaos scenarios on a target cluster's AUT are facilitated via the data stored in the persistent storage (mongoDB), collected by the connected chaos delegate plane components like `subscriber` and `chaos-exporter`. Engine `context` and Chaos Scenario `subject` are meant to provide the user with more granular control over the target of chaos while analyzing results or monitoring system or application metrics in real-time under stress or chaos.
+
+## Resources
+
+
+
+
+
+[Analyzing chaos scenarios](https://dev.to/code_igx/analysing-chaos-workflows-with-litmus-portal-4e67)
+
+## Learn More
+
+- [Explore Probes](probes.md)
+- [Application and infrastructure monitoring](app-infra-monitoring.md)
diff --git a/website/versioned_docs/version-2.13.0/faq.md b/website/versioned_docs/version-2.13.0/faq.md
new file mode 100644
index 0000000..dd4aaff
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/faq.md
@@ -0,0 +1,95 @@
+---
+id: faq
+title: FAQ
+sidebar_label: FAQ
+---
+
+---
+
+### Can we host Mongodb outside the cluster? What connection string is supported? Is SSL connection supported?
+
+Yes we can host Mongodb outside the cluster, the mongo string can be updated accordingly `DataBaseServer: "mongodb://mongo-service:27017"`.
+We use the same connection string for both authentication server and graphql server containers in litmus portal-server deployment, also there are the db user and db password keys that can be tuned in the configmap like `DB_USER: "admin"` and `DB_PASSWORD: "1234"`.
+We can connect with SSL if certificate is optional. If our requirement is ca.cert auth for the SSL connection, then this is not available on portal.
+
+### Is there any way to use Litmus within github? Basically when someone submits a k8s deployment for a PR, We want to run chaos Experiment on that to see whether it passes or not.
+
+Yes, with the help of github-chaos-action we can automate the chaos execution on an application in the same place where the code is stored. We can write individual tasks along with chaos actions and combine them to create a custom GitHub workflow. GitHub Workflows are custom automated processes that we can set up in our repository to build, test, package, or deploy any code project on GitHub. Including the GitHub chaos actions in our workflow YAML, We can test the performance/resiliency of our application in a much simpler and better way. To know more visit our Github chaos action [repository](https://github.com/litmuschaos/github-chaos-actions).
+
+### I encountered the concept of `namespace` and `cluster` scope during the installation. What is meant by the scopes, and how does it affect experiments to be performed outside or inside the litmus Namespace?
+
+The scope of portal control plane (portal) installation tuned by the env `PORTAL_SCOPE` of litmusportal-server deployment can be kept as a namespace if you want to provide a very restricted access to litmus; It's useful in dev environments like Okteto cloud etc.
+That basically restricts portal installation along with its chaos delegate to a single namespace and the chaos operator, exporter all get installed in a single namespace and can only perform and monitor chaos in that namespace.
+Other than that there is another key in the control planeβs configmap `litmus-portal-admin-config` called `AgentScope`, this is given to allow users to restrict access to the litmus self chaos delegate components self chaos delegate is the chaos delegate for your control plane cluster (exporter, operator etc), you can use both of them in a way to give access as per the requirement.
+The above holds for the control plane and self chaos delegate, for the external chaos delegates which can be connected using the litmusctl CLI you can provide the scope of the chaos delegate while using the utility to connect your other cluster to the control plane with access to just a single namespace or cluster-wide access.
+Using a combination of AgentScope: cluster and `PORTAL_SCOPE` env set to cluster would give you cluster-admin privileges to inject chaos on all namespaces where the control plane/portal is installed. For external chaos delegates just selecting the scope of installation as cluster would be sufficient via litmusctl.
+
+### What does failed status of chaos scenario means in LitmusPortal?
+
+Failed status indicates that either there is some misconfiguration in the chaos scenario or the default hypothesis of experiment was disproved and some of the experiments in the chaos scenario failed, In such case the resiliency score will be less than 100.
+
+### How can I setup chaoshub of my own gitlab repo in Litmus Portal?
+
+In the litmus portal when you go to the chaoshub section and you click on connect new hub button, you can see that there are two modes of authentication i.e public mode and private mode. In public mode, you only have to provide the git URL and branch name.
+
+In private mode, we have two types of authentication; Access token and SSH key.
+For the access token, go to the settings of GitLab and in the Access token section, add a token with read repository permission. After getting the token, go to the Litmus portal and provide the GitLab URL and branch name along with the access token. After submitting, your own chaos hub is connected to the Litmus portal.
+For the SSH key, click on the SSH and it will generate a public key. You have to use this public key and put it in your GitLab account. Just go to the settings of GitLab, you can see the SSH key section, go to the SSH key section and add your public key. After adding the public key. Get the ssh type URL of the git repository and put it in the Litmus Portal along with the branch. After submitting, your own chaoshub is connected to the Litmus Portal.
+
+### Does Litmus 2.0 maintain backward compatibility with kubernetes?
+
+Yes, Litmus maintains a separate CRD manifest to support backward compatibility.
+
+### Can I run LitmusChaos Outside of my Kubernetes clusters?
+
+Yes, you can run the ansible experiments outside of the k8s cluster which is dockerized under this image litmuschaos/ansible-runner:ci. But other components such as chaos-operator, chaos-exporter, and runner are Kubernetes native. They requires k8s cluster to run on it.
+
+### How to achieve High Availability of MongoDB and how can we add persistence to MongoDB?
+
+Currently, the MongoDB instance is not HA, we can install the MongoDB operator along with mongo to achieve HA. This MongoDB CRD allows for specifying the desired size and version as well as several other advanced options. Along with the Mongodb operator, we will use the MongoDB sts with PV to add the persistence.
+
+### Can I create chaos scenarios without using dashboard?
+
+Currently, you canβt. But we are working on it. Shortly we will publish samples for doing this via API/SDK and litmusctl.
+
+### Does Litmusctl support actions that are currently performed from the portal dashboard?
+
+For now, you can create chaos delegates and projects, also you can get the chaos delegates and project details by using litmusctl. To know more about litmusctl please refer to the [documentation of litmusctl](https://github.com/litmuschaos/litmusctl/blob/master/Usage.md).
+
+### What is the minimum system requirement to run Portal and chaos delegate together?
+
+To run LitmusPortal you need to have a minimum of 1 GiB memory and 1 core of CPU free.
+
+### Can I use Litmus in Production?
+
+Yes, you can use Litmuschaos in production. Litmus has a wide variety of experiments and is designed as per the principles of chaos. But, if you are new to Chaos Engineering, we would recommend you to first try Litmus on your dev environment, and then after getting the confidence, you should use it in Production.
+
+### How is resilience score calculated?
+
+The Resilience score is calculated on the basis of the weightage and the Probe Success Percentage of the experiment. Resilience for one single experiment is the multiplication of the weight given to that experiment and the Probe Success Percentage. Then we get the total test result by adding the resilience score of all the experiments. The Final Resilience Score is calculated by dividing the total test result by the sum of the weights of all the experiments combined in the single chaos scenario. For more detail refer to [this blog](https://dev.to/litmus-chaos/how-the-resilience-score-algorithm-works-in-litmus-1d22).
+
+### How can we use litmus in our DevOps pipeline/cycle?
+
+You can add litmus to the CI/CD pipelines as part of an end-to-end testing approach due to its minimal pre-requisites and simple result mechanisms. It also provides utilities for quick setup of Kubernetes clusters on different platforms as well as installation of storage provider control plane components (operators). [Openebs.ci](https://openebs.ci/home) is a reference implementation of how litmus can be used in the DevOps pipeline.
+
+### How can users integrate Litmuschaos in their environment with Gitops?
+
+Gitops feature in Litmus enables users to sync chaos scenarios from a configured git repo, any chaos scenario inserts/updates made to the repo will be monitored and picked up by litmus portal and will be executed on the target cluster. Litmus portal gitops also includes an event-driven chaos injection feature where users can annotate an application to be watched for changes and if and when the change happens chaos scenarios can be triggered automatically. This integrates with other gitops tools like flux/argo cd and enables users to automatically run chaos scenarios whenever a new release happens or a particular change occurs in the application.
+To configure a git repo the user must provide the Git URL of the repository and the Branch name and the authentication credentials which are of two types:
+
+- Access Token
+- SSH Key
+
+Once GitOps is enabled, any new chaos scenarios created will be stored in the configured repo in the path `litmus//.yaml`.
+
+### How to solve `invalid token` issue in litmusctl?
+
+You can use the command `litmusctl config set-account` to generate a new token. You get `invalid token` error if the authorization token is expired. Authorization token has a life span of 24 hours.
+
+### How to check if installed version of litmus control plane is compatible with installed litmusctl?
+
+litmusctl will prompt if your installed litmusctl and litmus control plane are compatible when user runs `litmusctl config set-account`
+
+### How to check compatibility of litmusctl with litmus control plane?
+
+You can use command `litmusctl version` to check the compatibility of litmusctl or you can refer to: https://github.com/litmuschaos/litmusctl#compatibility-matrix to get the compatibility matrix of litmusctl and litmus control plane.
diff --git a/website/versioned_docs/version-2.13.0/getting-started/installation.md b/website/versioned_docs/version-2.13.0/getting-started/installation.md
new file mode 100644
index 0000000..f8df511
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/getting-started/installation.md
@@ -0,0 +1,220 @@
+---
+id: installation
+title: ChaosCenter Cluster Scope Installation
+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
+ :::
+
+- [Helm3](https://v3.helm.sh/) or [kubectl](https://kubernetes.io/docs/tasks/tools/#kubectl)
+
+## Installation
+
+Users looking to use Litmus for the first time have two options available to them today. One way is to use a hosted Litmus service like [Harness Chaos Engineering SaaS](https://cloud.chaosnative.com/). Alternatively, users looking for some more flexibility can install Litmus into their own Kubernetes cluster.
+
+Users choosing the self-hosted option can refer to our Install and Configure docs for installing alternate versions and more detailed instructions.
+
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
+
+
+ Installation of Self-Hosted Litmus can be done using either of the below methods:
+
+
+ Refer to the below details for Self-Hosted Litmus installation.
+
+
+ Harness offers a free service for community members which makes getting started with Litmus easy. Create an account to get started. Once logged in, create a new hosted control plane and connect to it via the up CLI. Litmus can be used as a hosted cloud service using Harness Chaos Engineering SaaS. Harness Chaos Engineering SaaS executes your Chaos Scenarios in the cloud by managing all your Chaos Control Plane components, while the Chaos Execution Plane components exist on your Kubernetes cluster as part of an external chaos delegate.
+
+ To get started with Harness Chaos Engineering SaaS, visit Harness Chaos Engineering SaaS and register for free. You can skip the below installation steps.
+
+
+
+### Install Litmus using Helm
+
+The helm chart will install all the required service account configuration and ChaosCenter.
+
+The following steps will help you install Litmus ChaosCenter via helm.
+
+#### Step-1: Add the litmus helm repository
+
+```bash
+helm repo add litmuschaos https://litmuschaos.github.io/litmus-helm/
+helm repo list
+```
+
+#### Step-2: Create the namespace on which you want to install Litmus ChaosCenter
+
+- The ChaosCenter can be placed in any namespace, but for this scenario we are choose `litmus` as the namespace.
+
+```bash
+kubectl create ns litmus
+```
+
+#### Step-3: Install Litmus ChaosCenter
+
+```bash
+helm install chaos litmuschaos/litmus --namespace=litmus --set portal.frontend.service.type=NodePort
+```
+
+> **Note:** If your Kubernetes cluster isn't local, you may want not to expose Litmus via `NodePort`. If so, remove `--set portal.frontend.service.type=NodePort` option. To connect to Litmus UI from your laptop, you can use `port-forward svc/chaos-litmus-frontend-service 9091:9091`. Then you can use your browser and open `127.0.0.1:9091`.
+
+Expected Output
+
+```
+NAME: chaos
+LAST DEPLOYED: Wed Sep 21 10:53:05 2022
+NAMESPACE: litmus
+STATUS: deployed
+REVISION: 1
+TEST SUITE: None
+NOTES:
+Thank you for installing litmus π
+
+Your release is named chaos and it's installed to namespace: litmus.
+
+Visit https://docs.litmuschaos.io to find more info.
+```
+
+> **Note:** Litmus uses Kubernetes CRDs to define chaos intent. Helm3 handles CRDs better than Helm2. Before you start running a chaos experiment, verify if Litmus is installed correctly.
+
+### **Install Litmus using kubectl**
+
+#### **Install Litmus ChaosCenter**
+
+Applying the manifest file will install all the required service account configuration and ChaosCenter.
+
+```bash
+kubectl apply -f https://litmuschaos.github.io/litmus/2.13.0/litmus-2.13.0.yaml
+```
+
+---
+
+## **Verify your installation**
+
+#### **Verify if the frontend, server, and database pods are running**
+
+- Check the pods in the namespace where you installed Litmus:
+
+ ```bash
+ kubectl get pods -n litmus
+ ```
+
+ Expected Output
+
+ ```bash
+ NAME READY STATUS RESTARTS AGE
+ litmusportal-server-6fd57cc89-6w5pn 1/1 Running 0 57s
+ litmusportal-auth-server-7b596fff9-5s6g5 1/1 Running 0 57s
+ mongo-0 1/1 Running 0 57s
+ litmusportal-frontend-55974fcf59-cxxrf 1/1 Running 0 58s
+ ```
+
+- Check the services running in the namespace where you installed Litmus:
+
+ ```bash
+ kubectl get svc -n litmus
+ ```
+
+ Expected Output
+
+ ```bash
+ NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
+ litmusportal-frontend-service NodePort 10.43.79.17 9091:31846/TCP 102s
+ litmusportal-server-service NodePort 10.43.30.54 9002:31245/TCP,8000:32714/TCP 101s
+ litmusportal-auth-server-service NodePort 10.43.81.108 9003:32618/TCP,3030:31899/TCP 101s
+ mongo-service ClusterIP 10.43.227.10 27017/TCP 101s
+ mongo-headless-service ClusterIP None 27017/TCP 101s
+ ```
+
+---
+
+## **Accessing the ChaosCenter**
+
+To setup and login to ChaosCenter expand the available services just created and copy the `PORT` of the `litmusportal-frontend-service` service
+
+```bash
+kubectl get svc -n litmus
+```
+
+Expected Output
+
+```bash
+NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
+litmusportal-frontend-service NodePort 10.43.79.17 9091:31846/TCP 102s
+litmusportal-server-service NodePort 10.43.30.54 9002:31245/TCP,8000:32714/TCP 101s
+litmusportal-auth-server-service NodePort 10.43.81.108 9003:32618/TCP,3030:31899/TCP 101s
+mongo-service ClusterIP 10.43.227.10 27017/TCP 101s
+mongo-headless-service ClusterIP None 27017/TCP 101s
+```
+
+> **Note**: In this case, the PORT for `litmusportal-frontend-service` is `30385`. Yours will be different.
+
+Once you have the PORT copied in your clipboard, simply use your IP and PORT in this manner `:` to access the Litmus ChaosCenter.
+
+For example:
+
+```yaml
+http://172.17.0.3:30385/
+```
+
+> Where `172.17.0.3` is my NodeIP and `30385` is the frontend service PORT. If using a LoadBalancer, the only change would be to provide a `:`. [Learn more about how to access ChaosCenter with LoadBalancer](../user-guides/setup-without-ingress.md#with-loadbalancer)
+
+You should be able to see the Login Page of Litmus ChaosCenter. The **default credentials** are
+
+```yaml
+Username: admin
+Password: litmus
+```
+
+
+
+By default you are assigned with a default project with Owner permissions.
+
+
+
+## **Verify Successful Registration of the Self Chaos Delegate**
+
+Once the project is created, the cluster is automatically registered as a chaos target via installation of [Chaos Delegate](resources.md#chaosagents). This is represented as [Self Chaos Delegate](resources.md#types-of-chaosagents) in [ChaosCenter](resources.md#chaoscenter).
+
+```bash
+kubectl get pods -n litmus
+```
+
+```bash
+NAME READY STATUS RESTARTS AGE
+chaos-exporter-547b59d887-4dm58 1/1 Running 0 5m27s
+chaos-operator-ce-84ddc8f5d7-l8c6d 1/1 Running 0 5m27s
+event-tracker-5bc478cbd7-xlflb 1/1 Running 0 5m28s
+litmusportal-frontend-97c8bf86b-mx89w 1/1 Running 0 15m
+litmusportal-server-6fd57cc89-6w5pn 1/1 Running 0 15m
+litmusportal-auth-server-7b596fff9-5s6g5 1/1 Running 0 15m
+mongo-0 1/1 Running 0 15m
+subscriber-958948965-qbx29 1/1 Running 0 5m30s
+workflow-controller-78fc7b6c6-w82m7 1/1 Running 0 5m32s
+```
+
+## Resources
+
+
+
+## Learn more
+
+- [Install ChaosCenter in Namespace Scope](../user-guides/chaoscenter-namespace-scope-installation.md)
+- [Connect External Chaos Delegates to ChaosCenter](../user-guides/chaosagents-installation.md)
+- [Setup Endpoints and Access ChaosCenter without Ingress](../user-guides/setup-without-ingress.md)
+- [Setup Endpoints and Access ChaosCenter with Ingress](../user-guides/setup-with-ingress.md)
diff --git a/website/versioned_docs/version-2.13.0/getting-started/resources.md b/website/versioned_docs/version-2.13.0/getting-started/resources.md
new file mode 100644
index 0000000..8daee42
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/getting-started/resources.md
@@ -0,0 +1,69 @@
+---
+id: resources
+title: Resources
+sidebar_label: Resources
+---
+
+---
+
+## ChaosCenter
+
+The **ChaosCenter** is a single source of truth to control all the different Chaos Activities happening around Litmus. From the ChaosCenter you get the freedom to manage every single part of Litmus and shape your chaos scenarios 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)
+
+The ChaosCenter gives you access to a plethora of features, the major ones include
+
+- Chaos Scenario Creation
+
+
+
From Templates, Custom Chaos Scenarios 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 Scenarios 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
+
+
+- Monitoring & Observability
+
+
+
Connect a Data Source (from any Chaos Delegate) and monitor chaos scenarios
+
Visualize chaos scenario run statistics and aggregated schedules
+
Compare two or more Chaos Scenarios
+
Upload shared/downloadable dashboards available in the community
+
Edit queries, Tune dashboards to create a custom one from scratch
+
Monitor effect of chaos in real time with interleaved events and metrics from Prometheus Datasource
+
+
+- Chaos Scenario Management
+
+
+
Rolling out automated changes using GitOps
+
Allowing image addition from custom image server (both public and private)
+
Measure and Analyse the Resilience Score of each chaos scenario
+
+
+
+## Chaos Delegates
+
+A **Chaos Delegate** in Litmus is nothing but the target cluster where Chaos would be injected via Litmus. There should always be at least one or more than one Chaos Delegates connected to the ChaosCenter. Each individual Chaos Delegate can be chosen to be the Chaos Delegate for Chaos Injection.
+
+## Types of Chaos Delegates
+
+In Litmus, Chaos Delegates can be classified into two types
+
+- Self Chaos Delegate
+- External Chaos Delegate
+
+As part of the Litmus installation, a Self Chaos Delegate would be registered as a default Chaos Delegate in the ChaosCenter. The same cluster where Litmus is installed is chosen as the Self Chaos Delegate by the installer. From the ChaosCenter you can now induce chaos into this Self Chaos Delegate and observe the results.
+
+Since the ChaosCenter is Cross Cloud, you can connect multiple external Chaos Delegates to the same 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 Delegates.
diff --git a/website/versioned_docs/version-2.13.0/getting-started/run-your-first-workflow.md b/website/versioned_docs/version-2.13.0/getting-started/run-your-first-workflow.md
new file mode 100644
index 0000000..6f15b46
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/getting-started/run-your-first-workflow.md
@@ -0,0 +1,141 @@
+---
+id: run-your-first-workflow
+title: Run your First Chaos Scenario in 5 minutes
+sidebar_label: Run Your First Chaos Scenario
+---
+
+---
+
+Welcome to this scenario, in this section you will get an overview of how to execute a sample LitmusChaos Scenario on your application to induce Chaos as well as to observe the results and resilience score.
+
+## Prerequisites
+
+Before starting with your first Chaos Scenario make sure the [Litmus ChaosCenter](resources#chaoscenter) is installed in either one of these scopes
+
+- [Cluster Scope](../user-guides/chaoscenter-cluster-scope-installation.md)
+- [Namespace Scope](../user-guides/chaoscenter-namespace-scope-installation.md)
+
+## Aim of the scenario
+
+In this scenario we will execute a pod-delete fault on a sample micro-service application called [Podtato Head](https://github.com/cncf/podtato-head/). This scenario will help you
+
+- Install and execute a pod-delete fault on the [Podtato Head](https://github.com/cncf/podtato-head/) Application
+- Visualize and analyze the chaos experiment
+
+---
+
+## Schedule your First Chaos Scenario
+
+### Select the podtato-head predefined Chaos Scenario
+
+1. Click on **Schedule a Chaos Scenario** from the ChaosCenter Homepage or from the top right button in the **Litmus Workflows** tab.
+
+
+
+
+
+2. Select **Self Chaos Delegate** as the target [Chaos Delegate](resources.md#chaosagents) for Chaos Injection. This is where we'll select which Chaos Delegate to choose as the Chaos Delegate.
+
+
+
+3. Expand the first radio button (To create a new Chaos Scenario from Predefined Chaos Scenario Templates) and select **podtato-head** from the list of Predefined Chaos Scenarios.
+
+
+
+4. View the Chaos Scenario details in the **Chaos Scenario Settings**, you can modify the name and description of the Chaos Scenario to suit your needs.
+
+
+
+### Simulate the Chaos Scenario Steps Visualization
+
+5. View the visualization of the Litmus Chaos Scenario you are about to execute. This step also allows for you to edit or modify the YAML/tunable if required. We would just stick with the default configurations for now.
+
+
+
+ > By default in the Podtato Head Chaos Scenario Template the steps to gracefully delete the Chaos Resources (`revert-chaos`) and also the Podtato Head application (`delete-application`) are present.
+
+### Assign Weights to the Chaos Scenario Experiments
+
+6. Assign weights to the chaos experiments that are part of the Chaos Scenario using the slider. This is typically used when there are multiple experiments as part of a Chaos Scenario. These weights influence the **Resilience Score** calculation for the Chaos Scenario.
+
+
+
+### Schedule the Podtato-Head Chaos Scenario
+
+7. Schedule the Litmus Chaos Scenario for immediate and one-time execution by selecting the **Schedule Now** option
+
+
+
+8. Verify and click on **Finish** to start the Chaos Injection
+
+
+
+### Congratulations
+
+And with that you have successfully scheduled your first Chaos Scenario with Litmus.
+
+
+
+---
+
+## Visualize and Analyze
+
+1. To check the current progress of the Podtato-Head Chaos Scenario, view the status of the Chaos Scenario from the **Litmus Chaos Scenarios** Tab.
+
+
+
+2. Litmus deploys a sample multi-replica hello-service application before going onto pull the pod-delete ChaosExperiment template. In the next step, it creates the ChaosEngine to launch the chaos injection via dedicated pods.
+
+ To see all these steps live in action on the `chaos scenario name` from the **Runs** Tab or select **Show the Chaos Scenario** from the three dot menu.
+
+
+
+ To see them in action on the terminal itself watch the pods in the namespace where ChaosCenter is installed.
+
+ > In this case we would consider ChaosCenter to be installed in the `litmus` namespace
+
+ ```bash
+ kubectl get pods -n litmus
+ ```
+
+ Expected Output
+
+ ```bash
+ NAME READY STATUS RESTARTS AGE
+ chaos-exporter-547b59d887-4dm58 1/1 Running 0 6h16m
+ chaos-operator-ce-84ddc8f5d7-l8c6d 1/1 Running 0 6h16m
+ event-tracker-5bc478cbd7-xlflb 1/1 Running 0 6h16m
+ litmusportal-frontend-698bcb686f-xm4q5 1/1 Running 0 6h26m
+ litmusportal-server-5bb94f65d7-llzng 2/2 Running 1 6h26m
+ mongo-0 1/1 Running 0 6h26m
+ pod-delete-llu29u-vh8w9 1/1 Running 0 21s
+ podtato-5554584d7-68bts 1/1 Running 0 94s
+ podtato-5554584d7-cjmv6 0/1 ContainerCreating 0 2s
+ podtato-5554584d7-z4cwl 0/1 Terminating 0 94s
+ podtato-head-chaos-1622018315-1170130526 0/2 Completed 0 112s
+ podtato-head-chaos-1622018315-3739956689 2/2 Running 0 31s
+ podtato-head-chaos-1622018315-80657052 0/2 Completed 0 79s
+ podtato-head-pod-delete-chaosx55vh-runner 1/1 Running 0 25s
+ subscriber-958948965-qbx29 1/1 Running 0 6h16m
+ workflow-controller-78fc7b6c6-w82m7 1/1 Running 0 6h16m
+ ```
+
+3. Post Chaos Execution view the Experiment Results. Click on the **pod-delete** node on the graph to launch a results console. Click on the **Chaos Results** tab to view the details around success/failure of the steady-state hypothesis constraints (podtato-head website availability through pod deletion period) and the experiment verdict.
+
+
+
+## Resources
+
+
+
+### Beginner Friendly Resources
+
+β¨ Below is a list of beginner-level resources, everything you need to get started in your Cloud-Native Chaos Engineering journey β¨
+
+[List of Beginner Friendly Resources](https://github.com/litmuschaos/litmus/tree/master/resources)
+
+## Various Ways of Learning Litmus
+
+- [Learn Concept](../concepts/overview.md)
+- [View User Guides](../user-guides/overview.md)
+- [Learn by Running a sample Katakoda Scenario](https://www.katacoda.com/litmusbot/scenarios/getting-started-with-litmus)
diff --git a/website/versioned_docs/version-2.13.0/glossary.md b/website/versioned_docs/version-2.13.0/glossary.md
new file mode 100644
index 0000000..b69b8a1
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/glossary.md
@@ -0,0 +1,7 @@
+---
+id: glossary
+title: Glossary
+sidebar_label: glossary
+---
+
+## Coming Soon
diff --git a/website/versioned_docs/version-2.13.0/integrations/grafana.md b/website/versioned_docs/version-2.13.0/integrations/grafana.md
new file mode 100644
index 0000000..8c149d5
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/integrations/grafana.md
@@ -0,0 +1,274 @@
+---
+id: grafana
+title: Observe chaos impact using Grafana
+sidebar_label: Grafana
+---
+
+---
+
+Chaos Engineering is the discipline of experimenting on a system to build confidence in the systemβs capability to withstand turbulent conditions in production. Monitoring a system's resilience and its performance under chaos are one of the fundamental principles of chaos engineering. Litmus has sample chaos interleaved dashboards available on Grafanaβs community dashboards as well as provisioned dashboards along with provisioned data sources. Some sample chaos interleaved dashboards can be found [here](https://github.com/litmuschaos/litmus/tree/master/monitoring/grafana-dashboards)
+
+## Before you begin
+
+The following should be required before integrating Grafana with litmus 2.0:
+
+- [Running Chaos Scenarios](../getting-started/run-your-first-workflow.md)
+- [Prometheus TSDB](https://prometheus.io/)
+- [Prometheus Integration](prometheus.md)
+- [Application and infrastructure monitoring](../concepts/app-infra-monitoring.md)
+
+## Grafana setup with provisioned data source amd dashboards using Prometheus deployment with scrape jobs
+
+The following steps can be followed to set up Grafana with Prometheus for accessing the integrated and interleaved dashboards
+
+- Clone the litmus repo
+
+```bash
+git clone https://github.com/litmuschaos/litmus.git
+cd litmus/monitoring
+```
+
+- Create monitoring namespace on the cluster
+
+```bash
+kubectl create ns monitoring
+```
+
+- Deploy prometheus components
+
+```bash
+kubectl -n monitoring apply -f utils/prometheus/prometheus-scrape-configuration/
+```
+
+- Deploy metrics exporters
+
+```bash
+kubectl -n monitoring apply -f utils/metrics-exporters/node-exporter/
+kubectl -n monitoring apply -f utils/metrics-exporters/kube-state-metrics/
+```
+
+- Deploy chaos-exporter when the cluster is not connected to litmus 2.0 control plane via litmus chaos delegate (exporter is installed as a part of the chaos delegate bundle)
+
+```bash
+kubectl -n litmus apply -f utils/metrics-exporters/litmus-metrics/chaos-exporter/
+```
+
+- Deploy Grafana
+
+```bash
+kubectl -n monitoring apply -f utils/grafana/
+```
+
+_You may access the grafana dashboard via the LoadBalancer (or NodePort) service IP or via a port-forward operation on localhost and then view it from manage dashboards section._
+
+> View the services running in the monitoring namespace
+
+```bash
+kubectl get svc -n monitoring
+```
+
+> Now copy the EXTERNAL-IP of grafana and view it in the browser
+
+Default username/password credentials: `admin/admin`
+
+### Screenshots
+
+#### Chaos Result selector dropdown:
+
+
+
+#### Chaos Engine Context (Target application's NAMESPACE_LABEL) selector dropdown:
+
+
+
+#### Chaos Engines with Experiments as Chaos Results:
+
+
+
+#### Chaos event annotations:
+
+
+
+#### Chaos Result verdict annotations:
+
+
+
+#### Interleaved Chaos events:
+
+
+
+#### Interleaved Chaos Result verdicts:
+
+
+
+#### Chaos Result verdict failure alerts:
+
+
+
+#### Chaos Result probe failure alerts:
+
+
+
+#### Systems healthy / in steady state OR no alerts to be issued:
+
+
+
+#### Systems un-healthy / failed to regain steady state after chaos / meet SLO OR alerts are issued:
+
+
+
+#### Alerts issued:
+
+
+
+## Chaos interleaving over infra and application metrics
+
+Chaos interleaving can be achieved using the `litmuschaos_awaited_experiments` and `litmuschaos_experiment_verdict` prometheus metrics which can be transformed using grafana variables and annotations into chaos injection events with metadata and results to monitor the application under test or infrastructure under test.
+
+> Sample variable configurations:
+
+_Queries:_
+
+**chaosresult_name**
+
+```json
+label_values(litmuschaos_awaited_experiments{app=~"chaos-exporter"}, chaosresult_name)
+```
+
+**chaosengine_context**
+
+```json
+label_values(litmuschaos_experiment_verdict{app=~"chaos-exporter"}, chaosengine_context)
+```
+
+#### Screenshots
+
+
+
+Chaos result name variable
+
+
+
+
+Chaos engine context variable
+
+
+> Sample annotation configurations:
+
+_Queries:_
+
+**LitmusChaos Events**
+
+```json
+litmuschaos_awaited_experiments{chaosresult_name=~"$chaosresult_name", job="litmus/chaos-exporter", app="chaos-exporter"}
+```
+
+**LitmusChaos Metrics**
+
+```json
+litmuschaos_experiment_verdict{chaosresult_name=~"$chaosresult_name",chaosengine_context=~"$chaosengine_context", job="litmus/chaos-exporter", app="chaos-exporter"}
+```
+
+#### Screenshots
+
+
+
+Chaos event annotation
+
+
+
+
+Chaos metric annotation
+
+
+## Fault injection and system failure alerts
+
+These alerts can be configured and triggered based on conditions set on panels using the `litmuschaos_awaited_experiments` and `litmuschaos_experiment_verdict` metrics. The same can be issued to various channels registered for the corresponding alerts on Grafana.
+
+> Sample alert configuration for chaos result verdict
+
+_Query:_
+
+```json
+litmuschaos_experiment_verdict{job="litmus/chaos-exporter", app="chaos-exporter", chaosresult_verdict="Fail"}
+```
+
+#### Screenshots
+
+
+
+Experiment verdict failure alert query
+
+
+
+
+Experiment verdict failure alert configuration
+
+
+> Sample alert configuration for probe success percentage
+
+_Query:_
+
+```json
+litmuschaos_experiment_verdict{job="litmus/chaos-exporter", app="chaos-exporter", probe_success_percentage!="100.000000"}
+```
+
+#### Screenshots
+
+
+
+Probe failure alert query
+
+
+
+
+Probe failure alert configuration
+
+
+## Gauges from metrics for aggregated view of chaos injections
+
+Metrics from chaos-exporter like `litmuschaos_passed_experiments`, `litmuschaos_failed_experiments` and `litmuschaos_awaited_experiments` when ingested in Prometheus which is connected as a data source can provide an aggregated view of chaos injections on a chaos delegate cluster or namespace.
+
+_Queries:_
+
+**Total Experiments Runs**
+
+```json
+sum(litmuschaos_passed_experiments{job="litmus/chaos-exporter"} + litmuschaos_failed_experiments{job="litmus/chaos-exporter"})
+```
+
+**Passed Experiments**
+
+```json
+sum(litmuschaos_passed_experiments{job="litmus/chaos-exporter"})
+```
+
+**Failed Experiments**
+
+```json
+sum(litmuschaos_failed_experiments{job="litmus/chaos-exporter"})
+```
+
+**Queued Experiments**
+
+```json
+sum(litmuschaos_awaited_experiments{job="litmus/chaos-exporter"})
+```
+
+#### Screenshot
+
+
+
+Gauge metrics
+
+
+## Resources
+
+
+
+[Observability Considerations in Chaos: The Metrics Story](https://dev.to/ksatchit/observability-considerations-in-chaos-the-metrics-story-6cb)
+
+## Learn More
+
+- [Application and infrastructure monitoring](../concepts/app-infra-monitoring.md)
+- [Observability Setup](../user-guides/observability-set-up.md)
diff --git a/website/versioned_docs/version-2.13.0/integrations/prometheus.md b/website/versioned_docs/version-2.13.0/integrations/prometheus.md
new file mode 100644
index 0000000..f0a4d4a
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/integrations/prometheus.md
@@ -0,0 +1,206 @@
+---
+id: prometheus
+title: Collecting metrics using Prometheus
+sidebar_label: Prometheus
+---
+
+---
+
+LitmusChaos facilitates real-time monitoring for events and metrics using itβs native chaos exporter. These events and metrics can be exported into any TSDBs (Time-series databases) to overlay on top of application performance graphs and also as additional visualizations for chaos testing statistics. To set up or configure your monitoring infrastructure to support litmus chaos events and metrics, we provide both service endpoints and service monitors setup.
+
+## Before you begin
+
+The following should be required before integrating Prometheus in litmus 2.0:
+
+- [Running Chaos Scenarios](../getting-started/run-your-first-workflow.md)
+- [Prometheus TSDB](https://prometheus.io/)
+- [Probes](../concepts/probes.md)
+- [Data source](../concepts/datasource.md)
+
+## Prometheus deployment with scrape job
+
+- Clone the litmus repo
+
+```bash
+git clone https://github.com/litmuschaos/litmus.git
+cd litmus/monitoring
+```
+
+- Create monitoring namespace on the cluster
+
+```bash
+kubectl create ns monitoring
+```
+
+- Deploy prometheus components
+
+```bash
+kubectl -n monitoring apply -f utils/prometheus/prometheus-scrape-configuration/
+```
+
+- Deploy metrics exporters
+
+```bash
+kubectl -n monitoring apply -f utils/metrics-exporters/node-exporter/
+kubectl -n monitoring apply -f utils/metrics-exporters/kube-state-metrics/
+```
+
+- Deploy chaos-exporter when the cluster is not connected to litmus 2.0 control plane via litmus chaos delegate (exporter is installed as a part of the chaos delegate bundle)
+
+```bash
+kubectl -n litmus apply -f utils/metrics-exporters/litmus-metrics/chaos-exporter/
+```
+
+> Sample scrape job
+
+```yaml
+- job_name: 'chaos-exporter'
+ static_configs:
+ - targets: ['chaos-exporter.litmus.svc.cluster.local:8080']
+ relabel_configs:
+ - target_label: instance
+ replacement: 'chaos-exporter-service'
+```
+
+## Prometheus operator with service monitor
+
+- Clone the litmus repo
+
+```bash
+git clone https://github.com/litmuschaos/litmus.git
+cd litmus/monitoring
+```
+
+- Create monitoring namespace on the cluster
+
+```bash
+kubectl create ns monitoring
+```
+
+- Create the operator to instantiate all CRDs
+
+```bash
+kubectl -n monitoring apply -f utils/prometheus/prometheus-operator/
+```
+
+- Deploy monitoring components
+
+```bash
+kubectl -n monitoring apply -f utils/metrics-exporters-with-service-monitors/node-exporter/
+kubectl -n monitoring apply -f utils/metrics-exporters-with-service-monitors/kube-state-metrics/
+```
+
+- Deploy chaos-exporter when the cluster is not connected to litmus 2.0 control plane via litmus chaos delegate (exporter is installed as a part of the chaos delegate bundle)
+
+```bash
+kubectl -n litmus apply -f utils/metrics-exporters-with-service-monitors/litmus-metrics/chaos-exporter/
+```
+
+- Deploy prometheus instance and all the service monitors for targets
+
+```bash
+kubectl -n monitoring apply -f utils/prometheus/prometheus-configuration/
+```
+
+> Sample service monitor
+
+```yaml
+apiVersion: monitoring.coreos.com/v1
+kind: ServiceMonitor
+metadata:
+ name: chaos-exporter
+ labels:
+ k8s-app: chaos-exporter
+ namespace: litmus
+spec:
+ jobLabel: app
+ selector:
+ matchLabels:
+ app: chaos-exporter
+ namespaceSelector:
+ matchNames:
+ - litmus
+ endpoints:
+ - port: tcp
+ interval: 1s
+ metricRelabelings:
+ - targetLabel: instance
+ replacement: 'chaos-exporter-service'
+```
+
+## Prometheus community version (helm) - kube-prometheus-stack with pod monitor
+
+- Clone the litmus repo
+
+```bash
+git clone https://github.com/litmuschaos/litmus.git
+cd litmus/monitoring
+```
+
+- Deploy chaos-exporter when the cluster is not connected to litmus 2.0 control plane via litmus chaos delegate (exporter is installed as a part of the chaos delegate bundle)
+
+```bash
+kubectl -n litmus apply -f utils/metrics-exporters/litmus-metrics/chaos-exporter/
+```
+
+- Create monitoring namespace on the cluster
+
+```bash
+kubectl create ns monitoring
+```
+
+- Install prometheus via helm
+
+```bash
+helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
+helm repo update
+helm install prom prometheus-community/kube-prometheus-stack --namespace monitoring
+```
+
+- Create the pod monitor as specified
+
+```yaml
+apiVersion: monitoring.coreos.com/v1
+kind: PodMonitor
+metadata:
+ name: chaos-exporter-monitor
+ namespace: monitoring
+ labels:
+ release: prometheus-stack
+spec:
+ selector:
+ matchLabels:
+ app: chaos-exporter
+ namespaceSelector:
+ matchNames:
+ - litmus
+ podMetricsEndpoints:
+ - port: tcp
+ - interval: 1s
+ metricRelabelings:
+ - targetLabel: instance
+ replacement: 'chaos-exporter-service'
+```
+
+## Prometheus alertmanager for generating alerts for experiment results
+
+Prometheus alerts can be triggered on alertmanager based on chaos experiment verdicts, probe success percentage and related metadata on the metric `litmuschaos_experiment_verdict` from `chaos-exporter`
+
+Link: [https://github.com/litmuschaos/tutorials/issues/6](https://github.com/litmuschaos/tutorials/issues/6)
+
+## promProbe for prometheus metrics
+
+The promProbe allows users to run Prometheus queries and match the resulting output against specific conditions. The intent behind this probe is to allow users to define metrics-based SLOs in a declarative way and determine the experiment verdict based on its success. The probe runs the query on a Prometheus server defined by the endpoint, and checks whether the output satisfies the specified criteria.
+
+Know more on promProbe [here](../concepts/probes.md)
+
+## Resources
+
+
+
+## Learn More
+
+- [Application and infrastructure monitoring](../concepts/app-infra-monitoring.md)
+- [Observability Setup](../user-guides/observability-set-up.md)
+- [Configure Data Source](../user-guides/configure-datasource.md)
+- [Grafana Integration](grafana.md)
diff --git a/website/versioned_docs/version-2.13.0/introduction/community.md b/website/versioned_docs/version-2.13.0/introduction/community.md
new file mode 100644
index 0000000..2eaa655
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/introduction/community.md
@@ -0,0 +1,78 @@
+---
+id: community
+title: Community driven Chaos Engineering
+sidebar_label: Community
+---
+
+---
+
+Created by our users, contributors, and adopters, the Litmus community truly believes in adding to the value of open source culture. Serving and listening to the community is a priority to us.
+
+We welcome Kubernetes SREs and Developers to join this zealous community to learn and share all about Cloud-Native Chaos Engineering. There are many contributors in our community who are ready to mentor those who want to contribute. Ask a question in [our slack channel](https://slack.litmuschaos.io/).
+
+## Join our Slack channel
+
+Join Our Community On Slack For Detailed Discussion, Feedback & Regular Updates On Chaos Engineering For Kubernetes, join `#litmus` on `Kubernetes Slack` and connect with SREs and Chaos Engineering enthusiasts.
+
+Join here: https://slack.litmuschaos.io/
+
+## Join our Community meetings
+
+We meet on every 3rd Wednesday of the month!
+
+#### Topics we discuss
+
+- Updates to Litmus in the last one month
+- Contributor Experiences & Insights
+- SIG-Documentation Charter
+ and many more!
+
+## Community Events
+
+Our resolve is to reach the global community and escalate the value of Cloud-Native Chaos Engineering among Kubernetes Developers and SREs. We organize meetups every month to reach out to the community. Join into one of our meetups and experience the real aura of Chaos. You can also conduct your own meetup, join our community, and put forward your idea.
+
+
+
+## Contribute
+
+We invite contributions in all forms. Join us in writing blogs on DEV.to about experiments, features, and your experience. Use the `#litmuschaos` tag for your blog to get featured.
+
+[Go to dev.to](https://dev.to/t/litmuschaos)
+
+### Contribute your chaos experiments
+
+We are devoted to being an open source driven community and appeal to our community members to contribute chaos experiments, file issues, raise pull requests, and provide feedback to help enhance the user experience and bring in new enhancements to develop LitmusChaos.
+
+Check out the [CONTRIBUTING.md](https://github.com/litmuschaos/litmus/blob/master/CONTRIBUTING.md) page on [Litmus repository](https://github.com/litmuschaos/litmus) for instructions on how to contribute. Feel free to discuss about your contributions on [our slack channel](https://slack.litmuschaos.io/).
+
+## Learn more
+
+- [Meta Repository](https://github.com/litmuschaos/litmus)
+- [Release Tracker](https://github.com/litmuschaos/litmus/milestones)
diff --git a/website/versioned_docs/version-2.13.0/introduction/core-principles.md b/website/versioned_docs/version-2.13.0/introduction/core-principles.md
new file mode 100644
index 0000000..ca27a9d
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/introduction/core-principles.md
@@ -0,0 +1,35 @@
+---
+id: core-principles
+title: Core principles of Litmus
+sidebar_label: Core principles
+---
+
+---
+
+
+
+Cloud Native Chaos Engineering, defined as engineering practices focused on (and built on) Kubernetes environments, applications, microservices, and infrastructure follows these core principles -
+
+## Driven by Open Source
+
+Cloud-native software provides the ideal platform for multi-cloud deployments because it is rooted in open-source standards established by the World Wide Web Consortium (W3C). Digital transformation requires real-time, event-driven data collection and the W3C βOne Webβ vision defines an ideal architecture for any data to run with any app across any W3C-compliant cloud.
+
+This principle focuses on the framework to be completely open-source under the Apache2 License to encourage broader community participation and inspection. The number of applications moving to the Kubernetes platform is limitless. At such a large scale, only the Open Chaos model will thrive and get the required adoption.
+
+## CRDs for Chaos Management
+
+Custom Resource Definition(CRD) is what you use to define a Custom Resource. This is a powerful way to extend Kubernetes capabilities beyond the default installation. These Kubernetes native CRDs defined here should be used as APIs for both Developers and SREs to build and orchestrate chaos testing. The CRDs act as standard APIs to provision and manage the chaos.
+
+## Extensible and Pluggable
+
+One lesson learned why cloud native approaches are winning is that their components can be relatively easily swapped out and new ones introduced as needed. Any standard chaos library or functionality developed by other open-source developers should be able to be integrated into and orchestrated for testing via this pluggable framework.
+
+## Broad Community Adoption
+
+Once we have the APIs, Operator, and plugin framework, we have all the ingredients needed for a common way of injecting chaos. The chaos will be run against a well-known infrastructure like Kubernetes or applications like databases or other infrastructure components like storage or networking. These chaos experiments can be reused, and a broad-based community is useful for identifying and contributing to other high-value scenarios. Hence a Chaos Engineering framework should provide a central hub or forge where open-source chaos experiments are shared, and collaboration via code is enabled.
+
+[Learn more about our community adoption](community.md)
+
+## GitOps for Chaos Management
+
+Use GitOps as an operational framework that takes DevOps best practices used for application development such as version control, collaboration, compliance, and CI/CD, and applies them to infrastructure automation. With the demands made on todayβs infrastructure, it has become increasingly crucial to implement infrastructure automation. Modern infrastructure needs to be elastic so that it can effectively manage cloud resources that are needed for continuous deployments.
diff --git a/website/versioned_docs/version-2.13.0/introduction/features.md b/website/versioned_docs/version-2.13.0/introduction/features.md
new file mode 100644
index 0000000..7cdc140
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/introduction/features.md
@@ -0,0 +1,82 @@
+---
+id: features
+title: Why should you choose Litmus?
+sidebar_label: Features
+---
+
+---
+
+The goal of the LitmusChaos project is to create a complete solution to implement chaos engineering at scale, the Kubernetes way! Of course, this had to be done incrementally by first creating a toolset for chaos injection and then adding additional features to make it a platform. Litmus 1.x achieved the goal of keeping it completely open-source, creating a [ChaosHub](../concepts/chaoshub.md) and the required CRDs, Operators, and Schedulers. With Litmus 1.x, users have a working chaos engineering toolset aligned with the original goals.
+
+Over time, with the monthly cadence releases and community engagement, we have added a lot of features and made LitmusChaos much easier for the end-users. With the launch of Litmus 2.0, a new way of chaos engineering can be performed by the users, a few high-level features are mentioned [below](features.md#advantages-of-litmus-20), however a detailed list can be found on the [release page](https://github.com/litmuschaos/litmus/releases).
+
+## Advantages of Litmus 2.0
+
+A high-level feature overview of Litmus 2.0 are as follows
+
+- The Addition of [Chaos Scenario](../concepts/chaos-workflow.md) creation, Chaos experiments become building blocks of a Chaos Scenario, to allow users to create a larger chaos scenario using sequential or parallel experiment executions.
+- Addition of [ChaosCenter](../getting-started/resources.md#chaoscenter) where you can take advantage of all these features and a lot more
+ - Chaos Scenario Creation
+
+
+
From Templates, Custom Chaos Scenarios 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 Scenarios as Schedules
+
Attaching priority to Chaos Experiments based on your use cases
Allowing image addition from custom image server (both public and private)
+
Measure and Analyse the Resilience Score of each chaos scenario
+
+
+
+Litmus itself is composed of microservices. And we made sure that by adding the above features for 2.0, seamlessly integrates the additional microservices in conjunction with the existing one. Litmus 2.0 is completely backwards compatible. No features are deprecated.
+
+The migration path is about constructing new artifacts such as Chaos Scenarios that include the current chaos experiments in use by the users.
+
+## Feature Comparison between 1.x and 2.0
+
+Below is a high level comparison between Litmus 1.x and Litmus 2.0 providing a holistic view of the feature additions you get in Litmus 2.0.
+
+| Litmus 1.x | Litmus 2.0 |
+| -------------------- | ------------------------------------- |
+| Experiments | Chaos Scenarios |
+| Per user | Teams (Multi Tenant) |
+| Per cluster | Per organisation (Cross Cloud) |
+| Only Public ChaosHub | Public and Private ChaosHubs |
+| CLI only | CLI and GUI |
+| | GitOps |
+| | Scalability |
+| | Integrated and Interleaved monitoring |
+
+## Learn more
+
+- [Run your first chaos scenario in 5 minutes](../getting-started/run-your-first-workflow.md)
+- [Install Litmus](../getting-started/installation.md)
+- [Visualize Chaos Scenarios](../concepts/visualize-workflow.md)
+- Chaos Schedule
+- [Monitoring](../concepts/app-infra-monitoring.md)
+- [View the different User Guides](../user-guides/overview.md)
diff --git a/website/versioned_docs/version-2.13.0/introduction/other-links.md b/website/versioned_docs/version-2.13.0/introduction/other-links.md
new file mode 100644
index 0000000..060b563
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/introduction/other-links.md
@@ -0,0 +1,42 @@
+---
+id: other-links
+title: Find more about Litmus
+sidebar_label: More Resources
+---
+
+---
+
+You can learn more about Litmus using the following resources available
+
+### Official Website
+
+Check out the official website and get updates and what is happening around the LitmusChaos Community and all new feature releases.
+
+https://litmuschaos.io/
+
+## Follow Litmus
+
+Follow us on social media platforms and never miss an update
+
+- [Twitter](https://twitter.com/LitmusChaos)
+- [GitHub](https://github.com/litmuschaos/litmus)
+- [YouTube](https://www.youtube.com/channel/UCa57PMqmz_j0wnteRa9nCaw)
+
+## Blogs by Community and Contributors
+
+Check out the variety of blogs on Litmus written solely by the maintainers, contributors and community folks.
+
+- [Check out blogs on Dev.to](https://dev.to/t/litmuschaos/latest)
+- [Check out blogs on Medium](https://medium.com/litmus-chaos)
+
+## ChaosHub
+
+Check out all the information related to Chaos Experiments available publicly at ChaosHub (The center Hub/Repository for all your chaos experiments)
+
+http://hub.litmuschaos.io/
+
+## Join the Community
+
+We welcome Kubernetes SREs and Developers to join this zealous community to learn and share all about Cloud-Native Chaos Engineering.
+
+[Be a part of the community now.](community.md)
diff --git a/website/versioned_docs/version-2.13.0/introduction/usage.md b/website/versioned_docs/version-2.13.0/introduction/usage.md
new file mode 100644
index 0000000..edf36c7
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/introduction/usage.md
@@ -0,0 +1,32 @@
+---
+id: usage
+title: Uses of Litmus
+sidebar_label: Uses of Litmus
+---
+
+---
+
+Chaos tests can be done anywhere in the DevOps cycle. The extent of chaos tests varies from CI pipelines to production. In development pipelines, you might use chaos tests specific to applications being developed. As you move towards operations or production, you will expect a lot of failure scenarios for which you want to be resilient against, hence the number of chaos tests grows significantly.
+
+
+
+## Common Use Cases
+
+Typical use cases of Litmus include β failure or chaos testing in CI pipelines, increased chaos testing in staging and production and production environments, Kubernetes upgrades certification, post-upgrade validation of services, and resilience benchmarking, etc.
+
+- **For Developers:** To run chaos experiments during application development as an extension of unit testing or integration testing.
+- **For CI pipeline builders:** To run chaos as a pipeline stage to find bugs when the application is subjected to fail paths in a pipeline.
+- **For SREs:** To plan and schedule chaos experiments into the application and/or surrounding infrastructure. This practice identifies the weaknesses in the system and increases resilience.
+
+We keep hearing from SREs that they typically see a lot of resistance for introducing chaos from both developers and management. In the practice of chaos engineering, starting with small chaos tests and showing the benefits to developers and management will result in the initially required credibility. With time, the number of tests and associated resilience also will increase.
+
+
+
+Chaos Engineering is a practice. As seen above, with time, management buying and the SRE confidence will increase, and they move the chaos tests into production. This process will increase resilience metrics, as well.
+
+## Learn more
+
+- [Understand the Core Principles of Litmus](core-principles.md)
+- [Be a part of the Community](community.md)
+- [Get Started with Litmus](../getting-started/installation.md)
+- [Check out more resources about Litmus](other-links.md)
diff --git a/website/versioned_docs/version-2.13.0/introduction/what-is-litmus.md b/website/versioned_docs/version-2.13.0/introduction/what-is-litmus.md
new file mode 100644
index 0000000..4756775
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/introduction/what-is-litmus.md
@@ -0,0 +1,38 @@
+---
+id: what-is-litmus
+title: What is Litmus?
+sidebar_label: Litmus
+---
+
+---
+
+
+
+LitmusChaos is a Cloud-Native Chaos Engineering Framework with cross-cloud support. It is a CNCF Sandbox project with adoption across several organizations. Its mission is to help Kubernetes SREs and Developers to find weaknesses in both Non-Kubernetes as well as platforms and applications running on Kubernetes by providing a complete Chaos Engineering framework and associated Chaos Experiments.
+
+Litmus can be used to run chaos experiments initially in the staging environment and eventually in production to find bugs and vulnerabilities, fixing which leads to an increased resilience of the system. Litmus adopts a `Kubernetes-native` approach to define chaos intent in a declarative manner via custom resources.
+
+## Importance of Resilience
+
+
+
+Kubernetes is being run on a variety of infrastructure, ranging from virtual machines to bare metal and a combination of them. The platformβs physical nature is a source of faults to the application that runs inside containers, as shown in the tip of the above diagram. The next layer of dependency is Kubernetes itself.
+
+Your application resilience really depends more on the underlying stack than your application itself. It is possible that once your application is stabilized, the resilience of your service that runs on Kubernetes depends on other components and infrastructure more than 90% of the time.
+
+Thus it is important to verify your application resilience whenever a change has happened in the underlying stack. **Keep verifying** is the key. Robust testing before upgrades is not good enough, mainly because you cannot possibly consider all sorts of faults during upgrade testing. This introduces the concept of Chaos Engineering. The process of "**continuously verifying** if your service is resilient against faults" is called Chaos Engineering.
+
+## What is a Chaos Experiment
+
+Chaos Experiments are fundamental units within the LitmusChaos architecture. Users can choose between readily available chaos experiments or create new ones to construct a required Chaos Scenario.
+
+## What is a Chaos Scenarios
+
+A chaos scenario is much more than a simple chaos experiment. It supports the user in defining the expected result, observing the result, analysing the overall system behaviour, and in the decision-making process if the system needs to be tuned for improving the resilience.
+
+## How to Contribute
+
+- If you are a first-time contributor, please see [Steps to Contribute](https://github.com/litmuschaos/litmus/blob/master/CONTRIBUTING.md#steps-to-contribute-).
+- If you would like to suggest new tests to be added to litmus, please go ahead and [create a new issue](https://github.com/litmuschaos/litmus/issues/new) describing your test. All you need to do is specify the workload type and the operations that you would like to perform on the workload.
+- If you would like to work on something more involved, please connect with the Litmus Contributors.
+- If you would like to make code contributions, all your commits should be signed with Developer Certificate of Origin. See [Sign your work](https://github.com/litmuschaos/litmus/blob/master/CONTRIBUTING.md#sign-your-work).
diff --git a/website/versioned_docs/version-2.13.0/litmusctl/chaos-workflow-creation.md b/website/versioned_docs/version-2.13.0/litmusctl/chaos-workflow-creation.md
new file mode 100644
index 0000000..f616d9b
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/litmusctl/chaos-workflow-creation.md
@@ -0,0 +1,131 @@
+---
+id: chaos-workflow-creation
+title: Create Scenarios using Litmusctl
+sidebar_label: Create Chaos Scenarios
+---
+
+---
+
+> Notes:
+>
+> - For litmusctl v0.10.0 or latest
+> - Compatible with Litmus 2.9.0 or latest
+
+### litmusctl Syntax
+
+`litmusctl` has a syntax to use as follows:
+
+```shell
+litmusctl [command] [TYPE] [flags]
+```
+
+- Command: refers to what you do want to perform (create, get and config)
+- Type: refers to the feature type you are performing a command against (chaos delegate, project etc.)
+- Flags: It takes some additional information for resource operations. For example, `--installation-mode` allows you to specify an installation mode.
+
+Litmusctl is using the `.litmusconfig` config file to manage multiple accounts
+
+1. If the --config flag is set, then only the given file is loaded. The flag may only be set once and no merging takes place.
+2. Otherwise, the ${HOME}/.litmusconfig file is used, and no merging takes place.
+
+---
+
+### Steps to create a Chaos Scenario
+
+- To setup an account with litmusctl
+
+```shell
+litmusctl config set-account --endpoint="" --username="" --password=""
+```
+
+- To create a Chaos Scenario by passing a manifest file
+ > Note:
+ >
+ > - To get `project-id`, apply `litmusctl get projects`
+ > - To get `chaos-delegate-id`, apply `litmusctl get chaos-delegates --project-id=""`
+
+```shell
+litmusctl create chaos-scenario -f custom-chaos-scenario.yml --project-id="" --chaos-delegate-id=""
+```
+
+#### Verify the new Chaos Scenario
+
+To verify the successful creation, you can either view the list of chaos scenarios at the ChaosCenter dashboard or run the below given command to list the chaos scenarios within a given project.
+
+```shell
+litmusctl get chaos-scenarios --project-id=""
+```
+
+**Output:**
+
+```
+CHAOS SCENARIO ID CHAOS SCENARIO NAME CHAOS SCENARIO TYPE NEXT SCHEDULE CHAOS DELEGATE ID CHAOS DELEGATE NAME LAST UPDATED BY
+9433b48c-4ab7-4544-8dab-4a7237619e09 custom-chaos-scenario-1627980541 Non Cron Scenario None f9799723-29f1-454c-b830-ae8ba7ee4c30 Self-Chaos-Delegate admin
+Showing 1 of 1 chaos scenarios
+```
+
+---
+
+### Additional commands
+
+- To list all the chaos scenario runs within a project, issue the following command.
+
+```shell
+litmusctl get chaos-scenario-runs --project-id=""
+```
+
+**Output:**
+
+```
+CHAOS SCENARIO RUN ID STATUS RESILIENCY SCORE CHAOS SCENARIO ID CHAOS SCENARIO NAME TARGET CHAOS DELEGATE LAST RUN EXECUTED BY
+8ceb712c-1ed4-40e6-adc4-01f78d281506 Running 0.00 9433b48c-4ab7-4544-8dab-4a7237619e09 custom-chaos-scenario-1627980541 Self-Chaos-Delegate June 1 2022, 10:28:02 pm admin
+Showing 1 of 1 scenario runs
+```
+
+- To describe a particular chaos scenario, issue the following command.
+
+```shell
+litmusctl describe chaos-scenario 9433b48c-4ab7-4544-8dab-4a7237619e09 --project-id=""
+```
+
+**Output:**
+
+```
+apiVersion: argoproj.io/v1alpha1
+kind: Workflow
+metadata:
+ creationTimestamp: null
+ labels:
+ cluster_id: f9799723-29f1-454c-b830-ae8ba7ee4c30
+ subject: custom-chaos-scenario_litmus
+ workflow_id: 9433b48c-4ab7-4544-8dab-4a7237619e09
+ workflows.argoproj.io/controller-instanceid: f9799723-29f1-454c-b830-ae8ba7ee4c30
+ name: custom-chaos-scenario-1627980541
+ namespace: litmus
+spec:
+...
+```
+
+- To delete a particular chaos scenario, issue the following command.
+
+```shell
+litmusctl delete chaos-scenario df91c6b2-ad33-45ae-9a2f-00cb87978657 --project-id=""
+```
+
+**Output:**
+
+```
+π Chaos scenario successfully deleted.
+```
+
+For more information related to flags, Use `litmusctl --help`.
+
+---
+
+## Learn More
+
+- [Learn More about Litmusctl](installation.md)
+- [Installing Chaos Delegate in interactive mode](./usage-interactive-mode.md)
+- [Installing Chaos Delegate in non interactive mode](./usage-non-interactive-mode.md)
+- [Setup Endpoints and Access ChaosCenter without Ingress](../user-guides/setup-without-ingress.md)
+- [Setup Endpoints and Access ChaosCenter with Ingress](../user-guides/setup-with-ingress.md)
diff --git a/website/versioned_docs/version-2.13.0/litmusctl/installation.md b/website/versioned_docs/version-2.13.0/litmusctl/installation.md
new file mode 100644
index 0000000..617b19a
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/litmusctl/installation.md
@@ -0,0 +1,223 @@
+---
+id: installation
+title: Litmusctl
+sidebar_label: Installation
+---
+
+---
+
+The Litmuschaos command-line tool, litmusctl, allows you to manage litmuschaos's chaos delegate plane. You can use litmusctl to connect and disconnect chaos delegates, create chaos scenarios, project, and manage multiple litmuschaos accounts.
+
+## Prerequisites
+
+Litmusctl CLI requires the following things:
+
+- **kubeconfig** - litmusctl needs the kubeconfig of the k8s cluster where we need to connect litmus chaos delegates. The CLI currently uses the default path of kubeconfig i.e. `~/.kube/config`.
+- **kubectl** - litmusctl is using kubectl under the hood to apply the manifest.
+ > To install kubectl, follow: [kubectl](https://kubernetes.io/docs/tasks/tools/#kubectl)
+
+## Usage
+
+For more information including a complete list of litmusctl operations, see the litmusctl reference documentation.
+
+- For v0.12.0 or latest: Click here
+- For v0.2.0 or earlier: Click here
+
+## Compatibility matrix
+
+To check compatibility of litmusctl with Chaos Center
+
+
+
litmusctl version
+
Chaos Center supported versions
+
+
+
0.6.0
+
2.2.0, 2.3.0
+
+
+
0.7.0
+
2.4.0, 2.5.0, 2.6.0, 2.7.0, 2.8.0
+
+
+
0.8.0
+
2.4.0, 2.5.0, 2.6.0, 2.7.0, 2.8.0
+
+
+
0.9.0
+
2.4.0, 2.5.0, 2.6.0, 2.7.0, 2.8.0
+
+
+
0.10.0
+
2.9.0, 2.10.0, 2.11.0, 2.12.0, 2.13.0
+
+
+
0.11.0
+
2.9.0, 2.10.0, 2.11.0, 2.12.0, 2.13.0
+
+
+
0.12.0
+
2.9.0, 2.10.0, 2.11.0, 2.12.0, 2.13.0
+
+
+
0.13.0
+
2.9.0, 2.10.0, 2.11.0, 2.12.0, 2.13.0
+
+
+
+## Installation
+
+To install the latest version of litmusctl follow the below steps:
+
+
+
+### Linux/MacOS
+
+- Extract the binary
+
+```shell
+tar -zxvf litmusctl---.tar.gz
+```
+
+- Provide necessary permissions
+
+```shell
+chmod +x litmusctl
+```
+
+- Move the litmusctl binary to /usr/local/bin/litmusctl. Note: Make sure to use root user or use sudo as a prefix
+
+```shell
+mv litmusctl /usr/local/bin/litmusctl
+```
+
+- You can run the litmusctl command in Linux/macOS:
+
+```shell
+litmusctl [options and parameters]
+```
+
+### Windows
+
+- Extract the binary from the zip using WinZip or any other extraction tool.
+
+- You can run the litmusctl command in windows:
+
+```shell
+litmusctl.exe [options and parameters]
+```
+
+- To check the version of the litmusctl:
+
+```shell
+litmusctl version
+```
+
+---
diff --git a/website/versioned_docs/version-2.13.0/litmusctl/usage-interactive-mode.md b/website/versioned_docs/version-2.13.0/litmusctl/usage-interactive-mode.md
new file mode 100644
index 0000000..4ef0218
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/litmusctl/usage-interactive-mode.md
@@ -0,0 +1,423 @@
+---
+id: usage-interactive-mode
+title: Installing Chaos Delegate in interactive mode
+sidebar_label: Using interactive mode
+---
+
+---
+
+# Usage: Litmusctl v0.12.0 (Interactive mode)
+
+> Notes:
+>
+> - For litmusctl v0.12.0 or latest
+> - Compatible with Litmus 2.12.0 or latest
+
+### litmusctl Syntax
+
+`litmusctl` has a syntax to use as follows:
+
+```shell
+litmusctl [command] [TYPE] [flags]
+```
+
+- Command: refers to what you do want to perform (connect, create, get and config)
+- Type: refers to the feature type you are performing a command against (chaos-delegate, project etc.)
+- Flags: It takes some additional information for resource operations. For example, `--installation-mode` allows you to specify an installation mode.
+
+Litmusctl is using the `.litmusconfig` config file to manage multiple accounts
+
+1. If the --config flag is set, then only the given file is loaded. The flag may only be set once and no merging takes place.
+2. Otherwise, the ${HOME}/.litmusconfig file is used, and no merging takes place.
+
+Litmusctl supports both interactive and non-interactive(flag based) modes.
+
+> Only `litmusctl connect chaos-delegate` command needs --non-interactive flag, other commands don't need this flag to be in non-interactive mode. If mandatory flags aren't passed, then litmusctl takes input in an interactive mode.
+
+Multiple external Chaos Delegate can be connected to the ChaosCenter with the help of the command line utility [litmusctl](installation.md)
+
+### Steps to connect a Chaos Delegate
+
+- To setup an account with litmusctl
+
+```shell
+litmusctl config set-account
+```
+
+Next, you need to enter ChaosCenter details to login into your ChaosCenter account. Fields to be filled in:
+
+**ChaosCenter URL:** Enter the URL used to access the ChaosCenter.
+
+> Example, https://preview.litmuschaos.io/
+
+**Username:** Enter your ChaosCenter username.
+**Password:** Enter your ChaosCenter password.
+
+```
+Host endpoint where litmus is installed: https://preview.litmuschaos.io/
+Username [Default: admin]: admin
+
+Password:
+account.username/admin configured
+```
+
+- To connect a Chaos Delegate in a cluster mode
+
+```shell
+litmusctl connect chaos-delegate
+```
+
+There will be a list of existing projects displayed on the terminal. Select the desired project by entering the sequence number indicated against it.
+
+```
+Project list:
+1. Project-Admin
+
+Select a project [Range: 1-1]: 1
+```
+
+Next, select the installation mode based on your requirement by entering the sequence number indicated against it.
+
+Litmusctl can install a Chaos Delegate in two different modes.
+
+- cluster mode: With this mode, the Chaos Delegate can run the chaos in any namespace. It installs appropriate cluster roles and cluster role bindings to achieve this mode.
+
+- namespace mode: With this mode, the Chaos Delegate can run the chaos in its namespace. It installs appropriate roles and role bindings to achieve this mode.
+
+Note: With namespace mode, the user needs to create the namespace to install the Chaos Delegate as a prerequisite.
+
+```
+Installation Modes:
+1. Cluster
+2. Namespace
+
+Select Mode [Default: cluster] [Range: 1-2]: 1
+
+π Running prerequisites check....
+π clusterrole β
+π clusterrolebinding β
+π Sufficient permissions. Installing the Chaos Delegate...
+
+```
+
+Next, enter the details of the new Chaos Delegate.
+
+Fields to be filled in
+
+
+
Field
+
Description
+
+
Chaos Delegate Name:
+
Enter a name of the Chaos Delegate which needs to be unique across the project
+
+
+
Chaos Delegate Description:
+
Fill in details about the Chaos Delegate
+
+
+
Skip SSL verification
+
Choose whether Chaos Delegate will skip SSL/TLS verification
+
+
+
Node Selector:
+
To deploy the Chaos Delegate on a particular node based on the node selector labels
+
+
+
Platform Name:
+
Enter the platform name on which this Chaos Delegate is hosted. For example, AWS, GCP, Rancher etc.
+
+
+
Enter the namespace:
+
You can either enter an existing namespace or enter a new namespace. In cases where the namespace does not exist, litmusctl creates it for you
+
+
+
Enter service account:
+
You can either enter an existing or new service account
+
+
+
+```
+Enter the details of the Chaos Delegate
+
+Chaos Delegate Name: New-Chaos-Delegate
+
+Chaos Delegate Description: This is a new Chaos Delegate
+
+Do you want Chaos Delegate to skip SSL/TLS check (Y/N) (Default: N): n
+
+Do you want NodeSelector to be added in the Chaos Delegate deployments (Y/N) (Default: N): N
+
+Platform List:
+1. AWS
+2. GKE
+3. Openshift
+4. Rancher
+5. Others
+
+Select a platform [Default: Others] [Range: 1-5]: 5
+
+Enter the namespace (new or existing namespace) [Default: litmus]:
+π Continuing with litmus namespace
+```
+
+Once, all these steps are implemented you will be able to see a summary of all the entered fields.
+After verification of these details, you can proceed with the connection of the Chaos Delegate by entering Y. The process of connection might take up to a few seconds.
+
+```
+Enter service account [Default: litmus]:
+
+π Summary
+Chaos Delegate Name: New-Chaos-Delegate
+Chaos Delegate Description: This is a new Chaos Delegate
+Chaos Delegate SSL/TLS Skip: false
+Platform Name: Others
+Namespace: litmus
+Service Account: litmus (new)
+
+Installation Mode: cluster
+
+π€· Do you want to continue with the above details? [Y/N]: Y
+π Continuing Chaos Delegate connection!!
+Applying YAML:
+https://preview.litmuschaos.io/api/file/eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJjbHVzdGVyX2lkIjoiMDUyZmFlN2UtZGM0MS00YmU4LWJiYTgtMmM4ZTYyNDFkN2I0In0.i31QQDG92X5nD6P_-7TfeAAarZqLvUTFfnAghJYXPiM.yaml
+
+π‘ Connecting Chaos Delegate to ChaosCenter.
+π Chaos Delegate is running!!
+
+π Chaos Delegate Connection Successful!! π
+π Litmus Chaos Delegates can be accessed here: https://preview.litmuschaos.io/targets
+```
+
+#### Verify the new Chaos Delegate Connection\*\*
+
+To verify, if the connection process was successful you can view the list of connected Chaos Delegates from the Targets section on your ChaosCenter and ensure that the connected Chaos Delegate is in Active State.
+
+---
+
+### Steps to create a Chaos Scenario
+
+* To setup an account with litmusctl
+```shell
+litmusctl config set-account --endpoint="" --username="" --password=""
+```
+
+* To create a Chaos Scenario by passing a manifest file
+> Note:
+> * To get `project-id`, apply `litmusctl get projects`
+> * To get `chaos-delegate-id`, apply `litmusctl get chaos-delegates --project-id=""`
+```shell
+litmusctl create chaos-scenario -f custom-chaos-scenario.yml --project-id="" --chaos-delegate-id=""
+```
+
+---
+
+### Additional commands
+
+- To view the current configuration of `.litmusconfig`, type:
+
+```shell
+litmusctl config view
+```
+
+**Output:**
+
+```
+accounts:
+- users:
+ - expires_in: "1626897027"
+ token: eyJhbGciOiJIUzUxMiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE2MjY4OTcwMjcsInJvbGUiOiJhZG1pbiIsInVpZCI6ImVlODZkYTljLTNmODAtNGRmMy04YzQyLTExNzlhODIzOTVhOSIsInVzZXJuYW1lIjoiYWRtaW4ifQ.O_hFcIhxP4rhyUN9NEVlQmWesoWlpgHpPFL58VbJHnhvJllP5_MNPbrRMKyFvzW3hANgXK2u8437u
+ username: admin
+ - expires_in: "1626944602"
+ token: eyJhbGciOiJIUzUxMiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE2MjY5NDQ2MDIsInJvbGUiOiJ1c2VyIiwidWlkIjoiNjFmMDY4M2YtZWY0OC00MGE1LWIzMjgtZTU2ZDA2NjM1MTE4IiwidXNlcm5hbWUiOiJyYWoifQ.pks7xjkFdJD649RjCBwQuPF1_QMoryDWixSKx4tPAqXI75ns4sc-yGhMdbEvIZ3AJSvDaqTa47XTC6c8R
+ username: litmus-user
+ endpoint: https://preview.litmuschaos.io
+apiVersion: v1
+current-account: https://preview.litmuschaos.io
+current-user: litmus-user
+kind: Config
+```
+
+- To get an overview of the accounts available within `.litmusconfig`, use the `config get-accounts` command:
+
+```shell
+litmusctl config get-accounts
+```
+
+**Output:**
+
+```
+CURRENT ENDPOINT USERNAME EXPIRESIN
+ https://preview.litmuschaos.io admin 2021-07-22 01:20:27 +0530 IST
+* https://preview.litmuschaos.io raj 2021-07-22 14:33:22 +0530 IST
+```
+
+- To alter the current account use the `use-account` command:
+
+```shell
+litmusctl config use-account
+
+Host endpoint where litmus is installed: https://preview.litmuschaos.io
+
+Username: admin
+```
+
+- To create a project, apply the following command :
+
+```shell
+litmusctl create project
+
+Enter a project name: new
+```
+
+- To view all the projects with the user, use the `get projects` command.
+
+```shell
+litmusctl get projects
+```
+
+**Output:**
+
+```
+PROJECT ID PROJECT NAME CREATEDAT
+50addd40-8767-448c-a91a-5071543a2d8e Developer Project 2021-07-21 14:38:51 +0530 IST
+7a4a259a-1ae5-4204-ae83-89a8838eaec3 DevOps Project 2021-07-21 14:39:14 +0530 IST
+```
+
+- To get an overview of the Chaos Delegates available within a project, issue the following command.
+
+```shell
+litmusctl get chaos-delegates
+
+Enter the Project ID: 50addd40-8767-448c-a91a-5071543a2d8e
+```
+
+**Output:**
+
+```
+CHAOS DELEGATE ID CHAOS DELEGATE NAME STATUS REGISTRATION
+55ecc7f2-2754-43aa-8e12-6903e4c6183a chaos-delegate-1 ACTIVE REGISTERED
+13dsf3d1-5324-54af-4g23-5331g5v2364f chaos-delegate-2 INACTIVE NOT REGISTERED
+```
+
+
+* To disconnect an Chaos Delegate, issue the following command..
+```shell
+litmusctl disconnect chaos-delegate --project-id=""
+```
+
+**Output:**
+
+```
+π Chaos Delegate successfully disconnected.
+```
+
+
+* To list the created Chaos Scenarios within a project, issue the following command.
+```shell
+litmusctl get chaos-scenarios --project-id=""
+```
+
+**Output:**
+
+```
+CHAOS SCENARIO ID CHAOS SCENARIO NAME CHAOS SCENARIO TYPE NEXT SCHEDULE CHAOS DELEGATE ID CHAOS DELEGATE NAME LAST UPDATED BY
+9433b48c-4ab7-4544-8dab-4a7237619e09 custom-chaos-scenario-1627980541 Non Cron Chaos Scenario None f9799723-29f1-454c-b830-ae8ba7ee4c30 Self-Chaos-delegate admin
+
+Showing 1 of 1 Chaos Scenarios
+```
+
+
+* To list all the Chaos Scenario runs within a project, issue the following command.
+```shell
+litmusctl get chaos-scenario-runs --project-id=""
+```
+
+**Output:**
+
+```
+CHAOS SCENARIO RUN ID STATUS RESILIENCY SCORE CHAOS SCENARIO ID CHAOS SCENARIO NAME TARGET CHAOS DELEGATE LAST RUN EXECUTED BY
+8ceb712c-1ed4-40e6-adc4-01f78d281506 Running 0.00 9433b48c-4ab7-4544-8dab-4a7237619e09 custom-chaos-scenario-1627980541 Self-Chaos-Delegate June 1 2022, 10:28:02 pm admin
+
+Showing 1 of 1 Chaos Scenario runs
+```
+
+
+* To describe a particular Chaos Scenario, issue the following command.
+```shell
+litmusctl describe chaos-scenario --project-id=""
+```
+
+**Output:**
+
+```
+apiVersion: argoproj.io/v1alpha1
+kind: Workflow
+metadata:
+ creationTimestamp: null
+ labels:
+ cluster_id: f9799723-29f1-454c-b830-ae8ba7ee4c30
+ subject: custom-chaos-scenario_litmus
+ workflow_id: 9433b48c-4ab7-4544-8dab-4a7237619e09
+ workflows.argoproj.io/controller-instanceid: f9799723-29f1-454c-b830-ae8ba7ee4c30
+ name: custom-chaos-scenario-1627980541
+ namespace: litmus
+spec:
+...
+```
+
+
+* To delete a particular Chaos Scenario, issue the following command.
+```shell
+litmusctl delete chaos-scenario --project-id=""
+```
+
+**Output:**
+
+```
+π Chaos Scenario successfully deleted.
+```
+
+---
+
+## Flag details
+
+
+
Flag
+
Short Flag
+
Type
+
Description
+
+
--cacert
+
+
String
+
custom ca certificate used by litmusctl for communicating with portal
+
+
+
--config
+
+
String
+
config file (default is $HOME/.litmusctl)
+
+
+
--skipSSL
+
+
Boolean
+
litmusctl will skip ssl/tls verification while communicating with portal
+
+
+
--help
+
-h
+
+
help for litmusctl
+
+
+
+For more information related to flags, Use `litmusctl --help`.
+## Learn More
+
+- [Learn More about Litmusctl](installation.md)
+- [Installing Chaos Delegates in non interactive mode](./usage-non-interactive-mode.md)
+- [Create Chaos Scenarios using Litmusctl](./chaos-workflow-creation.md)
+- [Setup Endpoints and Access ChaosCenter without Ingress](../user-guides/setup-without-ingress.md)
+- [Setup Endpoints and Access ChaosCenter with Ingress](../user-guides/setup-with-ingress.md)
diff --git a/website/versioned_docs/version-2.13.0/litmusctl/usage-non-interactive-mode.md b/website/versioned_docs/version-2.13.0/litmusctl/usage-non-interactive-mode.md
new file mode 100644
index 0000000..2f62112
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/litmusctl/usage-non-interactive-mode.md
@@ -0,0 +1,329 @@
+---
+id: usage-non-interactive-mode
+title: Installing Chaos Delegates in non interactive mode
+sidebar_label: Using non interactive mode
+---
+
+---
+
+# Usage: Litmusctl v0.12.0
+
+> Notes:
+>
+> - For litmusctl v0.12.0 or latest
+> - Compatible with Litmus 2.12.0 or latest
+
+### litmusctl Syntax
+`litmusctl` has a syntax to use as follows:
+
+```shell
+litmusctl [command] [TYPE] [flags]
+```
+* Command: refers to what you do want to perform (connect, create, get and config)
+* Type: refers to the feature type you are performing a command against (chaos-delegate, project etc.)
+* Flags: It takes some additional information for resource operations. For example, `--installation-mode` allows you to specify an installation mode.
+
+Litmusctl is using the `.litmusconfig` config file to manage multiple accounts
+1. If the --config flag is set, then only the given file is loaded. The flag may only be set once and no merging takes place.
+2. Otherwise, the ${HOME}/.litmusconfig file is used, and no merging takes place.
+
+Litmusctl supports both interactive and non-interactive(flag based) modes.
+> Only `litmusctl connect chaos-delegate` command needs --non-interactive flag, other commands don't need this flag to be in non-interactive mode. If mandatory flags aren't passed, then litmusctl takes input in an interactive mode.
+
+### Installation modes
+Litmusctl can install a Chaos Delegate in two different modes.
+* cluster mode: With this mode, the Chaos Delegate can run the chaos in any namespace. It installs appropriate cluster roles and cluster role bindings to achieve this mode. It can be enabled by passing a flag `--installation-mode=cluster`
+
+* namespace mode: With this mode, the Chaos Delegate can run the chaos in its namespace. It installs appropriate roles and role bindings to achieve this mode. It can be enabled by passing a flag `--installation-mode=namespace`
+
+Note: With namespace mode, the user needs to create the namespace to install the Chaos Delegate as a prerequisite.
+
+### Minimal steps to connect a Chaos Delegate
+
+* To setup an account with litmusctl
+```shell
+litmusctl config set-account --endpoint="" --username="" --password=""
+```
+
+* To create an Chaos Delegate with an existing project
+> Note: To get `project-id`. Apply `litmusctl get projects`
+
+```shell
+litmusctl connect chaos-delegate --name="" --project-id="" --non-interactive
+```
+
+### Flags for `connect chaos-delegate` command
+
+
Flag
+
Short Flag
+
Type
+
Description
+
+
--description
+
+
String
+
Set the Chaos Delegate description (default "---")
+
+
+
--name
+
+
String
+
Set the name of Chaos Delegate which should be unique
+
+
+
--skip-ssl
+
+
Boolean
+
Set whether Chaos Delegate will skip ssl/tls check (can be used for self-signed certs, if cert is not provided in portal) (default false)
+
+
+
--chaos-delegate-type
+
+
String
+
Set the chaos-delegate-type to external for external Chaos Delegates | Supported=external/internal (default "external")
+
+
+
--installation-mode
+
+
String
+
Set the installation mode for the kind of Chaos Delegate | Supported=cluster/namespace (default "cluster")
+
+
+
--kubeconfig
+
-k
+
String
+
Set to pass kubeconfig file if it is not in the default location ($HOME/.kube/config)
+
+
+
--namespace
+
+
String
+
Set the namespace for the Chaos Delegate installation (default "litmus")
+
+
+
--node-selector
+
+
String
+
Set the node-selector for Chaos Delegate components | Format: key1=value1,key2=value2)
+
+
+
--non-interactive
+
-n
+
String
+
Set it to true for non interactive mode | Note: Always set the boolean flag as --non-interactive=Boolean
+
+
+
--ns-exists
+
+
Boolean
+
Set the --ns-exists=false if the namespace mentioned in the --namespace flag is not existed else set it to --ns-exists=true | Note: Always set the boolean flag as --ns-exists=Boolean
+
+
+
--platform-name
+
+
String
+
Set the platform name. Supported- AWS/GKE/Openshift/Rancher/Others (default "Others")
+
+
+
--sa-exists
+
+
Boolean
+
Set the --sa-exists=false if the service-account mentioned in the --service-account flag is not existed else set it to --sa-exists=true | Note: Always set the boolean flag as --sa-exists=Boolean"
+
+
+
--service-account
+
+
String
+
Set the service account to be used by the Chaos Delegate (default "litmus")
+
+
+
--config
+
+
String
+
config file (default is $HOME/.litmusctl)
+
+
+
+---
+
+### Steps to create a chaos scenaro
+
+* To setup an account with litmusctl
+```shell
+litmusctl config set-account --endpoint="" --username="" --password=""
+```
+
+* To create a Chaos Scenario by passing a manifest file
+> Note:
+> * To get `project-id`, apply `litmusctl get projects`
+> * To get `chaos-delegate-id`, apply `litmusctl get chaos-delegates --project-id=""`
+```shell
+litmusctl create chaos-scenario -f custom-chaos-scenario.yml --project-id="" --chaos-delegate-id=""
+```
+
+---
+
+### Additional commands
+
+* To view the current configuration of `.litmusconfig`, type:
+```shell
+litmusctl config view
+```
+
+**Output:**
+```
+accounts:
+- users:
+ - expires_in: "1626897027"
+ token: eyJhbGciOiJIUzUxMiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE2MjY4OTcwMjcsInJvbGUiOiJhZG1pbiIsInVpZCI6ImVlODZkYTljLTNmODAtNGRmMy04YzQyLTExNzlhODIzOTVhOSIsInVzZXJuYW1lIjoiYWRtaW4ifQ.O_hFcIhxP4rhyUN9NEVlQmWesoWlpgHpPFL58VbJHnhvJllP5_MNPbrRMKyFvzW3hANgXK2u8437u
+ username: admin
+ - expires_in: "1626944602"
+ token: eyJhbGciOiJIUzUxMiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE2MjY5NDQ2MDIsInJvbGUiOiJ1c2VyIiwidWlkIjoiNjFmMDY4M2YtZWY0OC00MGE1LWIzMjgtZTU2ZDA2NjM1MTE4IiwidXNlcm5hbWUiOiJyYWoifQ.pks7xjkFdJD649RjCBwQuPF1_QMoryDWixSKx4tPAqXI75ns4sc-yGhMdbEvIZ3AJSvDaqTa47XTC6c8R
+ username: litmus-user
+ endpoint: https://preview.litmuschaos.io
+apiVersion: v1
+current-account: https://preview.litmuschaos.io
+current-user: litmus-user
+kind: Config
+```
+
+* To get an overview of the accounts available within `.litmusconfig`, use the `config get-accounts` command:
+
+```shell
+litmusctl config get-accounts
+```
+
+**Output:**
+
+```
+CURRENT ENDPOINT USERNAME EXPIRESIN
+ https://preview.litmuschaos.io admin 2021-07-22 01:20:27 +0530 IST
+* https://preview.litmuschaos.io raj 2021-07-22 14:33:22 +0530 IST
+```
+
+* To alter the current account use the `use-account` command with the --endpoint and --username flags:
+```shell
+litmusctl config use-account --endpoint="" --username=""
+```
+
+* To create a project, apply the following command with the `--name` flag:
+```shell
+litmusctl create project --name=""
+```
+
+* To view all the projects with the user, use the `get projects` command.
+```shell
+litmusctl get projects
+```
+
+**Output:**
+
+```
+PROJECT ID PROJECT NAME CREATEDAT
+50addd40-8767-448c-a91a-5071543a2d8e Developer Project 2021-07-21 14:38:51 +0530 IST
+7a4a259a-1ae5-4204-ae83-89a8838eaec3 DevOps Project 2021-07-21 14:39:14 +0530 IST
+```
+
+
+* To get an overview of the Chaos Delegates available within a project, issue the following command.
+```shell
+litmusctl get chaos-delegates --project-id=""
+```
+
+**Output:**
+
+```
+CHAOS DELEGATE ID CHAOS DELEGATE NAME STATUS REGISTRATION
+55ecc7f2-2754-43aa-8e12-6903e4c6183a chaos-delegate-1 ACTIVE REGISTERED
+13dsf3d1-5324-54af-4g23-5331g5v2364f chaos-delegate-2 INACTIVE NOT REGISTERED
+```
+
+
+* To disconnect a Chaos Delegate, issue the following command..
+```shell
+litmusctl disconnect chaos-delegate --project-id=""
+```
+
+**Output:**
+
+```
+π Chaos Delegate successfully disconnected.
+```
+
+
+* To list the created Chaos Scenarios within a project, issue the following command.
+```shell
+litmusctl get chaos-scenarios --project-id=""
+```
+
+**Output:**
+
+```
+CHAOS SCENARIO ID CHAOS SCENARIO NAME CHAOS SCENARIO TYPE NEXT SCHEDULE CHAOS DELEGATE ID CHAOS DELEGATE NAME LAST UPDATED BY
+9433b48c-4ab7-4544-8dab-4a7237619e09 custom-chaos-scenario-1627980541 Non Cron Chaos Scenario None f9799723-29f1-454c-b830-ae8ba7ee4c30 Self-Chaos-delegate admin
+
+Showing 1 of 1 Chaos Scenarios
+```
+
+
+* To list all the Chaos Scenario runs within a project, issue the following command.
+```shell
+litmusctl get chaos-scenario-runs --project-id=""
+```
+
+**Output:**
+
+```
+CHAOS SCENARIO RUN ID STATUS RESILIENCY SCORE CHAOS SCENARIO ID CHAOS SCENARIO NAME TARGET CHAOS DELEGATE LAST RUN EXECUTED BY
+8ceb712c-1ed4-40e6-adc4-01f78d281506 Running 0.00 9433b48c-4ab7-4544-8dab-4a7237619e09 custom-chaos-scenario-1627980541 Self-Chaos-Delegate June 1 2022, 10:28:02 pm admin
+
+Showing 1 of 1 Chaos Scenario runs
+```
+
+
+* To describe a particular Chaos Scenario, issue the following command.
+```shell
+litmusctl describe chaos-scenario --project-id=""
+```
+
+**Output:**
+
+```
+apiVersion: argoproj.io/v1alpha1
+kind: Workflow
+metadata:
+ creationTimestamp: null
+ labels:
+ cluster_id: f9799723-29f1-454c-b830-ae8ba7ee4c30
+ subject: custom-chaos-scenario_litmus
+ workflow_id: 9433b48c-4ab7-4544-8dab-4a7237619e09
+ workflows.argoproj.io/controller-instanceid: f9799723-29f1-454c-b830-ae8ba7ee4c30
+ name: custom-chaos-scenario-1627980541
+ namespace: litmus
+spec:
+...
+```
+
+
+* To delete a particular Chaos Scenario, issue the following command.
+```shell
+litmusctl delete chaos-scenario --project-id=""
+```
+
+**Output:**
+
+```
+π Chaos Scenario successfully deleted.
+```
+
+
+
+For more information related to flags, Use `litmusctl --help`.
+
+## Learn More
+
+- [Learn More about Litmusctl](installation.md)
+- [Installing Chaos Delegate in interactive mode](./usage-interactive-mode.md)
+- [Create Chaos Scenarios using Litmusctl](./chaos-workflow-creation.md)
+- [Setup Endpoints and Access ChaosCenter without Ingress](../user-guides/setup-without-ingress.md)
+- [Setup Endpoints and Access ChaosCenter with Ingress](../user-guides/setup-with-ingress.md)
diff --git a/website/versioned_docs/version-2.13.0/troubleshooting.md b/website/versioned_docs/version-2.13.0/troubleshooting.md
new file mode 100644
index 0000000..7aaf4f2
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/troubleshooting.md
@@ -0,0 +1,112 @@
+---
+id: troubleshooting
+title: Troubleshooting
+sidebar_label: Troubleshooting
+---
+
+---
+
+### Subscriber is crashing with the error `dial:websocket: bad handshake`
+
+It is a network issue. It seems your subscriber is unable to access the server.
+While installing chaos delegate, It creates a config called agent-config to store some metadata like server endpoint, accesskey, etc. That server endpoint can be generated in many ways:
+
+- Ingress (If INGRESS=true in server deployment envs)
+- Loadbalancer (it generates lb type of ip based on the server svc type)
+- NodePort (it generates nodeport type of ip based on the server svc type)
+- ClusterIP (it generates clusterip type of ip based on the server svc type)
+
+So, you can edit the agent-config and update the node IP. Once edited, restart the subscriber.
+We suggest using ingress, so that if the endpoint IP changes, then it won't affect your chaos delegate.
+
+### Not able to connect to the Litmus chaos Control Plane hosted on GKE cluster.
+
+In GKE you have to setup a firewall rule to allow TCP traffic on the node port. You can use the following command:
+
+`gcloud compute firewall-rules create test-node-port --allow tcp:port`
+
+If this firewall rule is set up, It may be accessible on nodeIp:port where nodeIp is the external IP address of your node.
+
+### I forgot my Litmus portal password. How can I reset my credentials?
+
+Just run the following command:
+
+`kubectl exec -it mongo-0 -n litmus -- mongo -u admin -p 1234 <<< $'use auth\ndb.usercredentials.update({username:"admin"},{$set:{password:"$2a$15$sNuQl9y/Ok92N19UORcro.3wulEyFi0FfJrnN/akOQe3uxTZAzQ0C"}})\nexit\n'`
+
+Make sure to update the namespace and mongo pod name according to your setup, the rest should remain the same. This command will update the password to `litmus`.
+
+### While uninstalling Litmus portal using helm, some components like subscriber, exporter, event, chaos scenatios, etc are not removed.
+
+These are chaos delegate components, which are launched by the control plane server, so first disconnect the chaos delegatefrom the portal then uninstall the portal using helm.
+
+### Unable to Install Litmus portal using helm. Server pod and mongo pod are in CrashLoopBackOff state. Got this error while checking the logs of mongo container `chown: changing ownership of '/data/db/.snapshot': Read-only file system`.
+
+It seems the directory somehow existed prior to litmus installation and might be used by some other application.
+You have to change the mount path from /consul/config to /consul/myconfig in mongo statefulset then you can successfully deploy the litmus.
+
+### We were setting up Litmus Portal, however, the Self Chaos Delegate status is showing pending. Any idea why is this happening?
+
+The litmusportal-server-service might not be reachable due to inbound rules. You can enable the traffic to it if on GKE/EKS/AKS (by adding the port to inbound rules for traffic).
+You have to check the logs of the subscriber pod and expose the port mentioned for the communication with the server.
+
+### After logging in for the first time to the portal, `/getStarted` page keep loading after I provided the new password
+
+First, try to clear the browser cache and cookies and refresh the page, this might solve your problem.
+If your problem persists, then delete all the cluster role bindings, PV and PVC used by litmus and try to reinstall the litmus again.
+
+### In the logs of Helper pod, I am getting this error ` Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?`
+
+You need to Provide the correct socket path. By default in Portal `CONTAINER_RUNTIME` is set to `docker`,
+If Your container runtime is `containerd` then you have to change the `CONTAINER_RUNTIME` to `containerd` and `SOCKET_PATH` to `/var/run/containerd/containerd.sock`.
+You can find these in tune experiments part of the tune chaos scenario page.
+
+### We have installed ChaosCenter successfully but the Litmus ChaosHub is in error state and manual cloning of a Git repository does not work.
+
+It is most probably a network issue. Currently the ChaosHub feature is not supported in airgapped environment since it requires cloning of a remote git repository. Make sure you have an active internet connection to clone the git repository. If the issue still persists, you can manually add the git repository in the server pod. Here are the steps for the same:
+
+- Step 1: Exec inside the litmus-portal server pod and graphql-server container
+
+```
+kubectl exec -i -t -n litmus --container graphql-server -- sh
+```
+
+Check if the Chaos Experiments directory is available. The directory structure is like
+
+```
+/tmp/version//
+```
+
+Create these directories if not present inside /tmp/version/ :
+
+```
+mkdir
+cd
+mkdir
+```
+
+- Step 2: Clone the Chaos-Charts/Hub repository locally
+
+- Step 3: Use this command to copy the hub directory from your local system to the litmus-portal server pod
+
+```
+kubectl cp /:/ -c graphql-server
+```
+
+Example:
+
+```
+kubectl cp /home/amitkrdas/Chaos-Charts/chaos-charts/ litmus/litmusportal-server-6df9c5895d-57xx7:/tmp/version/686c1da2-da9c-4029-9c6a-528a9455a3b3/"Litmus ChaosHub" -c graphql-server
+```
+
+- Step 4: Once the chaos experiments directory is copied, refresh the ChaosHub page in ChaosCenter.
+
+### Getting invalid token error while running litmusctl commands
+
+Invalid token error occurs when the authorization token is not valid or expired. Authorization token expires in 24 hours. To solve the problem you need to generate a new token and update it in
+.litmusconfig.
+
+The following command can be used to do the same
+
+```
+litmusctl config set-account
+```
diff --git a/website/versioned_docs/version-2.13.0/user-guides/accept-invite.md b/website/versioned_docs/version-2.13.0/user-guides/accept-invite.md
new file mode 100644
index 0000000..76b5028
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/user-guides/accept-invite.md
@@ -0,0 +1,15 @@
+---
+id: accept-invite
+title: Accept an invite
+sidebar_label: Accept invite
+---
+
+---
+
+Once the invitation is received, you can take a look at details including the sender's name, role, and project name, then decide whether to accept or decline the invitation.
+
+
+
+Once accepted, you can switch to the project using the header or the `View Project` option as shown below:
+
+
diff --git a/website/versioned_docs/version-2.13.0/user-guides/account-settings.md b/website/versioned_docs/version-2.13.0/user-guides/account-settings.md
new file mode 100644
index 0000000..35ea6fa
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/user-guides/account-settings.md
@@ -0,0 +1,38 @@
+---
+id: account-settings
+title: Account Settings
+sidebar_label: Account Settings
+---
+
+---
+
+Under the `My Account` tab, you can change your personal details such as the email, full name, and password.
+
+> Note: The username canβt be changed as it is unique.
+
+## Edit Personal Details
+
+Enter your name and your email address in the following text fields and click on the `Save Changes` button.
+
+
+
+Once done successfully, youβll be getting a modal indicating a successful completion of the operation.
+
+
+
+## Change Password
+
+On the same page, you can change your password by providing your current as well as your new password and then click on the `Change Password` button.
+
+
+
+> Note: If you have forgotten your password, please contact your admin to reset your password
+
+On successful completion, youβll be getting a modal indicating that the password has been changed.
+
+
+
+## Learn more
+
+- [Create a new user](create-user.md)
+- [View users and their details](view-user.md)
diff --git a/website/versioned_docs/version-2.13.0/user-guides/air-gapped.md b/website/versioned_docs/version-2.13.0/user-guides/air-gapped.md
new file mode 100644
index 0000000..b7ec55c
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/user-guides/air-gapped.md
@@ -0,0 +1,9 @@
+---
+id: air-gapped
+title: Run Litmus in Air-gapped Environments
+sidebar_label: Air Gapped Environment
+---
+
+---
+
+## Coming soon
diff --git a/website/versioned_docs/version-2.13.0/user-guides/analyze-workflow.md b/website/versioned_docs/version-2.13.0/user-guides/analyze-workflow.md
new file mode 100644
index 0000000..d2b24d6
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/user-guides/analyze-workflow.md
@@ -0,0 +1,59 @@
+---
+id: analyze-workflow
+title: Analyzing a Chaos scenario
+sidebar_label: Analyzing Chaos Scenario
+---
+
+---
+
+Chaos Scenario Analytics allows you to analyze their chaos scenarios (Recurring/ Nonrecurring) & helps them to keep track of the chaos scenario runs of scheduled chaos scenarios and their behaviour.
+
+## Chaos Scenario Details
+
+On the chaos scenario analytics page, in the first container, you will be able to see the details about the selected chaos scenario such as the chaos scenario name, chaos scenario id, chaos delegate details(name, namespace, etc.), and the chaos scenario run details like the last run as well as regularity.
+
+
+
+## Chaos Scenario Statistics
+
+On clicking on **show statistics**, you will be able to see the experiment statistics, average resiliency score and pass/fail ratio for the chaos scenarios/experiments.
+
+
+
+:::note
+
+If the selected chaos scenario is recurring or is re-run multiple times, then the average resiliency score for all the chaos scenario runs is shown. A drop-down has been provided to switch between chaos scenarios & experiments for checking the pass/fail ratio.
+
+:::
+
+
+
+## Chaos Scenario Heatmap
+
+If the selected chaos scenario is recurring or is re-run multiple times, a heat map representing the days of the year showing all the chaos scenario runs for the selected chaos scenario can be observed. On hovering over a point in the heat map, the average resiliency score for that particular day will be shown in the form of a tool-tip.
+
+
+
+## Chaos Scenario Activity
+
+On clicking on a heat map entry, a stacked bar graph representing the pass/fail ratio is shown, on which you can see the chaos scenario runs on that day and hover over the bars to see the resiliency for that particular chaos scenario run on that day.
+
+
+
+:::info
+
+You can check Pass Count, Fail Count of Experiments & Resiliency Score by hovering over the bar for that chaos scenario run.
+
+:::
+
+## Experiments Table
+
+On clicking on a bar, more details about the chaos scenario run represented by that stacked bar are presented in a tabular format. A table having individual experiments details is presented to the user, which helps them to get insights about the experiments.
+
+
+
+## Learn more
+
+- [Compare Chaos Scenarios](comparative-analysis.md)
+- [Manage Application Dashboard](manage-app-dashboard.md)
+- [Configure Datasource](configure-datasource.md)
diff --git a/website/versioned_docs/version-2.13.0/user-guides/change-project-name.md b/website/versioned_docs/version-2.13.0/user-guides/change-project-name.md
new file mode 100644
index 0000000..380727e
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/user-guides/change-project-name.md
@@ -0,0 +1,38 @@
+---
+id: change-project-name
+title: Changing Project Name
+sidebar_label: Change Project Name
+---
+
+---
+
+Owners have the ability to change the name of their project if they wish to do so.
+
+## Before you begin
+
+The concept of `Projects` is discussed [here](../concepts/projects.md) and will help you build a foundational understanding of what projects mean in the ChaosCenter.
+
+## Steps
+
+### 1. Go to `My Project`
+
+Go to the `Team` section of settings and scroll to the `My project` section:
+
+
+
+### 2. Enter edit mode
+
+Click on either the text (demonstrated in this example as `adminβs project`) or on the edit icon next to it to enter the edit mode:
+
+
+
+### 3. Replace name
+
+Once in the editing mode, type out the name you want to replace the current name with, and click away anywhere in the screen. You will notice that the name of the project has been changed in the `My Project` section as well as the header of the portal.
+
+
+
+## Learn more
+
+- [Invite a member to your project](invite-team-member.md)
+- [Remove a member from your project](remove-team-member.md)
diff --git a/website/versioned_docs/version-2.13.0/user-guides/chaosagents-installation.md b/website/versioned_docs/version-2.13.0/user-guides/chaosagents-installation.md
new file mode 100644
index 0000000..3aeb0ba
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/user-guides/chaosagents-installation.md
@@ -0,0 +1,71 @@
+---
+id: chaosagents-installation
+title: Chaos Delegate Installation
+sidebar_label: Chaos Delegate
+---
+
+---
+
+## Prerequisites
+
+- Before connecting a Chaos Delegate to the [ChaosCenter](../getting-started/resources.md#chaoscenter), learn about what is a [Chaos Delegate](../getting-started/resources.md#chaosagents) in Litmus.
+- Make sure [litmusctl](../litmusctl/installation.md) is installed.
+
+## Connecting Chaos Delegate
+
+- Learn to [connect Chaos Delegate with non interactive mode using litmuctl](../litmusctl/usage-non-interactive-mode.md)
+- Learn to [connect Chaos Delegate with interactive mode using litmuctl](../litmusctl/usage-interactive-mode.md)
+
+## Resource Requiremenets for Chaos Delegate plane components
+
+The Resource requests provided here have been estimated using data gathered manually through different methods -
+
+- Using command `kubectl top`
+- Recommendations from Vertical-Pod-Autoscaler
+- Recommendations by a great utility [Goldilocks](https://github.com/FairwindsOps/goldilocks).
+
+These resources are getting monitored continuously and the information below will be updated as the metrics changes.
+
+
+
+
Pod
+
Container
+
CPU(Requested)
+
Memory(Requested)
+
+
+
chaos-operator-ce
+
chaos-operator-ce
+
25m
+
300M
+
+
+
chaos-exporter
+
chaos-exporter
+
25m
+
300M
+
+
+
event-tracker
+
litmus-event-tracker
+
25m
+
300M
+
+
+
subscriber
+
subscriber
+
25m
+
300M
+
+
+
workflow-controller
+
workflow-controller
+
25m
+
300M
+
+
+
+## Learn more
+
+- [Setup Endpoints and Access ChaosCenter without Ingress](setup-without-ingress.md)
+- [Setup Endpoints and Access ChaosCenter with Ingress](setup-with-ingress.md)
diff --git a/website/versioned_docs/version-2.13.0/user-guides/chaoscenter-cluster-scope-installation.md b/website/versioned_docs/version-2.13.0/user-guides/chaoscenter-cluster-scope-installation.md
new file mode 100644
index 0000000..0c3a5f9
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/user-guides/chaoscenter-cluster-scope-installation.md
@@ -0,0 +1,203 @@
+---
+id: chaoscenter-cluster-scope-installation
+title: ChaosCenter Cluster Scope Installation
+sidebar_label: Cluster Scope
+---
+
+---
+
+## 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
+ :::
+
+- [Helm3](https://v3.helm.sh/) or [kubectl](https://kubernetes.io/docs/tasks/tools/#kubectl)
+
+## Installation
+
+Installation of Litmus can be done using either of the below methods
+
+- [Helm3](#install-litmus-using-helm) chart
+- [Kubectl](#install-litmus-using-kubectl) yaml spec file
+
+### Install Litmus using Helm
+
+The helm chart will install all the required service account configuration and ChaosCenter.
+
+The following steps will help you install Litmus ChaosCenter via helm.
+
+#### Step-1: Add the litmus helm repository
+
+```bash
+helm repo add litmuschaos https://litmuschaos.github.io/litmus-helm/
+helm repo list
+```
+
+#### Step-2: Create the namespace on which you want to install Litmus ChaosCenter
+
+- The chaoscenter components can be placed in any namespace, though it is typically placed in "litmus".
+
+```bash
+kubectl create ns litmus
+```
+
+#### Step-3: Install Litmus ChaosCenter
+
+```bash
+helm install chaos litmuschaos/litmus --namespace=litmus
+```
+
+Expected Output
+
+```
+NAME: chaos
+LAST DEPLOYED: Tue Jun 15 19:20:09 2021
+NAMESPACE: litmus
+STATUS: deployed
+REVISION: 1
+TEST SUITE: None
+NOTES:
+Thank you for installing litmus π
+
+Your release is named chaos and its installed to namespace: litmus.
+
+Visit https://docs.litmuschaos.io to find more info.
+```
+
+> **Note:** Litmus uses Kubernetes CRDs to define chaos intent. Helm3 handles CRDs better than Helm2. Before you start running a chaos experiment, verify if Litmus is installed correctly.
+
+### **Install Litmus using kubectl **
+
+#### **Install Litmus ChaosCenter**
+
+Applying the manifest file will install all the required service account configuration and ChaosCenter.
+
+```bash
+kubectl apply -f https://litmuschaos.github.io/litmus/2.13.0/litmus-2.13.0.yaml
+```
+
+> If you are installing Litmus in any other namespace apart from `litmus` namespace, make sure to change the same in the manifest too `https://litmuschaos.github.io/litmus/2.13.0/litmus-2.13.0.yaml`.
+
+## **Verify your installation**
+
+#### **Verify if the frontend, server, and database pods are running**
+
+- Check the pods in the namespace where you installed Litmus:
+
+ ```bash
+ kubectl get pods -n litmus
+ ```
+
+ Expected Output
+
+ ```bash
+ NAME READY STATUS RESTARTS AGE
+ litmusportal-server-6fd57cc89-6w5pn 1/1 Running 0 57s
+ litmusportal-auth-server-7b596fff9-5s6g5 1/1 Running 0 57s
+ mongo-0 1/1 Running 0 57s
+ litmusportal-frontend-55974fcf59-cxxrf 1/1 Running 0 58s
+ ```
+
+- Check the services running in the namespace where you installed Litmus:
+
+ ```bash
+ kubectl get svc -n litmus
+ ```
+
+ Expected Output
+
+ ```bash
+ NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
+ litmusportal-frontend-service NodePort 10.43.79.17 9091:31846/TCP 102s
+ litmusportal-server-service NodePort 10.43.30.54 9002:31245/TCP,8000:32714/TCP 101s
+ litmusportal-auth-server-service NodePort 10.43.81.108 9003:32618/TCP,3030:31899/TCP 101s
+ mongo-service ClusterIP 10.43.227.10 27017/TCP 101s
+ mongo-headless-service ClusterIP None 27017/TCP 101s
+ ```
+
+---
+
+#### **Verify Successful Registration of the Self Chaos Delegate post [Account Configuration](setup-without-ingress)**
+
+Once the project is created, the cluster is automatically registered as a chaos target via installation of [Chaos Delegate](../getting-started/resources.md#chaosagents). This is represented as [Self Chaos Delegate](../getting-started/resources.md#types-of-chaosagents) in [ChaosCenter](../getting-started/resources.md#chaoscenter).
+
+```bash
+kubectl get pods -n litmus
+```
+
+```bash
+NAME READY STATUS RESTARTS AGE
+chaos-exporter-547b59d887-4dm58 1/1 Running 0 5m27s
+chaos-operator-ce-84ddc8f5d7-l8c6d 1/1 Running 0 5m27s
+event-tracker-5bc478cbd7-xlflb 1/1 Running 0 5m28s
+litmusportal-frontend-97c8bf86b-mx89w 1/1 Running 0 15m
+litmusportal-server-6fd57cc89-6w5pn 1/1 Running 0 15m
+litmusportal-auth-server-7b596fff9-5s6g5 1/1 Running 0 15m
+mongo-0 1/1 Running 0 15m
+subscriber-958948965-qbx29 1/1 Running 0 5m30s
+workflow-controller-78fc7b6c6-w82m7 1/1 Running 0 5m32s
+```
+
+## Resource Requirements of Control-plane components
+
+The Resource requests provided here have been estimated using data gathered manually through different methods -
+
+- Using command `kubectl top`
+- Recommendations from Vertical-Pod-Autoscaler
+- Recommendations by a great utility [Goldilocks](https://github.com/FairwindsOps/goldilocks).
+
+These resources are getting monitored continuously and the information below will be updated as the metrics changes.
+
+:::note
+**The metrics given below shows resources consumed when ChaosCenter is used at medium scale.The resources may need to be increased when used at higher scale.**
+:::
+
+
+
+
Pod
+
Container
+
CPU
+
Memory
+
+
+
litmusportal-frontend
+
litmusportal-frontend
+
25m
+
300M
+
+
+
litmusportal-server
+
auth-server
+
25m
+
150M
+
+
+
litmusportal-server
+
graphql-server
+
25m
+
350M
+
+
+
mongodb
+
mongodb
+
25m
+
350M
+
+
+
+## Resources
+
+
+
+## Learn more
+
+- [Install ChaosCenter in Namespace Scope](chaoscenter-namespace-scope-installation.md)
+- [Setup Endpoints and Access ChaosCenter without Ingress](setup-without-ingress.md)
+- [Setup Endpoints and Access ChaosCenter with Ingress](setup-with-ingress.md)
diff --git a/website/versioned_docs/version-2.13.0/user-guides/chaoscenter-namespace-scope-installation.md b/website/versioned_docs/version-2.13.0/user-guides/chaoscenter-namespace-scope-installation.md
new file mode 100644
index 0000000..4938948
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/user-guides/chaoscenter-namespace-scope-installation.md
@@ -0,0 +1,259 @@
+---
+id: chaoscenter-namespace-scope-installation
+title: ChaosCenter Namespace Scope Installation
+sidebar_label: Namespace Scope
+---
+
+---
+
+## 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
+ :::
+
+- [Helm3](https://v3.helm.sh/) or [kubectl](https://kubernetes.io/docs/tasks/tools/#kubectl)
+
+## Installation
+
+Installation of Litmus can be done using either of the below methods
+
+- [Helm3](#install-litmus-using-helm) chart
+- [Kubectl](#install-litmus-using-kubectl) yaml spec file
+
+### **Install Litmus using Helm **
+
+The helm chart will install all the required service account configuration and ChaosCenter.
+
+The following steps will help you install Litmus ChaosCenter via helm.
+
+#### Step-1: Add the litmus helm repository
+
+```bash
+helm repo add litmuschaos https://litmuschaos.github.io/litmus-helm/
+helm repo list
+```
+
+#### Step-2: Create the namespace on which you want to install Litmus ChaosCenter [Required only if namespace isn't there]
+
+- The chaoscenter components can be placed in any namespace, though it is typically placed in "litmus".
+
+```bash
+kubectl create ns litmus
+```
+
+> The ChaosCenter can be placed in any namespace, though it is typically placed in `litmus`. Ignore if you already have the namespace where you want to install Litmus created.
+
+#### Step-3: Install the required Litmus CRDs
+
+The cluster-admin or an equivalent user with the right permissions are required to install the CRDs upfront.
+
+```bash
+kubectl apply -f https://raw.githubusercontent.com/litmuschaos/litmus/master/litmus-portal/manifests/litmus-portal-crds.yml
+```
+
+Expected Output
+
+```bash
+customresourcedefinition.apiextensions.k8s.io/clusterworkflowtemplates.argoproj.io created
+customresourcedefinition.apiextensions.k8s.io/cronworkflows.argoproj.io created
+customresourcedefinition.apiextensions.k8s.io/workflows.argoproj.io created
+customresourcedefinition.apiextensions.k8s.io/workflowtemplates.argoproj.io created
+customresourcedefinition.apiextensions.k8s.io/chaosengines.litmuschaos.io created
+customresourcedefinition.apiextensions.k8s.io/chaosexperiments.litmuschaos.io created
+customresourcedefinition.apiextensions.k8s.io/chaosresults.litmuschaos.io created
+customresourcedefinition.apiextensions.k8s.io/eventtrackerpolicies.eventtracker.litmuschaos.io created
+```
+
+#### Step-4: Install Litmus ChaosCenter
+
+```bash
+helm install chaos litmuschaos/litmus --namespace=litmus --set portalScope=namespace
+```
+
+Expected Output
+
+```bash
+NAME: chaos
+LAST DEPLOYED: Tue Jun 15 19:20:09 2021
+NAMESPACE: litmus
+STATUS: deployed
+REVISION: 1
+TEST SUITE: None
+NOTES:
+Thank you for installing litmus π
+
+Your release is named chaos and its installed to namespace: litmus.
+
+Visit https://docs.litmuschaos.io/ to find more info.
+
+```
+
+> **Note:** Litmus uses Kubernetes CRDs to define chaos intent. Helm3 handles CRDs better than Helm2. Before you start running a chaos experiment, verify if Litmus is installed correctly.
+
+### **Install Litmus using kubectl **
+
+#### **Set the namespace on which you want to install Litmus ChaosCenter**
+
+> Create a namespace `kubectl create ns `
+
+```bash
+kubectl create ns litmus
+```
+
+Expected Output
+
+```bash
+NAME STATUS AGE
+litmus Active 2s
+```
+
+#### **Install the required Litmus CRDs**
+
+The cluster-admin or an equivalent user with the right permissions are required to install the CRDs upfront.
+
+```bash
+kubectl apply -f https://raw.githubusercontent.com/litmuschaos/litmus/master/litmus-portal/manifests/litmus-portal-crds.yml
+```
+
+Expected Output
+
+```bash
+customresourcedefinition.apiextensions.k8s.io/clusterworkflowtemplates.argoproj.io created
+customresourcedefinition.apiextensions.k8s.io/cronworkflows.argoproj.io created
+customresourcedefinition.apiextensions.k8s.io/workflows.argoproj.io created
+customresourcedefinition.apiextensions.k8s.io/workflowtasksets.argoproj.io created
+customresourcedefinition.apiextensions.k8s.io/workflowtemplates.argoproj.io created
+customresourcedefinition.apiextensions.k8s.io/chaosengines.litmuschaos.io created
+customresourcedefinition.apiextensions.k8s.io/chaosexperiments.litmuschaos.io created
+customresourcedefinition.apiextensions.k8s.io/chaosresults.litmuschaos.io created
+customresourcedefinition.apiextensions.k8s.io/eventtrackerpolicies.eventtracker.litmuschaos.io created
+```
+
+#### **Install Litmus ChaosCenter**
+
+Applying the manifest file will install all the required service account configuration and ChaosCenter.
+
+```bash
+kubectl apply -f https://raw.githubusercontent.com/litmuschaos/litmus/master/mkdocs/docs/2.13.0/litmus-namespaced-2.13.0.yaml -n
+```
+
+> You need to provide the Namespace in place of `Your Namespace`, that you have created eariler for the litmuschaos Installation
+
+Expected Output
+
+```bash
+role.rbac.authorization.k8s.io/argo-role-for-litmusportal-server created
+rolebinding.rbac.authorization.k8s.io/argo-rb-for-litmusportal-server created
+role.rbac.authorization.k8s.io/litmus-namespace-scope-for-litmusportal-server created
+rolebinding.rbac.authorization.k8s.io/litmus-namespace-scope-rb-for-litmusportal-server created
+role.rbac.authorization.k8s.io/subscriber-role-for-litmusportal-server created
+rolebinding.rbac.authorization.k8s.io/subscriber-rb-for-litmusportal-server created
+role.rbac.authorization.k8s.io/litmus-admin-role-for-litmusportal-server created
+rolebinding.rbac.authorization.k8s.io/litmus-admin-rb-for-litmusportal-server created
+role.rbac.authorization.k8s.io/chaos-role-for-litmusportal-server created
+rolebinding.rbac.authorization.k8s.io/chaos-rb-for-litmusportal-server created
+role.rbac.authorization.k8s.io/event-tracker-role-for-litmusportal-server created
+rolebinding.rbac.authorization.k8s.io/event-tracker-rb-for-litmusportal-server created
+role.rbac.authorization.k8s.io/litmus-server-role created
+rolebinding.rbac.authorization.k8s.io/litmus-server-rb created
+serviceaccount/litmus-server-account created
+secret/litmus-portal-admin-secret created
+configmap/litmus-portal-admin-config created
+configmap/litmusportal-frontend-nginx-configuration created
+deployment.apps/litmusportal-frontend created
+service/litmusportal-frontend-service created
+deployment.apps/litmusportal-server created
+service/litmusportal-server-service created
+deployment.apps/litmusportal-auth-server created
+service/litmusportal-auth-server-service created
+statefulset.apps/mongo created
+service/mongo-service created
+service/mongo-headless-service created
+```
+
+## **Verify your installation**
+
+---
+
+#### **Verify if the frontend, server, and database pods are running**
+
+- Check the pods in the namespace where you installed Litmus:
+
+ ```bash
+ kubectl get pods -n litmus
+ ```
+
+ Expected Output
+
+ ```bash
+ NAME READY STATUS RESTARTS AGE
+ litmusportal-server-6fd57cc89-6w5pn 1/1 Running 0 57s
+ litmusportal-auth-server-7b596fff9-5s6g5 1/1 Running 0 57s
+ mongo-0 1/1 Running 0 57s
+ litmusportal-frontend-55974fcf59-cxxrf 1/1 Running 0 58s
+ ```
+
+- Check the services running in the namespace where you installed Litmus:
+
+ ```bash
+ kubectl get svc -n litmus
+ ```
+
+ Expected Output
+
+ ```bash
+ NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
+ litmusportal-frontend-service NodePort 10.43.79.17 9091:31846/TCP 102s
+ litmusportal-server-service NodePort 10.43.30.54 9002:31245/TCP,8000:32714/TCP 101s
+ litmusportal-auth-server-service NodePort 10.43.81.108 9003:32618/TCP,3030:31899/TCP 101s
+ mongo-service ClusterIP 10.43.227.10 27017/TCP 101s
+ mongo-headless-service ClusterIP None 27017/TCP 101s
+ ```
+
+> Note: With the namespace mode of the control panel, we need to set the endpoint of the chaos center ui according to the use case for external Chaos Delegates. By default, it is `http://litmusportal-frontend-service:9091`
+
+To alter, Apply:
+
+```bash
+kubectl set env deployment/litmusportal-server -n litmus --containers="graphql-server" CHAOS_CENTER_UI_ENDPOINT="http://172.132.44.44:3231"
+```
+
+---
+
+#### **Verify Successful Registration of the Self Chaos Delegate post [Account Configuration](setup-without-ingress)**
+
+Once the project is created, the cluster is automatically registered as a chaos target via installation of [Chaos Delegate](../getting-started/resources.md#chaosagents). This is represented as [Self Chaos Delegate](../getting-started/resources.md#types-of-chaosagents) in [ChaosCenter](../getting-started/resources.md#chaosagents).
+
+```bash
+kubectl get pods -n litmus
+```
+
+```bash
+NAME READY STATUS RESTARTS AGE
+chaos-exporter-547b59d887-4dm58 1/1 Running 0 5m27s
+chaos-operator-ce-84ddc8f5d7-l8c6d 1/1 Running 0 5m27s
+event-tracker-5bc478cbd7-xlflb 1/1 Running 0 5m28s
+litmusportal-frontend-97c8bf86b-mx89w 1/1 Running 0 15m
+litmusportal-server-6fd57cc89-6w5pn 1/1 Running 0 15m
+litmusportal-auth-server-7b596fff9-5s6g5 1/1 Running 0 15m
+mongo-0 1/1 Running 0 15m
+subscriber-958948965-qbx29 1/1 Running 0 5m30s
+workflow-controller-78fc7b6c6-w82m7 1/1 Running 0 5m32s
+```
+
+## Resources
+
+
+
+## Learn more
+
+- [Install ChaosCenter in Cluster Scope](chaoscenter-cluster-scope-installation.md)
+- [Setup Endpoints and Access ChaosCenter without Ingress](setup-without-ingress.md)
+- [Setup Endpoints and Access ChaosCenter with Ingress](setup-with-ingress.md)
diff --git a/website/versioned_docs/version-2.13.0/user-guides/chaoscenter-oauth-dex-installation.md b/website/versioned_docs/version-2.13.0/user-guides/chaoscenter-oauth-dex-installation.md
new file mode 100644
index 0000000..f8b557d
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/user-guides/chaoscenter-oauth-dex-installation.md
@@ -0,0 +1,167 @@
+---
+id: chaoscenter-oauth-dex-installation
+title: ChaosCenter with OAuth2 Login Support
+sidebar_label: OAuth2 Support using Dex
+---
+
+---
+
+# 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
+ :::
+
+- [kubectl](https://kubernetes.io/docs/tasks/tools/#kubectl)
+
+- [Deployed ChaosCenter](../getting-started/installation.md)
+
+- Atleast one of the following
+ - Google Oauth credentials
+ - GitHub Oauth credentials
+
+## Deploy Dex OIDC provider
+
+In order to enable OAuth2 and to be able to login via Google and GitHub, litmus uses [Dex OIDC](https://dexidp.io/)
+
+Make sure you have your Google and GitHub Client credentials ready, if you do not have them, you can generate one yourself
+
+- [Guide to generating Google Oauth Client Credentials](https://support.google.com/cloud/answer/6158849?hl=en#zippy=)
+- [Guide to generating GitHub OAuth Client Credentials](https://docs.github.com/en/developers/apps/building-oauth-apps/creating-an-oauth-app)
+
+### Configuring Dex OIDC provider
+
+```bash
+curl https://raw.githubusercontent.com/litmuschaos/litmus/master/litmus-portal/dex-server/dex-deployment.yaml --output dex-deployment.yaml
+```
+
+1. Open the file with your favorite text-editor
+2. You will find the following `config-map` with some data, replace your data as the comments suggests
+ ```yaml
+ issuer: http://:32000 # Replace your NODE_IP here
+ storage:
+ type: kubernetes
+ config:
+ inCluster: true
+ web:
+ http: 0.0.0.0:5556
+ staticClients:
+ - id: LitmusPortalAuthBackend
+ redirectURIs:
+ - '/auth/dex/callback'
+ - 'http://localhost:8080/auth/dex/callback' # Included for local testing purposes
+ - 'https:///auth/dex/calllback' #TODO: Replace with you frontend URL
+ name: 'LitmusPortalAuthBackend'
+ secret: ZXhhbXBsZS1hcHAtc2VjcmV0
+ oauth2:
+ skipApprovalScreen: true
+ connectors:
+ - type: google
+ id: google
+ name: Google
+ config:
+ clientID: # Add your Google Client ID here
+ clientSecret: # Add your Google Client Secret here
+ redirectURI: http://:32000 # Replace your NODE_IP here
+ - type: github
+ id: github
+ name: GitHub
+ config:
+ clientID: # Add your GitHub Client ID here
+ clientSecret: # Add your GitHub Client Secret here
+ redirectURI: http://:32000/callback # Replace your NODE_IP here
+ ```
+
+**Note: The Dex OIDC provider runs at `NODE_IP:32000` by default**
+
+After the configuration, deploy the Dex deployment using the following command:
+
+```bash
+kubectl apply -f dex-deployment.yaml
+```
+
+You should now see the dex-server deployed in the litmus namespace!
+
+```bash
+kubectl get pods -n litmus
+```
+
+Expected Output
+
+```bash
+NAME READY STATUS RESTARTS AGE
+litmusportal-dex-server-7f7658b57-lbbxc 1/1 Running 0 107s
+litmusportal-frontend-74d456746f-56v9x 1/1 Running 0 5m57s
+litmusportal-server-9c4d85f57-5r6km 2/2 Running 0 5m57s
+mongo-0 1/1 Running 0 5m57s
+```
+
+### Configuring `chaos-litmus-auth-server` to enable Dex features
+
+To set up Dex, we would require to modify our litmusportal-server a bit in order to communicate with Dex. This will be achieved by adding some environment variables
+
+- `OIDC_ISSUER`: The place where the Dex OIDC is hosted, i.e `NODE_IP:32000` or `https://dex.yourdomain.com`
+- `DEX_ENABLED`: This variable enables dex features in the litmusportal-server
+- `DEX_OAUTH_CALLBACK_URL`: This is the url that will be called back after user completes thier OAuth, this will be the litmusportal-frontend service
+- `DEX_OAUTH_CLIENT_ID`: This parameter is defined in the `dex-deployment.yaml` file the defaults being `LitmusPortalAuthBackend`
+- `DEX_OAUTH_CLIENT_SECRET`: This parameter is defined in the `dex-deployment.yaml` file the defaults being `ZXhhbXBsZS1hcHAtc2VjcmV0`
+
+Set your variables using
+
+```bash
+kubectl set env deployment/chaos-litmus-auth-server -n litmus --containers="auth-server" DEX_ENABLED=true OIDC_ISSUER=:32000 DEX_OAUTH_CALLBACK_URL=https:///auth/dex/callback DEX_OAUTH_CLIENT_ID=LitmusPortalAuthBackend DEX_OAUTH_CLIENT_SECRET=ZXhhbXBsZS1hcHAtc2VjcmV0
+```
+
+Your chaos-litmus-auth-server pod(s) will be restarted and Dex features will be enabled!
+
+### Verifying if OAuth2 is enabled
+
+Run the following command to check the env variables of the `auth-server`
+
+```bash
+kubectl describe deployment litmusportal-server -n litmus auth-server
+```
+
+Under `auth-server`, verify if the `DEX_ENABLED` variables are set
+
+Expected Output
+
+```bash
+ auth-server:
+ Image: litmuschaos/litmusportal-auth-server:ci
+ Ports: 3000/TCP, 3030/TCP
+ Host Ports: 0/TCP, 0/TCP
+ Environment Variables from:
+ litmus-portal-admin-config ConfigMap Optional: false
+ litmus-portal-admin-secret Secret Optional: false
+ Environment:
+ STRICT_PASSWORD_POLICY: false
+ ADMIN_USERNAME: admin
+ ADMIN_PASSWORD: litmus
+ LITMUS_SVC_ENDPOINT: 127.0.0.1
+ OIDC_ISSUER: [REDACTED]
+ DEX_ENABLED: true
+ DEX_OAUTH_CALLBACK_URL: [REDACTED]
+ Mounts:
+```
+
+Go to http://litmusportal-frontend-service/auth/dex/login, you should be prompted with Google or GitHub login
+
+
+
+## Resources
+
+- [Dex OIDC Provider configurations](https://dexidp.io/docs/)
+
+## Learn more
+
+- [Install ChaosCenter in Namespace Scope](../user-guides/chaoscenter-namespace-scope-installation.md)
+- [Connect External Chaos Delegates to ChaosCenter](../user-guides/chaosagents-installation.md)
+- [Setup Endpoints and Access ChaosCenter without Ingress](../user-guides/setup-without-ingress.md)
+- [Setup Endpoints and Access ChaosCenter with Ingress](../user-guides/setup-with-ingress.md)
diff --git a/website/versioned_docs/version-2.13.0/user-guides/comparative-analysis.md b/website/versioned_docs/version-2.13.0/user-guides/comparative-analysis.md
new file mode 100644
index 0000000..79c383d
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/user-guides/comparative-analysis.md
@@ -0,0 +1,73 @@
+---
+id: comparative-analysis
+title: Comparative Analysis of Chaos Scenarios
+sidebar_label: Compare Scenarios
+---
+
+---
+
+Chaos Scenario Dashboard allows you to manage your chaos scenario runs, schedules & statistics.
+
+## Long-term Statistics
+
+Long-term Statistics provides details about chaos scenario runs & schedules over time.
+
+In first tab, you can compare number of chaos scenario runs according to selected granuality i.e. Daily/Monthly/Hourly. Granuality can be changed using drop-down in top right corner.
+
+
+
+
+Similarily, In other tab, you can also compare schedules according to selected granuality.
+
+
+
+
+:::info
+
+You can hover over the respective graphs to get the total chaos scenario runs & total schedules respectively.
+
+:::
+
+## Total Chaos Scenario Statistics
+
+Total Chaos Scenario Statistics helps you to see how many of their scheduled have been passing/ failing & running. This helps you to see average performance of all the chaos scenario runs.
+
+
+
+## Comparing Multiple Scenarios
+
+List of chaos scenarios provided on the page helps you to keep track of their scheduled chaos scenarios along with associated details like chaos scenario name, chaos delegate, starting time,etc & allows to compare the chaos scenarios by selecting them from the table.
+
+
+
+For comparing the chaos scenarios, you can select the scenarios from the table & click on _**Compare Chaos Scenario**_ button.
+
+
+
+Once, user clicks on _**Compare Chaos Scenario**_ button, they will be presented with a graph, which shows comparison of selected chaos scenarios with respect to resilience score.
+
+
+
+You can change the granuality by clicking on drop-down in top right corner. We can choose between Hourly/ Daily/ Monthly.
+
+
+
+:::note
+
+By hovering over the dots on comparison graph, you can see the resiliency score of compared chaos scenarios & also average chaos scenarios.
+
+:::
+
+
+
+The Comparison report can be downloaded in PDF form using the _**export button**_ given in header of table.
+
+
+
+> **Sample chaos scenario comparison report can be downloaded from [here](../assets/chaos-center-analytics.pdf)**
+
+## Learn more
+
+- [Configure Datasource](configure-datasource.md)
+- [See Chaos Scenario Analytics](analyze-workflow.md)
+- [Manage Application Dashboard](manage-app-dashboard.md)
diff --git a/website/versioned_docs/version-2.13.0/user-guides/configure-datasource.md b/website/versioned_docs/version-2.13.0/user-guides/configure-datasource.md
new file mode 100644
index 0000000..68539ca
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/user-guides/configure-datasource.md
@@ -0,0 +1,93 @@
+---
+id: configure-datasource
+title: Configuring a Datasource
+sidebar_label: Configure Datasource
+---
+
+---
+
+Litmus 2.0 provides in-house monitoring support which can be leveraged by connecting a data source to the chaos center, configured to scrape chaos event metics and application or infrastructure metics.
+
+### Before you begin
+
+To configure a data source for a chaos center project, you must first setup the data source. To learn more about data source setup [click here](setup-datasource.md)
+
+### Connecting a data source
+
+- Click on the `Observability` section from the sidebar then switch to the `Data Source` tab. Click the `Add data source` button to open the data source connection form.
+
+The _first page_ of the form requires the user to provide the general details, It also has a link to documentation around setting up a Prometheus data source (Litmus center supports Prometheus 2.1 or later) to collect chaos events and metrics along with generic node-exporter and kube-state-metrics. Form fields on page 1 for data source connection:
+
+- **Data source name** - alias.
+- **Data source type** - defaults to Prometheus in Litmus 2.0.
+- **Data source endpoint URL** - IP OR Host along with port number. The user can also use the Kubernetes DNS provided and kubelet configured fully qualified domain name (FQDN) with port for prometheus server service, prefixed with `http://` to connect a data source hosted on the control plane cluster for a secure internal connection on K8s.
+ (Ex. - http://prometheus-k8s.monitoring.svc.cluster.local:9090)
+- **Access type** - defaults to Server.
+
+
+
+Data source connection form page - 1
+
+
+On clicking the next button, the _second page_ of the form appears which requires the user to provide more details:
+
+- **Authentication option** - defaults to `No auth` for Litmus 2.0.
+- **Scrape interval** - scrape interval in seconds for the TSDB, The scrape interval is used to control the lower limit of minStep for queries multiplying by denominator of query resolution for a dashboard consuming the data source; the same might be used for limiting the refresh rate for dashboard views with relative time range in later versions of the Litmus center.
+- **Query timeout** - query timeout in seconds for the TSDB, The query timeout is used for all the queries associated with all the dashboards connected to the given data source although the default request timeout for the health check of the data source while connecting, updating or listing it is 5 seconds.
+- **HTTP method** - defaults to `POST` as Litmus uses the Prometheus client APIs to query the data source using POST requests which support bigger queries.
+
+
+
+Data source connection form page - 2
+
+
+After filling up all the details, the user can connect the data source to the project in the Litmus center by clicking the `Save changes` button.
+
+### Data source table, re-configure, deletion
+
+- Click on the `Observability` section from the sidebar then switch to the `Data Source` tab. This tab contains a data source table which lists all the data sources connected to the Litmus center associated with the currently active project. This table has different fields like, `Status` which is essentially health check status with a timeout of 5 seconds for each data source, `Name`, `Type` which defaults to Prometheus for Litmus 2.0, `Last configured` and `Link` to the data source. The last column has a menu with options to `Configure` OR `Delete` the data source.
+
+
+
+Data sources tab
+
+
+- Configuring the data source allows the user to update data source details entered while connecting it to the Litmus center. It takes the user to the connection form with the details pre-filled as per previous configuration. The update works only if the data source endpoint is healthy and active.
+
+
+
+Data source configuration screen
+
+
+- Deletion allows the user to disconnect the data source from the Litmus centerβs project. If any dashboard is consuming the data source then the user is given an option to `Force delete` the data source which also deletes all the dashboards consuming it.
+
+
+
+Data source deletion confirmation
+
+
+
+
+Data source force delete
+
+
+- The table also allows searching for data source by itβs `Name`, filtering entries based on `Status` and `Last configured` date and time.
+
+### Related features
+
+Number of connected data sources are also listed on `Overview` tab of `Observability section` and when no data source connected then user is prompted to add a data source while browsing the `Application monitoring` tab, if an existing inactive data source is found, option to re-configure it is also made available to the user.
+
+### Uses of data source in application monitoring
+
+- [Data source linking during creation and update of application monitoring dashboards](manage-app-dashboard.md)
+- [Tuning queries for dashboards uses data source details associated with the linked data source](editing-queries-app-dashboard.md)
+- [Application monitoring dashboard uses the data source details to perform a health check before pulling application metrics, chaos events and verdict from it to be observed by the user to analyse chaos impact on services or resources](view-chaos-impact.md)
+
+### Resources
+
+
+
+### Learn more
+
+- [Observability Setup](observability-set-up.md)
+- [Manage Application Dashboards](manage-app-dashboard.md)
diff --git a/website/versioned_docs/version-2.13.0/user-guides/construct-workflow.md b/website/versioned_docs/version-2.13.0/user-guides/construct-workflow.md
new file mode 100644
index 0000000..9538720
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/user-guides/construct-workflow.md
@@ -0,0 +1,275 @@
+---
+id: construct-workflow
+title: Construct Chaos Scenario YAML without ChaosCenter
+sidebar_label: Construct Chaos Scenario YAML
+---
+
+---
+
+**Chaos Scenario** is a set of different operations coupled together to achieve desired chaos imapact on a Kubernetes Cluster.
+A basic chaos scenario consists of these steps:
+
+1. Install ChaosExperiment
+2. Install ChaosEngine
+3. Revert Chaos
+
+## Before we begin
+
+To construct a Chaos Scenario without ChaosCenter, make sure you are aware of [Chaos Scenario](../concepts/chaos-workflow.md), [ChaosEngine CR](../concepts/chaos-engine.md) and the different steps present in it.
+
+## Steps to Construct a Chaos Scenario
+
+LitmusChaos leverages the popular chaos scenario and GitOps tool **Argo** to achieve this goal. Argo enables the orchestration of different chaos scenarios together in the form of chaos scenario which is extremly simple and efficient to use.
+
+The structure of a chaos scenario is similar to that of a Kubernetes Object. It consists of the mandatory fields like `apiVersion`, `kind`, `metadata`, `spec`.
+
+Few additional terms in an Argo chaos scenarios are:
+
+1. **Template** : It consists of different steps with their specific operations.
+
+```yaml
+ templates:
+ - name: custom-chaos
+ steps:
+ - - name: install-chaos-experiments
+ template: install-chaos-experiments
+ - - name: pod-delete
+ template: pod-delete
+ - - name: revert-chaos
+ template: revert-chaos
+```
+
+2. **Steps** : It is a single step inside a chaos scenario which runs a container based on the input parameters.
+ These can also be sequenced parallely.
+
+```yaml
+steps:
+ - - name: install-chaos-experiments
+ template: install-chaos-experiments
+ - - name: pod-delete
+ template: pod-delete
+ - name: pod-cpu-hog
+ template: pod-cpu-hog
+ - - name: revert-chaos
+ template: revert-chaos
+```
+
+3. **Entrypoint** : The first step that executes in a chaos scenario is called its entrypoint.
+
+```yaml
+entrypoint: custom-chaos
+```
+
+Here, the template with the name `custom-chaos` will be executed first.
+
+4. **Artifacts** : Artifacts are defined as the files saved by the containers in each step.
+
+```yaml
+- name: install-chaos-experiments
+ inputs:
+ artifacts:
+ - name: pod-delete
+ path: /tmp/pod-delete.yaml
+ raw:
+ data: >
+ apiVersion: litmuschaos.io/v1alpha1
+
+ description:
+ message: |...
+```
+
+Once the chaos scenario is constructed, it should look like this:
+
+```yaml
+apiVersion: argoproj.io/v1alpha1
+kind: Workflow
+metadata:
+ name: pod-delete-experiment
+ namespace: litmus
+spec:
+ arguments:
+ parameters:
+ - name: adminModeNamespace
+ value: litmus
+ entrypoint: custom-chaos
+ securityContext:
+ runAsNonRoot: true
+ runAsUser: 1000
+ serviceAccountName: argo-chaos
+ templates:
+ - name: custom-chaos
+ steps:
+ - - name: install-chaos-experiments
+ template: install-chaos-experiments
+ - - name: pod-delete
+ template: pod-delete
+ - - name: revert-chaos
+ template: revert-chaos
+ - name: install-chaos-experiments
+ inputs:
+ artifacts:
+ - name: pod-delete
+ path: /tmp/pod-delete.yaml
+ raw:
+ data: >
+ apiVersion: litmuschaos.io/v1alpha1
+
+ description:
+ message: |
+ Deletes a pod belonging to a deployment/statefulset/daemonset
+ kind: ChaosExperiment
+
+ metadata:
+ name: pod-delete
+ labels:
+ name: pod-delete
+ app.kubernetes.io/part-of: litmus
+ app.kubernetes.io/component: chaosexperiment
+ app.kubernetes.io/version: 1.13.8
+ spec:
+ definition:
+ scope: Namespaced
+ permissions:
+ - apiGroups:
+ - ""
+ - apps
+ - apps.openshift.io
+ - argoproj.io
+ - batch
+ - litmuschaos.io
+ resources:
+ - deployments
+ - jobs
+ - pods
+ - pods/log
+ - replicationcontrollers
+ - deployments
+ - statefulsets
+ - daemonsets
+ - replicasets
+ - deploymentconfigs
+ - rollouts
+ - pods/exec
+ - events
+ - chaosengines
+ - chaosexperiments
+ - chaosresults
+ verbs:
+ - create
+ - list
+ - get
+ - patch
+ - update
+ - delete
+ - deletecollection
+ image: litmuschaos/go-runner:1.13.8
+ imagePullPolicy: Always
+ args:
+ - -c
+ - ./experiments -name pod-delete
+ command:
+ - /bin/bash
+ env:
+ - name: TOTAL_CHAOS_DURATION
+ value: "15"
+ - name: RAMP_TIME
+ value: ""
+ - name: FORCE
+ value: "true"
+ - name: CHAOS_INTERVAL
+ value: "5"
+ - name: PODS_AFFECTED_PERC
+ value: ""
+ - name: LIB
+ value: litmus
+ - name: TARGET_PODS
+ value: ""
+ - name: SEQUENCE
+ value: parallel
+ labels:
+ name: pod-delete
+ app.kubernetes.io/part-of: litmus
+ app.kubernetes.io/component: experiment-job
+ app.kubernetes.io/version: 1.13.8
+ container:
+ args:
+ - kubectl apply -f /tmp/pod-delete.yaml -n
+ {{workflow.parameters.adminModeNamespace}} | sleep 30
+ command:
+ - sh
+ - -c
+ image: litmuschaos/k8s:latest
+ - name: pod-delete
+ inputs:
+ artifacts:
+ - name: pod-delete
+ path: /tmp/chaosengine-pod-delete.yaml
+ raw:
+ data: |
+ apiVersion: litmuschaos.io/v1alpha1
+ kind: ChaosEngine
+ metadata:
+ namespace: "{{workflow.parameters.adminModeNamespace}}"
+ generateName: pod-delete
+ labels:
+ instance_id: 86a4f130-d99b-4e91-b34b-8f9eee22cb63
+ spec:
+ appinfo:
+ appns: default
+ applabel: app=nginx
+ appkind: deployment
+ jobCleanUpPolicy: retain
+ engineState: active
+ chaosServiceAccount: litmus-admin
+ experiments:
+ - name: pod-delete
+ spec:
+ components:
+ env:
+ - name: TOTAL_CHAOS_DURATION
+ value: "30"
+ - name: CHAOS_INTERVAL
+ value: "10"
+ - name: FORCE
+ value: "false"
+ - name: PODS_AFFECTED_PERC
+ value: ""
+ container:
+ args:
+ - -file=/tmp/chaosengine-pod-delete.yaml
+ - -saveName=/tmp/engine-name
+ image: litmuschaos/litmus-checker:latest
+ - name: revert-chaos
+ container:
+ image: litmuschaos/k8s:latest
+ command:
+ - sh
+ - -c
+ args:
+ - "kubectl delete chaosengine -l 'instance_id in
+ (86a4f130-d99b-4e91-b34b-8f9eee22cb63, )' -n
+ {{workflow.parameters.adminModeNamespace}} "
+```
+
+## Install Experiment
+
+1. ### ChaosExperiment CR:
+
+ The `install-experiment` step consists of ChaosExperiment CR in its artifact.
+ ChaosExperiment CR is the heart of LitmusChaos and contains the low-level execution information. They serve as off-the-shelf templates that one needs to "pull" (install on the cluster) before including them as part of chaos run against any target applications (the binding being defined in the ChaosEngine). The experiments are installed on the cluster as Kubernetes custom resources and are designed to hold granular details of the experiment such as image, library, necessary permissions, chaos parameters (set to their default values). Most of the ChaosExperiment parameters are essentially tunables that can be overridden from the ChaosEngine resource.
+
+2. ### ChaosEngine CR:
+ The ChaosEngine is the main user-facing chaos custom resource with a namespace scope and is designed to hold information around how the chaos experiments are executed. It connects an application instance with one or more chaos experiments while allowing the users to specify run level details (override experiment defaults, provide new environment variables and volumes, options to delete or retain experiment pods, etc.,). This CR is also updated/patched with the status of the chaos experiments, making it the single source of truth with respect to the chaos.
+
+## Resources
+
+- The ChaosExperiment CR and ChaosEngine CR of different experiments are available at **[ChaosHub](http://hub.litmuschaos.io/)**.
+
+
+
+
+
+## Learn More
+
+- [What are the different Probes](../concepts/probes.md)
+- [What is ChaosResult](../concepts/chaos-result.md)
diff --git a/website/versioned_docs/version-2.13.0/user-guides/create-user.md b/website/versioned_docs/version-2.13.0/user-guides/create-user.md
new file mode 100644
index 0000000..6613560
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/user-guides/create-user.md
@@ -0,0 +1,35 @@
+---
+id: create-user
+title: Create a User
+sidebar_label: Create User
+---
+
+---
+
+This feature enables the admin to create a new user by assigning a unique username and password for the user. In addition to this, the admin can also provide the name and email address of the new user which is optional.
+
+## 1. Create a new user
+
+Click the `Create new user` button as observed below:
+
+
+
+## 2. Add the details of the new user
+
+Add all the details of the user to be created and hit the `Create` button.
+
+
+
+## 3. Confirmation of creation
+
+The user is created and you will receive a confirmation modal.
+
+
+
+You will now be able to view the new user in the table in the user management tab.
+
+## Learn more
+
+- [View users](view-user.md)
+- [Reset the password of a user](reset-password.md)
+- [Deactivate a user](deactivate-user.md)
diff --git a/website/versioned_docs/version-2.13.0/user-guides/deactivate-user.md b/website/versioned_docs/version-2.13.0/user-guides/deactivate-user.md
new file mode 100644
index 0000000..78baf21
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/user-guides/deactivate-user.md
@@ -0,0 +1,31 @@
+---
+id: deactivate-user
+title: Deactivate a User
+sidebar_label: Deactivate User
+---
+
+---
+
+The Account of a created user can be deactivated if required. Once the user is deactivated, the user wonβt be able to log in or access any of the APIs. Along with this, the project in which the user was the owner of will also get deactivated and everyone who is a member of the project will lose access to that project. Admin can also reactivate the account of a deactivated user. Once the user is reactivated, complete data will get restored.
+
+## 1. Locate and deactivate the user
+
+In the user management tab, locate the user account that you'd like to deactivate and click on the horizontal options icon.
+
+
+
+## 2. Confirm the user is deactivated
+
+Once deactivated, the indicator next to the user's username in the usermanagement table will turn gray.
+
+
+
+## 3. Re-activate a user (Optional step)
+
+Similarly, the admin can re-activate the user from the same drop-down menu as shown:
+
+
+
+## Learn more
+
+- [View users](view-user.md)
diff --git a/website/versioned_docs/version-2.13.0/user-guides/delete-workflow.md b/website/versioned_docs/version-2.13.0/user-guides/delete-workflow.md
new file mode 100644
index 0000000..66cb2d5
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/user-guides/delete-workflow.md
@@ -0,0 +1,43 @@
+---
+id: delete-workflow
+title: Delete a Chaos Scenario
+sidebar_label: Delete Chaos Scenario
+---
+
+---
+
+If required, it is possible to delete a chaos scenario schedule that you no longer wish to run against your application.
+
+:::note
+This also means that all the runs corresponding to that chaos scenario will also be deleted.
+:::
+
+## Before you begin
+
+You can learn about the concept of chaos scenarios [here](../concepts/chaos-workflow.md) and how to schedule your first chaos scenario [here](schedule-workflow.md).
+
+## 1. Go to the chaos scenarios sections
+
+In the `Chaos Scenario` page, go to the `Schedules` tab and click on the options menu for the specific schedule you wish to delete:
+
+
+
+## 2. Click on the `Delete chaos scenario` option
+
+After opening the options menu and clicking on the `Delete chaos scenario` option, you'll see a prompt in order to confirm your action. Please ensure that you want to delete the selected chaos scenario and click the `Delete` button:
+
+
+
+## 3. The Chaos Scenario has been deleted
+
+You will observe that the chaos scenario no longer appears in the list of schedules and has been removed.
+
+
+
+As stated above, we observe that the runs have been removed as well.
+
+
+
+## Learn more
+
+- [schedule a chaos scenario](schedule-workflow.md)
diff --git a/website/versioned_docs/version-2.13.0/user-guides/download-workflow-manifest.md b/website/versioned_docs/version-2.13.0/user-guides/download-workflow-manifest.md
new file mode 100644
index 0000000..ce53bd2
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/user-guides/download-workflow-manifest.md
@@ -0,0 +1,31 @@
+---
+id: download-workflow-manifest
+title: Download Chaos Scenario Manifest
+sidebar_label: Download Chaos Scenario Manifest
+---
+
+---
+
+You can save a schedule configurations manifest as a `YAML`. This section goes over the steps to achieve the same.
+
+## Before you begin
+
+You can learn how to schedule your first chaos scenario [here](schedule-workflow.md).
+
+## 1. Go to the chaos scenarios sections
+
+In the `Chaos Scenario` page, go to the `Schedules` tab and click on the options menu for the specific schedule you wish to download the manifest for:
+
+
+
+## 2. Click on the `Download Manifest` option
+
+After opening the options menu, click on the `Download Manifest` option. Having downloaded a particular schedule manifest, you can see the browser downloads list to see the status of the manifest download operation and then see the `YAML` file in your system's default download directory:
+
+
+
+## Learn more
+
+- [Schedule a chaos scenario](schedule-workflow.md)
+- [Re-run a chaos scenario](re-run-workflow.md)
+- [Delete a chaos scenario](delete-workflow.md)
diff --git a/website/versioned_docs/version-2.13.0/user-guides/edit-invite.md b/website/versioned_docs/version-2.13.0/user-guides/edit-invite.md
new file mode 100644
index 0000000..3fe415a
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/user-guides/edit-invite.md
@@ -0,0 +1,17 @@
+---
+id: edit-invite
+title: Edit or Cancel an invite
+sidebar_label: Edit/Cancel invite
+---
+
+---
+
+If you had a change of mind and you wanted to change the role of an invitation that has been already sent, we got you!
+
+Just go to the invited tab, change the role, and hit the `Resend` button. You can also cancel the invitation by just clicking on the `bin` icon.
+
+
+
+## Learn more
+
+- [Accept an invitation](accept-invite.md)
diff --git a/website/versioned_docs/version-2.13.0/user-guides/edit-schedule.md b/website/versioned_docs/version-2.13.0/user-guides/edit-schedule.md
new file mode 100644
index 0000000..b3c066e
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/user-guides/edit-schedule.md
@@ -0,0 +1,52 @@
+---
+id: edit-schedule
+title: Edit Chaos Scenario Schedule
+sidebar_label: Edit Chaos Scenario Schedule
+---
+
+---
+
+## Before you begin
+
+You must schedule a chaos scenario. To know more about scheduling chaos scenarios click [here](schedule-workflow.md)
+
+---
+
+After you have scheduled a chaos scenario, you might have a need of changing the schedule of a recurring chaos scenario. To edit the schedule follow these steps:
+
+## 1. Select edit schedule from the menu
+
+In the `Schedules` tab of `Litmus Chaos Scenarios` page you can click on the triple dots of the schedule to access more options for it. From the menu select the `Edit Schedule` option.
+
+
+
+Selecting Edit Schedule from the Menu
+
+
+## 2. Click on edit button
+
+Now you'll be seeing the Summary of your chaos scenario and you can click on the `Edit` button to change the schedule.
+
+
+
+Summary of the Chaos Scenario with Edit button
+
+
+## 3. Change the schedule
+
+Here you can change the schedule to the required interval and click on the `Verify` button.
+
+
+
+Editing the Schedule
+
+
+## 4. Save the changes
+
+Click on the `Save Changes` button to commit the changes to your chaos scenario.
+
+## Learn more
+
+- [Observe Chaos Scenario](observe-workflow.md)
+- [Save Chaos Scenarios as a Template](save-as-template.md)
+- [Re-run a Chaos Scenario](re-run-workflow.md)
diff --git a/website/versioned_docs/version-2.13.0/user-guides/editing-queries-app-dashboard.md b/website/versioned_docs/version-2.13.0/user-guides/editing-queries-app-dashboard.md
new file mode 100644
index 0000000..45cd1fa
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/user-guides/editing-queries-app-dashboard.md
@@ -0,0 +1,92 @@
+---
+id: editing-queries-app-dashboard
+title: Editing Queries for Panels in Application Dashboard
+sidebar_label: Editing Panel Queries
+---
+
+---
+
+## Before you begin
+
+In order to edit the queries, you must first have a [data source](configure-datasource.md) connected and a configured [dashboard](manage-app-dashboard.md#create-dashboard).
+
+---
+
+## Dashboard Structure
+
+For visualization of the metrics, you need to tune the queries as per your use case. To learn about the dashboard schema [click here](https://raw.githubusercontent.com/litmuschaos/litmus/master/monitoring/portal-dashboards/schema.json). The hierarchical structure of the dashboard is defined as follows:
+
+```
+Dashboard (root)
++--Panel Group
+ +-- Panel
+ +-- Graphs
+```
+
+The dashboard is the root level element that contains multiple panel groups. A panel group is a collection of similar types of panels. For example, panels that reflect the data about pod CPU usage should be grouped under the same panel group. A panel is a collection of similar types of graphs. For example, if multiple graphs are primarily based on the `HTTP` metric like `http_request_count_seconds` and `http_request_duration_seconds_sum` then they can be placed under the same panel.
+
+
+
+Create dashboard, Tune the queries step
+
+
+## Editing Queries
+
+- **Add a panel:** Every individual tab in the `Tune the queries` header section corresponds to a panel. For example in the image given below `Chaos-Pod-CPU Usage` and `Chaos-Pod-Memory Usage` both are individual panels. To add another panel simply click on `+ Add Panel` and a new panel will appear with the name `Untitled Panel`.
+
+ By default, the newly added panel is placed in the `Untitled Group name`. You can select a panel group from the list of the existing panel groups or add a new panel group by clicking on `Untitled Group name`, entering a new name, adding it to the list by hitting enter and then selecting it from the list of all panel groups. For example, in the image below we have added a new panel group `HTTP Panel Group`.
+
+ To edit the panel name click on `Untitled Panel` and rename it to any desired name of your choice. For example in the image below a panel named `Http requests` has been added.
+
+
+
+Adding a panel
+
+
+- **Delete a panel:** Click to delete the current panel
+- **Configure panel:** Click to open/close the configuration dropdown for the current panel
+
+- **Add a query:** To add a query in the panel, click on `Add Query` button.
+ A new query will be created with some prefilled configurations.
+
+
+
+Editing a query
+
+
+- **Copy query:** Click to copy the query.
+- **Delete a query:** Click to delete the specific query.
+- **Hide query:** Click to hide the query from the panel. This feature assists you in creating and tuning the graph without deleting the queries.
+- **Queries:** you can edit the queries to get the appropriate visualisations of your applicationβs metrics. The number of queries present in the particular panel is also mentioned besides the `Queries` text. Please note that the metric, key and values fields provide you assistance in the generation of a query. You may generate a query with their assistance or if you already have a query then you can directly add it in the query field.
+
+ - Metric: All the metrics which are valid as per the connected data source are listed in the dropdown. Select any metric as per your requirement. Also if you want to input a metric that is not listed in the dropdown then you may simply enter the metric name as the option of free-solo has been enabled.
+ - (Optional) Key & Values: Based upon your selection of the metric, all the valid keys are listed in the dropdown. For a given key all the possible valid values are listed in the drop-down list in the Values field. You may select multiple values for the given key.
+
+ To select and configure multiple keys, you can switch between all the keys available and select the corresponding values for them. All of your selections for the keys and their values are reflected in the query generated based upon your selection.
+
+ - Query: This field can be auto-generated based upon your selections for the metric, key and values field or you can directly provide it with a query. The query editing option also comes along with intelligence for user assistance.
+
+ - Configurations :
+ - (Optional) Legends: The legend field is used for grouping the metric data
+ - Min-step: The time interval between the two data points are the given metric. By default, it is `5 seconds`. The lower the min-step the denser the graph is.
+ - Format: The format for the given metric. By default, it is `Time Series`.
+ - Graph: Select the type of graph with which you want to visualize the graph. By default, it is a `Line graph`.
+ - Resolution: To smoothen the rendering process for metrics with a huge amount of data, a resolution option is provided. Resolution determines the ratio of data points to be shown out of all the data points fetched by the given metric. This feature is under development and will be fully functional in the upcoming version.
+
+- **Visualizations:**
+ It enables the user to customize the visual experience on the dashboard.
+ - Points: By default points option is turned off. If switched on, it will plot a point marker for the individual data points of the metric.
+ - Grids: By default, the grid option is turned on. It is meant to render a grid line in the background of the graph which aids the viewers of the graph to perceive and evaluate the unlabeled data points of the metrics.
+
+
+
+Visualization options
+
+
+- **Discard changes:** By clicking this button it reverts all the changes performed in the given panel.
+
+- **Save changes:** Click this button to save all the changes made in the dashboard.
+
+## Learn more
+
+- [Sharing Application Dashboards](share-app-dashboard.md)
diff --git a/website/versioned_docs/version-2.13.0/user-guides/event-triggered-chaos.md b/website/versioned_docs/version-2.13.0/user-guides/event-triggered-chaos.md
new file mode 100644
index 0000000..19be671
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/user-guides/event-triggered-chaos.md
@@ -0,0 +1,9 @@
+---
+id: event-triggered-chaos
+title: Event Triggered Chaos using GitOps
+sidebar_label: Event Triggered Chaos (GitOps)
+---
+
+---
+
+## Coming soon
diff --git a/website/versioned_docs/version-2.13.0/user-guides/gitops-configuration.md b/website/versioned_docs/version-2.13.0/user-guides/gitops-configuration.md
new file mode 100644
index 0000000..9a33bd5
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/user-guides/gitops-configuration.md
@@ -0,0 +1,108 @@
+---
+id: gitops-configuration
+title: Configuring GitOps
+sidebar_label: Configuring GitOps
+---
+
+## Introduction
+
+GitOps enables you to configure a single source of truth for your chaos scenarios and experiments, any changes made either to the artifacts stored in the configured git repository or the portal will be synced.
+
+## Before you begin
+
+- [Gitops](../concepts/gitops.md)
+- Chaos Delegate
+- [Chaos Scenario](../concepts/chaos-workflow.md)
+- Ensure that you have an active internet connection and a git repository.
+
+## Steps to configure GitOps
+
+- Setup a git repository, so that the ChaosCenter can sync with it, and push all the chaos scenarios in that repository.
+- The git repo can be public or private but for authorization, you have to provide an access token or any other mode of authentication.
+- Login into ChaosCenter, go to `GitOps` tab under `Settings`.
+
+
+
+- Select the `Git Repository` radio button.
+- Copy the git URL of your git repository and paste it in the `Git URL` text box.
+- Enter the branch where you want to sync your chaos scenarios.
+
+
+
+- You can allow access of your repository either through an access token or through an SSH key.
+- In the case of the SSH key, just copy the key and paste it in the`Deploy Keys` Tab inside `Settings` in your git - repository. Click on the allow write access checkbox, and then on the `Add key` button.
+- Go back to the portal and click on the update button. A modal will pop up showing, `Successfully updated GitOps!` message.
+- Some metadata will be pushed to your repository, that is the projectID of your project.
+- Now whenever you schedule a chaos scenario, it will automatically be pushed to your repository. And that repository will be the single source of truth.
+
+:::note
+It is also possible to account for the chaos scenarios that are created and pushed to the git repository directly, after configuring GitOps. In this case, if the chaos scenario is a single run chaos scenario, then it starts executing as soon as it is pushed to the repository. Alternatively, if the chaos scenario is a scheduled chaos scenario, then it executes as per the defined schedule. On the other hand, updating an existing chaos scenario present in the git repository will not execute the chaos scenario but only sync the chaos scenario resource definition with the ChaosCenter, if applicable.
+:::
+
+## Steps to configure Event-Triggered Chaos Injection
+
+- Once the chaos scenario is pushed to your repository, youβll notice every chaos scenario has a `workflow_id`. You can get this from the chaos scenario YAML file. You need to copy the id and annotate the target application so that if thereβs any change in the application, gitops will sync the chaos scenario using this workflow_id and run it on your target application. You can use the following command:
+
+```
+kubectl annotate deploy/target-application litmuschaos.io/workflow=${workflow_id}
+```
+
+```
+kubectl annotate deploy/target-application litmuschaos.io/gitops=true
+```
+
+- You can check if the event-tracker is running using this command:
+
+```
+kubectl get pods -n litmus -w
+```
+
+- To check the logs copy the pod name of the event-tracker and add it to the following command:
+
+```
+kubectl logs -f event-tracker-pod-name -n litmus
+```
+
+In the logs, youβll notice that the event-tracker has started.
+If you make changes in the application the event tracker will trigger the chaos injection. If the policy conditions are met then the event tracker will inform the server to schedule a chaos scenario in that same target. For eg: if you have an Nginx app as your target application, you can just edit the deployment and change its image tag, this will trigger the chaos injection.
+
+Below is a sample policy where two conditions are present and will be validated by the respective operator. The chaos scenario will be triggered if both conditions are met due to the `AND` condition type.
+
+```
+apiVersion: eventtracker.litmuschaos.io/v1
+kind: EventTrackerPolicy
+metadata:
+ name: eventtrackerpolicy-sample
+ namespace: litmus
+spec:
+ # Add fields here
+ condition_type: "and"
+ conditions:
+ - key: "spec.replicas"
+ value: "1"
+ operator: EqualTo
+ - key: "spec.template.spec.containers[0].image"
+ value: "nginx:1.18"
+ operator: EqualTo
+
+```
+
+Currently supported policy operators are:
+
+- EqualTo
+- NotEqualTo
+- LessThan
+- GreaterThan
+- GreaterThanEqualTo
+- LessThanEqualTo
+
+## Resources
+
+
+
+
+
+## Learn More
+
+- [Schedule a chaos scenario](../user-guides/schedule-workflow.md)
+- [Observe a Chaos Scenario](../user-guides/observe-workflow.md)
diff --git a/website/versioned_docs/version-2.13.0/user-guides/image-registry.md b/website/versioned_docs/version-2.13.0/user-guides/image-registry.md
new file mode 100644
index 0000000..e626dec
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/user-guides/image-registry.md
@@ -0,0 +1,63 @@
+---
+id: image-registry
+title: Using different Image Registries in a Chaos Scenario
+sidebar_label: Using different Image Registries
+---
+
+---
+
+A container image registry can be defined as a collection of repositories that store container image.
+These can be either public or private. Few of the container image registries are Docker, Red Hat Quay, Google Container Registry.
+By default LitmusChaos uses DockerHub for managing the different images. These images are then used in Chaos Scenarios. Few images that are used in the Litmus chaos scenarios are `litmuschaos:k8s`, `litmuschaos:litmus-checker` etc.
+With ChaosCenter, you get the privilege to use your own/custom image registries for Chaos Scenarios.
+
+## Before you begin
+
+To understand the concept of Image Registry, make sure you are aware of [Chaos Scenario](../concepts/chaos-workflow.md) and the different image registries that are used in it.
+
+## Steps to Update Chaos Scenario Image Registry
+
+To updated the Chaos Scenario Image Registry, you can go to Settings in ChaosCenter. In settings, there will be tab named Image Registry. On clicking the Image Registry tab, you can see that the default Registry server is `docker.io`, Registry name is `litmuschaos` and it is a Public registry.
+
+
+
+
+To update this, click on the `Use Custom Values` option and provide the following details:
+
+1. Registry Server
+2. Registry Name
+3. Registry Type `Public/Private`
+
+
+
+
+If the Registry Type is `Private`, make sure to provide the secret and the namespace where the secret is present.
+
+Once the details are provided, click on the `Save Changes` button and you can see the updated Image Registry changes.
+
+
+
+
+
+Now while scheduling a chaos scenario, the image registry changes will be visible. Here's the code snippet from a Chaos Scenario after the image registry change.
+
+```yaml
+- name: install-application
+ container:
+ image: docker.io/testing-reg/litmus-app-deployer:latest
+ args:
+ - -namespace=bank
+ - -typeName=resilient
+ - -operation=apply
+ - -timeout=400
+ - -app=bank-of-anthos
+ - -scope=cluster
+ - name: install-chaos-experiments
+ container:
+ image: docker.io/testing-reg/k8s:latest
+```
+
+## Learn More
+
+- [What is a Chaos Scenario](../concepts/chaos-workflow.md)
+- [What is ChaosCenter](../getting-started/resources.md#chaoscenter)
diff --git a/website/versioned_docs/version-2.13.0/user-guides/invite-team-member.md b/website/versioned_docs/version-2.13.0/user-guides/invite-team-member.md
new file mode 100644
index 0000000..de5f8a6
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/user-guides/invite-team-member.md
@@ -0,0 +1,34 @@
+---
+id: invite-team-member
+title: Invite a Team Member
+sidebar_label: Invite Team Member
+---
+
+---
+
+> In the `/settings` route (settings on the sidebar) the `Team` tab can be used to access the teaming feature by the `owner`. We recommend learning about the concept of [teaming](../concepts/teaming.md) before proceeding with the following user guides.
+
+With this feature, you can select as many users you want, choose their roles individually and send the invitation at once! Once it is done successfully you can see the status of the sent invitation (whether it is in a pending/accepted/declined or exited state) along with all the other necessary details in the `Invited` tab.
+
+## 1. Find the user you want to invite
+
+In the team tab, click the `Invite new member` button as shown below:
+
+
+
+## 2. Select all the members to be invited
+
+From the list of all available members, choose the ones you want to collaborate on your chaos with and decide what project level access they should have to your project (Viewer/Editor) and hit the `Send Invite` button.
+
+
+
+## 3. Collaborate over the chaos!
+
+On successful invitation you will receive the confirmation dialog as shown below indicating selected members have been invited to your project.
+
+
+
+## Learn more
+
+- [Edit an invitation](edit-invite.md)
+- [Accept invite](accept-invite.md)
diff --git a/website/versioned_docs/version-2.13.0/user-guides/leave-project.md b/website/versioned_docs/version-2.13.0/user-guides/leave-project.md
new file mode 100644
index 0000000..e84d23b
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/user-guides/leave-project.md
@@ -0,0 +1,24 @@
+---
+id: leave-project
+title: Leave a Project
+sidebar_label: Leave Project
+---
+
+---
+
+You can leave a project that you no longer wish to be a part of.
+
+## 1. Identify the project you want to leave
+
+In the settings page, scroll to the very bottom of the `Team` tab. Here you will see a list of all the projects you are a part of, identify the project youβd like to leave and click on the `Leave Project` button:
+
+
+
+> Note: Having left the project, the number of active projects will change and the project you left can no longer be observed as a currently active project in the `Team` tab
+
+
+
+## Learn more
+
+- [Invite a member to your project](invite-team-member.md)
+- [Remove a member from your project](remove-team-member.md)
diff --git a/website/versioned_docs/version-2.13.0/user-guides/manage-app-dashboard.md b/website/versioned_docs/version-2.13.0/user-guides/manage-app-dashboard.md
new file mode 100644
index 0000000..4fae3cc
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/user-guides/manage-app-dashboard.md
@@ -0,0 +1,93 @@
+---
+id: manage-app-dashboard
+title: Creating and Updating an Application Dashboard
+sidebar_label: Manage Application Dashboard
+---
+
+---
+
+Observing chaos injections and deriving insights from the chaos events is the core part of Chaos Observability. Whenever a chaos scenario run is performed its impact may be observed across different services and applications. Application dashboards provide a systematic visualization of all such events along with the performance of the individual service/application. To learn more about the dashboard schema architecture [click here](https://raw.githubusercontent.com/litmuschaos/litmus/master/monitoring/portal-dashboards/schema.json)
+
+## Before you begin
+
+To configure an application dashboard, you must first add a data source. To learn more about data sources [click here](configure-datasource.md)
+
+- If no data source is available, a banner on the application dashboard tab requests you to add it before configuring a dashboard.
+
+
+
+Application dashboard with no configured data source
+
+
+- If a data source becomes inactive after dashboard creation then you will be requested to either reconfigure the dashboard with another data source or update the existing data source.
+
+---
+
+## Table for configured dashboards
+
+All the configured dashboards are listed under the Dashboards table. The table provides you all the details related to the dashboard like the name of the dashboard, the chaos delegate with which it has been connected, type of the dashboard, connected data source type and the last date it was opened.
+
+For all the dashboards listed in the table, you can filter the dashboard with respect to chaos delegate name, dashboard-type and time period for dashboard creation.
+
+
+
+Application dashboard table with a configured dashboard
+
+
+On clicking on more options, you can select `View` to open the dashboards, click on configure to make changes in the existing dashboard, you can also download the dashboard in `JSON` format and click on `Delete` to remove the dashboard.
+
+## Create dashboard
+
+- To add a dashboard, click on the `Create dashboard` button placed at the right corner.
+
+
+
+Creating a dashboard
+
+
+- **Choose a dashboard-type:**
+
+
+Select dashboard type
+
+
+You need to select the dashboard type from the following options:
+
+- _Predefined dashboards:_ Litmus provides a set of predefined dashboards for different applications and use-cases like Node metric, Pod metric, Sock Shop etc along with the chaos events and chaos exporter metrics.
+- _Custom dashboard:_ To create your custom dashboard from scratch.
+- _Upload a dashboard:_ To upload a dashboard in a JSON file format. This option is helpful for users who already have a JSON file for the dashboard configurations.
+
+
+
+Configuring the metadata of the dashboard
+
+
+- **Dashboard metadata:**
+
+ - Name: Enter the name for your dashboard. A default name for the dashboard is provided you may override it as per your requirement.
+ - chaos delegate: Select the chaos delegate for which you want to set up the dashboard. By default, an chaos delegate from the list of all connected chaos delegates is selected for you. You may override this as per your requirement.
+ - Data source: Select the data source from which you want to scrap the metrics and visualise it. By default, a data source from the list of all the active data sources is selected for you. You may override this as per your requirement.
+ - Dashboard type: It contains information about the type of the dashboard being configured. If you want to change it you may navigate back to `Choose a dashboard type` and select the desired dashboard type. Once the dashboard is created its type cannot be changed.
+ - Applications: You can make selections for particular namespaces, application types and specific applications which will assist you while tuning the queries and visualizing the metrics.
+
+
+
+Selecting applications
+
+
+- **Select the metrics:** For the predefined dashboards, the checklist of the corresponding metrics is provided from which you may select the required metrics to be plotted.
+
+
+
+Selecting the required metrics
+
+
+The dashboards comprise panel groups each having a set of panel metrics. For example here, CPU Utilization Metrics is the panel group and Chaos-Node-CPU Utilization is the panel metric.
+
+- **Tune the queries:**
+ Tuning the queries is an optional step. If you want to continue with the default set of queries then click on Save Changes and the dashboard will be created. To learn more about tuning the queries [click here](editing-queries-app-dashboard.md).
+
+## Learn more
+
+- [Editing Panel Queries](editing-queries-app-dashboard.md)
+- [Sharing Application Dashboards](share-app-dashboard.md)
diff --git a/website/versioned_docs/version-2.13.0/user-guides/observability-set-up.md b/website/versioned_docs/version-2.13.0/user-guides/observability-set-up.md
new file mode 100644
index 0000000..2c28815
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/user-guides/observability-set-up.md
@@ -0,0 +1,54 @@
+---
+id: observability-set-up
+title: Setup Observability with ChaosCenter
+sidebar_label: Setup Observability
+---
+
+---
+
+Overview Tab helps you to manage your connected data sources and dashboards, all while making it easier to view and analyze your chaos scenarios. The overview tab is split into 3 parts -
+
+- Data Sources
+- Application Dashboards
+- Chaos Scenario Dashboards
+
+## Before you begin
+
+Before starting with observability setup, you have to connect an chaos delegate to get chaos scenario statistics & keep track of chaos scenarios performance.
+For connecting a new chaos delegate, you can follow [here](../litmusctl/installation.md) .
+
+---
+
+Once the chaos delegate is connected, you will see a banner for adding data sources and a list of recently updated chaos scenario dashboards (if any).
+
+
+
+Overview page, When no chaos scenarios are running
+
+
+
+
+Overview page, When some chaos scenarios have been already scheduled
+
+
+If you already have a data source, then they can connect the same by clicking on _**Add data source**_ button and following the corresponding instructions. For deploying a new data source, you can follow the sample configuration steps by clicking on _**Sample Prometheus configuration**_.
+
+Once you have added a data source successfully, you will be able to see the data source listed on the overview page.you can add more data sources by clicking on _**Add data source**_ button.
+
+
+
+Now, you will get a banner with an option to add a dashboard for visualizing the data from the connected data sources.
+
+After setting up the dashboard, you will be able to see the dashboard on the overview page.
+
+
+
+You can view, configure & download the dashboards in the form of JSON for reusability using provided buttons.
+
+You can check the chaos scenario analytics and the chaos scenario run graph by clicking on _**see chaos scenario run**_ & _**see chaos scenario analytics**_ icons for a chaos scenario from the list of chaos scenario dashboards present on the overview page.
+
+## Learn more
+
+- [Analyze a Chaos Scenario](analyze-workflow.md)
+- [Configure Datasource](configure-datasource.md)
+- [Manage Application Dashboard](manage-app-dashboard.md)
diff --git a/website/versioned_docs/version-2.13.0/user-guides/observe-workflow.md b/website/versioned_docs/version-2.13.0/user-guides/observe-workflow.md
new file mode 100644
index 0000000..a86fe9c
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/user-guides/observe-workflow.md
@@ -0,0 +1,112 @@
+---
+id: observe-workflow
+title: Observe Chaos Scenario
+sidebar_label: Observe Chaos Scenario
+---
+
+---
+
+## Before you begin
+
+You must schedule a chaos scenario. To know more about scheduling chaos scenarios click [here](schedule-workflow.md)
+
+---
+
+After scheduling a chaos scenario, you can track the status of the chaos scenario run from the `Runs` tab in the `Litmus Chaos Scenario`. The status that is currently displayed are:
+
+- Failed
+- Running
+- Completed
+
+
+
+Chaos Scenario Runs Table showing a Running Chaos Scenario
+
+
+---
+
+you can analyze a chaos scenario using two methods:
+
+## Visualize the chaos scenario run graph
+
+After scheduling a chaos scenario, you can click on the **Show the chaos scenario** option or click on the chaos scenario name to see the real-time graph of the chaos scenario.
+
+
+
+Graph of Podtato Head chaos scenario
+
+
+The graph consists of useful information such as :
+
+- Phase of individual nodes.
+- Total time taken for the nodes to execute.
+- Structure of the experiments (Serial or Parallel experiments).
+
+You can also visualize the non Chaos scenarios. The logs of individual nodes are also available here.
+
+
+
+Graph of a non Chaos Scenario
+
+
+## View logs of individual nodes
+
+you can click on the nodes to get the logs of that particular step. If the revert-chaos step is disabled, the complete logs are available which include the runner pod logs and the chaos logs.
+
+
+
+Podtato Head chaos scenario with Logs
+
+
+## View chaos results
+
+Once the experiment completes, the [Chaos Results](../concepts/chaos-result.md) are also available alongside the logs. The Chaos Results are directly fetched from the ChaosResult CRD.
+
+
+
+Podtato Head chaos scenario with chaos logs and chaos result of generic/pod-delete experiment
+
+
+## Resilience Score Calculation
+
+A Resilience Score is the measure of how resilient your chaos scenario run is considering all the chaos experiments and their individual result points. This calculation takes into account the individual experiment weights (from a range of 1-10) which are relative to each other.
+
+Once a weight has been assigned to the experiment, we look for the [Probe Success Percentage](../concepts/probes#probe-status--deriving-inferences) for that experiment itself (Post Chaos) and calculate the total resilience result for that experiment as a multiplication of the weight given and the probe success percentage returned after the Chaos Run.
+
+```doc
+Total Resilience for one single experiment = (Weight Given to that experiment * Probe Success Percentage)
+```
+
+> If an experiment doesn't have a probe in it, the probe success percentage returned can either be 0 or 100 based on the experiment verdict. If the experiment passed then it returns 100 else 0.
+
+The Final Resilience Score is calculated by dividing the total test result by the sum of all the weights of all the experiments combined in a single chaos scenario.
+
+For example, if we consider two experiments in a chaos scenario, here is what the calculation would look like.
+
+> Considering Probe Success Percentage is 100
+
+| Experiment | Weight | Probe Success Percentage | Total Test Result |
+| :--------- | :---------------------: | -----------------------: | -----------------------------------: |
+| exp1 | 3 | 100 | (3 \* 100) = 300 |
+| exp2 | 9 | 100 | (9 \* 100) = 900 |
+| | Weight Sum = 3 + 9 = 12 | | Total Test Result = 300 + 900 = 1200 |
+
+```
+Resilience Score = Total Test Result / Weight Sum
+ = 1200 / 12
+ = 100%
+```
+
+## Analytics from the runs tab
+
+Once the chaos scenario run execution completes, you can click the **Show the analytics** option in the `Runs` tab of `Litmus Chaos Scenarios` which opens up a [Chaos Scenario Dashboard](../user-guides/analyze-workflow.md) which can also be accessed from the Analytics section and is explained more [here](../user-guides/analyze-workflow.md). This analytics can be crucial to analyse the Cron Chaos Scenarios.
+
+## Resources
+
+
+
+## Learn more
+
+- [Edit Schedule](edit-schedule.md)
+- [Download Chaos Scenario Manifest](download-workflow-manifest.md)
+- [Re-run a Chaos Scenario](re-run-workflow.md)
diff --git a/website/versioned_docs/version-2.13.0/user-guides/overview.md b/website/versioned_docs/version-2.13.0/user-guides/overview.md
new file mode 100644
index 0000000..c2626ff
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/user-guides/overview.md
@@ -0,0 +1,49 @@
+---
+id: overview
+title: Overview
+sidebar_label: Overview
+---
+
+---
+
+The User Guides section details Processes, User-flows and How-tos detailing all sorts of scenarios in various environments. Technical details and inner workings of the various components are explained in the [Concepts](../concepts/overview.md) section.
+
+### [Advanced Installation](chaoscenter-cluster-scope-installation.md)
+
+Install ChaosCenter and Chaos Delegate in various environment configurations.
+
+### [Injecting Fault](schedule-workflow.md)
+
+Constructing, Scheduling, Editing and Observing chaos scenarios.
+
+### [Observing Chaos](observability-set-up.md)
+
+Set-up monitoring, Analyze and Compare various metrics that help you make reliable decisions regarding your application.
+
+### [Event Triggered Chaos using GitOps](gitops-configuration.md)
+
+GitOps in Litmus provides a way of using Event-Driven Chaos Injection, where target resources(stateful sets, deployments, etc.) can be configured to automatically trigger chaos scenarios with any changes in the resource spec.
+
+### [Account Settings](account-settings.md)
+
+Changing your personal details such as the email, full name, and password.
+
+### [User Management](create-user.md)
+
+Adding and Deactivating users to ChaosCenter and Resetting passwords for users.
+
+### [Managing Projects](change-project-name.md)
+
+Probes are pluggable checks that can be defined within the ChaosEngine for any Chaos Experiment.
+
+### [Teaming](invite-team-member.md)
+
+Adding members to a project, Editing user-invite and Removing team members from a project.
+
+### [Using different Image Registries in a Chaos Scenario](image-registry.md)
+
+Using different Image Registries like Docker, Red Hat Quay, Google Container Registry in a Chaos Scenario.
+
+### [Uninstalling Litmus](uninstall-litmus.md)
+
+Disconnecting Chaos Delegate and uninstalling ChaosCenter.
diff --git a/website/versioned_docs/version-2.13.0/user-guides/re-run-workflow.md b/website/versioned_docs/version-2.13.0/user-guides/re-run-workflow.md
new file mode 100644
index 0000000..327007d
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/user-guides/re-run-workflow.md
@@ -0,0 +1,30 @@
+---
+id: re-run-workflow
+title: Re-run a chaos scenario
+sidebar_label: Re-run chaos scenario
+---
+
+---
+
+You can re-run any **_non-recurring_** schedule should you wish to test your application against it at any point.
+
+## Before you begin
+
+You can learn how to schedule your first chaos scenario [here](schedule-workflow.md).
+
+## 1. Go to the chaos scenarios sections
+
+In the `Chaos Scenario` page, go to the `Schedules` tab and click on the options menu for the specific schedule you wish to re-run:
+
+
+
+## 2. Click on the `Rerun Schedule` option
+
+After opening the options menu, click on the `Rerun Schedule` option. Having re-run a particular schedule, you can switch to the `Runs` tab and see that it has started to re-run as per the schedule configurations:
+
+
+
+## Learn more
+
+- [Schedule a chaos scenario](schedule-workflow.md)
+- [Delete a chaos scenario](delete-workflow.md)
diff --git a/website/versioned_docs/version-2.13.0/user-guides/remove-team-member.md b/website/versioned_docs/version-2.13.0/user-guides/remove-team-member.md
new file mode 100644
index 0000000..1f02bf4
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/user-guides/remove-team-member.md
@@ -0,0 +1,23 @@
+---
+id: remove-team-member
+title: Remove a Team Member
+sidebar_label: Remove Team Member
+---
+
+---
+
+If you are the project owner, you have the ability to remove any members from your project as required.
+
+## Steps
+
+### 1. Identify the member to remove
+
+In the `Team` tab in the settings page, scroll down to the `My project` table, here you will be able to see all the members who have their invitation status as `accepted` for your project collaboration invite. Here, identify the user to remove and click on the red `Remove` bin icon as shown.
+
+
+
+### 2. Confirmation for removal
+
+On hitting the `Remove` icon, you will be prompted to confirm the removal of the member, hit `Yes` to confirm and remove the member from your project.
+
+
diff --git a/website/versioned_docs/version-2.13.0/user-guides/reset-password.md b/website/versioned_docs/version-2.13.0/user-guides/reset-password.md
new file mode 100644
index 0000000..5bb19cd
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/user-guides/reset-password.md
@@ -0,0 +1,25 @@
+---
+id: reset-password
+title: Reset Password of a User
+sidebar_label: Reset Password
+---
+
+---
+
+The admin has the ability to reset the login password for any user in the portal.
+
+## 1. Locate the user
+
+Under the `User management` tab find the user who's password needs to be updated and click on the options icon to open a drop-down and select `Edit Profile` option
+
+
+
+## 2. Change the password
+
+In the `Login Details` section select the `New password` input field and type in the new password. Once done hit the `Save` button to update the password.
+
+
+
+## Learn more
+
+- [View users](view-user.md)
diff --git a/website/versioned_docs/version-2.13.0/user-guides/save-as-template.md b/website/versioned_docs/version-2.13.0/user-guides/save-as-template.md
new file mode 100644
index 0000000..c021834
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/user-guides/save-as-template.md
@@ -0,0 +1,43 @@
+---
+id: save-as-template
+title: Save Chaos Scenarios as a Template
+sidebar_label: Save Chaos Scenarios as Template
+---
+
+---
+
+You can save a schedule as a template for later usage in subsequent schedules. This section goes over the steps to achieve the same.
+
+## Before you begin
+
+You can learn how to schedule your first chaos scenario [here](schedule-workflow.md).
+
+## 1. Go to the chaos scenarios sections
+
+In the `Chaos Scenario` page, go to the `Schedules` tab and click on the options menu for the specific schedule you wish to save as a template:
+
+
+
+## 2. Click on the `Save Template` option
+
+After opening the options menu, click on the `Save Template` option. You will see the following modal popup. Here you can edit the chaos scenario `YAML` and provide a name and description for the template you are creating:
+
+
+
+## 3. Save the changes
+
+After having made all the changes you wish to preserve as a template, click the `Save Changes` button to save your template.
+
+
+
+## 4. Use your new template
+
+You can now see your template under the `Create a new chaos scenario by cloning an existing chaos scenario` option in the chaos scenario scheduling steps and can directly use it for your chaos.
+
+
+
+## Learn more
+
+- [Schedule a chaos scenario](schedule-workflow.md)
+- [Re-run a chaos scenario](re-run-workflow.md)
+- [Delete a chaos scenario](delete-workflow.md)
diff --git a/website/versioned_docs/version-2.13.0/user-guides/schedule-workflow.md b/website/versioned_docs/version-2.13.0/user-guides/schedule-workflow.md
new file mode 100644
index 0000000..058965e
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/user-guides/schedule-workflow.md
@@ -0,0 +1,155 @@
+---
+id: schedule-workflow
+title: Schedule a Chaos Scenario
+sidebar_label: Schedule Chaos Scenario
+---
+
+---
+
+## Before you begin
+
+You must connect an Chaos Delegate before scheduling a chaos scenario . There might be a default `Self Chaos Delegate` automatically created or you can [connect an external Chaos Delegate ](../litmusctl/installation.md).
+
+---
+
+Click on the **Schedule a chaos scenario ** button on the home page or **Schedule chaos scenario ** button in Litmus Chaos Scenarios page to get started.
+
+
+
+Home Page
+
+
+It will take you to the **Schedule a new Litmus chaos scenario ** page where you can choose or design your own chaos scenario by doing the following steps:
+
+## 1. Choose targetchaos delegate
+
+This is the first step in chaos scenario creation. In this step, you can select a target chaos delegate where the chaos scenario will be scheduled. These chaos delegate consist of the CRDs and the required resources to run a chaos scenario .
+While installing the Litmus Portal, a default chaos delegate named **Self Chaos Delegate ** is created.
+
+
+
+Selecting a Chaos Delegate
+
+
+After Selecting the chaos delegate , you can continue by clicking on **Next** button.
+
+> Note: You may have to wait for the chaos delegate to be up and ready, after which you can move forward by again clicking on βNextβ . Newly created users by the admin won't have any chaos delegate connected and thus won't be able to schedule a chaos scenario . As non-admin users, you will get a message βNo Cluster Registered With Your Project ID, Please Waitβ¦β if you try to create a chaos scenario .
+
+## 2. Choose a chaos scenario
+
+
+
+Choosing a Chaos Scenario
+
+
+In this step, you can create a chaos scenario from different methods, these include:
+
+- **Create a new chaos scenario from one of the pre-defined chaos scenario s** : With this option, you can select a pre-defined chaos scenarios which are available in the connected ChaosHub.
+
+- **Create a new chaos scenario by using cloned template chaos scenario ** : With this option, you can create a new chaos scenario from an existing one [saved as a template](save-as-template.md). Choose on of the saved templates and tweak it according to your requirements.
+
+- **Create a new chaos scenario using experiments from MyHub** : With this option, you can create customized chaos scenarios from the one of your connected ChaosHubs. With this option you can add multiple experiments from that ChaosHub either serially or in parallel to construct your chaos scenario graphically.
+
+- **Import chaos scenario using YAML** : With this option, you can import a [hand-crafted/constructed chaos scenario ](construct-workflow.md) manifest and tune it according to the use-case. You can also import a basic Argo chaos scenario using this functionality.
+ :::note
+ For an uploaded chaos scenario , the tune chaos scenario functionality will not be available. The uploaded chaos scenario is completely user-dependent or user-specific.
+
+## 3. Chaos Scenario Settings
+
+In this section, you can change the name of the chaos scenario and also provide a description to the chaos scenario . This section also consists information regarding the namespace where the chaos scenario will be scheduled.
+
+
+
+Change name and description
+
+
+## 4. Tune the chaos scenario
+
+This section consists of all the information related to the chaos scenario .
+Some new and advanced features that are present in this section are :
+
+1. **Chaos Scenario Visualization** : This feature allows you to visualize the chaos scenario even before scheduling it.
+ This gives a brief information related to the structure of chaos scenario i.e if the experiments are present in serial or parallel way.
+2. **Chaos Scenario Table** : This table contains the list of experiments present in the chaos scenario . It also consists of some valuable information related to the target applications.
+3. **Add Experiment** : If you have selected `Create a new chaos scenario using experiments from MyHub` in Choose a Chaos Scenario step, you can see a `Add a new experiment` button, this will allow you to add more experiments to the chaos scenario .
+4. **Edit Chaos Scenario ** : With this option, you can view and make changes in the chaos scenario manifest with a YAML editor.
+5. **Revert Chaos** : For custom chaos scenarios, you can now enable or disable the revert step from the portal.
+ With revert step enabled, a new functionality called `podGC` is also added which deletes the chaos scenario pods after the completion of chaos scenario as part of the clean-up process.
+
+
+
+Tuning a Predefined Chaos Scenario (Podtato Head)
+
+
+
+
+Editing Experiment Sequence
+
+
+
+
+Adding Experiments to Chaos Scenario (Available after choosing a Hub in previous step)
+
+
+Some of the other features that are included with Litmus Portal 2.0 are :
+
+1. **Target Selection** : On the chaos scenario table, you can select an experiment to edit the engine configuration directly from the portal. You can change the `annotationCheck` and `jobCleanUpPolicy` according to the use-case.
+ You can also target the application by selecting the namespace and the respective label of that application. We have added a functionality to fetch the live data from the selected chaos delegate like the available namespaces and resources that you can target.
+
+2. **Defining the steady state for the application** : With this step, you can add probes to your experiments. Probes are some additional checks that you can provide in your experiments. To know more about probes, you can visit [here](../concepts/probes.md).
+
+
+
+
+Target Selection
+
+
+## 5. Assign weights to experiments
+
+In this step, you can assign weights to the experiments present in the chaos scenario . These weights will be then used for the calculation of the resilience score after the chaos scenario completion. By default, 10 points are assigned to each experiment. This can be altered as per your use-case.
+
+
+
+Adjust Experiment Weights
+
+
+#### **The Importance of Weights in experiments**
+
+Giving a weightage to your experiment is a way of signifying/attaching the importance/priority of that experiment in your chaos scenario . The higher the weight, the more importance it holds.
+
+The weight priority is generally divided into three sections:
+
+- **0-3:** Low Priority
+- **4-6:** Medium Priority
+- **7-10:** High Priority
+
+## 6. Schedule
+
+In this step, you can schedule the chaos scenario in 2 ways:
+
+1. **Schedule now** : With this option, the chaos scenario will start as soon as you schedule it.
+2. **Recurring Schedule** : This option will allow you to schedule the chaos scenario in recurring ways. It converts a normal chaos scenario to `Cron` chaos scenario and a cron syntax is added in the chaos scenario manifest. The following methods are available to schedule a chaos scenario in recurring ways:
+ 1. Every Hour
+ 2. Every Day
+ 3. Every Week
+ 4. Every Month
+
+
+
+Scheduling a Cron Chaos Scenario
+
+
+## 7. Verify and commit
+
+This is the final step in chaos scenario creation process. In this step, you can validate all the changes related to the chaos scenario like the chaos scenario name, the experiment weights, chaos scenario description, chaos scenario manifest etc. Once you have verified all the changes, you can click the **Finish** button to start the schedule.
+
+
+
+View Summary and Commit
+
+
+## Learn more
+
+- [Observe Chaos Scenario ](observe-workflow.md)
+- [Edit Schedule](edit-schedule.md)
+- [Save Chaos Scenarios as a Template](save-as-template.md)
diff --git a/website/versioned_docs/version-2.13.0/user-guides/setup-datasource.md b/website/versioned_docs/version-2.13.0/user-guides/setup-datasource.md
new file mode 100644
index 0000000..3768e98
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/user-guides/setup-datasource.md
@@ -0,0 +1,471 @@
+---
+id: setup-datasource
+title: Setting up Data source
+sidebar_label: Setup Data source
+---
+
+---
+
+This guide provides sample scrape job to be used for Prometheus deploymentβs scrape-configmap and service monitors to be used with Prometheus operator for the different architectural topologies for integrating Prometheus (connecting a data source link) with Chaos center.
+
+### Before you begin
+
+To setup a data source for a chaos center project, you must know about [open observability](../concepts/open-observability.md) and [data source considerations](../concepts/datasource.md) in Litmus 2.0
+
+### Topologies
+
+Listed below are three among many topologies in which a data source can be setup for collecting chaos delegate cluster's metrics along with chaos metrics for chaos center.
+
+#### For Control plane chaos delegate / Self chaos delegate with Prometheus - scraping chaos-exporter metrics and events along with other metrics
+
+
+
+Data flow and topological diagram
+
+
+_Scrape jobs:_
+
+- **Chaos exporter**
+
+```yaml
+- job_name: 'chaos-exporter'
+ static_configs:
+ - targets: ['chaos-exporter.litmus.svc.cluster.local:8080']
+ relabel_configs:
+ - target_label: instance
+ replacement: 'chaos-exporter-service'
+```
+
+- **Kube state metrics exporter**
+
+```yaml
+- job_name: 'kube-state-metrics'
+ static_configs:
+ - targets: ['kube-state-metrics.monitoring.svc.cluster.local:8080']
+```
+
+- [Node exporter](https://github.com/litmuschaos/litmus/blob/master/monitoring/utils/prometheus/prometheus-scrape-configuration/02-prometheus-configMap.yaml)
+- [Black box exporter](https://github.com/litmuschaos/litmus/blob/master/monitoring/utils/prometheus/prometheus-scrape-configuration/02-prometheus-configMap.yaml)
+- [cAdvisor](https://github.com/litmuschaos/litmus/blob/master/monitoring/utils/prometheus/prometheus-scrape-configuration/02-prometheus-configMap.yaml)
+
+[Detailed setup guide for Prometheus deployment with scrape configuration](../integrations/prometheus)
+
+_Service monitors:_
+
+- **Chaos exporter**
+
+```yaml
+apiVersion: monitoring.coreos.com/v1
+kind: ServiceMonitor
+metadata:
+ name: chaos-exporter
+ labels:
+ k8s-app: chaos-exporter
+ namespace: litmus
+spec:
+ jobLabel: app
+ selector:
+ matchLabels:
+ app: chaos-exporter
+ namespaceSelector:
+ matchNames:
+ - litmus
+ endpoints:
+ - port: tcp
+ interval: 1s
+ metricRelabelings:
+ - targetLabel: instance
+ replacement: 'chaos-exporter-service'
+```
+
+- **Kube state metrics exporter**
+
+```yaml
+apiVersion: monitoring.coreos.com/v1
+kind: ServiceMonitor
+metadata:
+ labels:
+ app.kubernetes.io/name: kube-state-metrics
+ app.kubernetes.io/version: latest
+ k8s-app: kube-state-metrics
+ name: kube-state-metrics
+ namespace: monitoring
+spec:
+ endpoints:
+ - bearerTokenFile: /var/run/secrets/kubernetes.io/serviceaccount/token
+ honorLabels: true
+ interval: 30s
+ port: http-metrics
+ relabelings:
+ - action: labeldrop
+ regex: (pod|service|endpoint|namespace)
+ scheme: http
+ scrapeTimeout: 30s
+ tlsConfig:
+ insecureSkipVerify: true
+ - bearerTokenFile: /var/run/secrets/kubernetes.io/serviceaccount/token
+ interval: 30s
+ port: telemetry
+ scheme: http
+ tlsConfig:
+ insecureSkipVerify: true
+ jobLabel: app.kubernetes.io/name
+ selector:
+ matchLabels:
+ app.kubernetes.io/name: kube-state-metrics
+```
+
+- [Node exporter](https://github.com/litmuschaos/litmus/blob/master/monitoring/utils/metrics-exporters-with-service-monitors/node-exporter/service-monitor.yaml)
+- [Black box exporter](https://github.com/litmuschaos/litmus/blob/master/monitoring/utils/metrics-exporters-with-service-monitors/prometheus-blackbox-exporter-metrics/service-monitor.yaml)
+
+[Detailed setup guide for Prometheus operator with service monitors](../integrations/prometheus)
+
+##### Note:
+
+- Scrape jobs as per (above links) can also be added under [this](https://github.com/prometheus-community/helm-charts/blob/9b3d4815bdefa71ef94ac0d474934c4aaebb3891/charts/kube-prometheus-stack/values.yaml#L2247) additionalScrapeConfigs for the [Prometheus communityβs Kube prometheus stack](https://github.com/prometheus-community/helm-charts/blob/main/charts/kube-prometheus-stack/README.md)
+
+- Pod labels to be used with Prometheus operator installed via helm as part of the [Prometheus communityβs Kube prometheus stack](https://github.com/prometheus-community/helm-charts/blob/main/charts/kube-prometheus-stack/README.md) configured for podMonitors or with [Prometheusβs inbuilt Kubernetes service discovery](https://github.com/prometheus-community/helm-charts/blob/9b3d4815bdefa71ef94ac0d474934c4aaebb3891/charts/kube-prometheus-stack/values.yaml#L2492)
+
+_Chaos exporter_
+
+> labels
+
+```yaml
+labels:
+ app: chaos-exporter
+ release: prometheus-stack
+```
+
+> pod monitor
+
+```yaml
+apiVersion: monitoring.coreos.com/v1
+kind: PodMonitor
+metadata:
+ name: chaos-exporter-monitor
+ namespace: monitoring
+ labels:
+ release: prometheus-stack
+spec:
+ selector:
+ matchLabels:
+ app: chaos-exporter
+ namespaceSelector:
+ matchNames:
+ - litmus
+ podMetricsEndpoints:
+ - port: tcp
+ - interval: 1s
+ metricRelabelings:
+ - targetLabel: instance
+ replacement: 'chaos-exporter-service'
+```
+
+_Black box exporter_
+
+> labels
+
+```yaml
+labels:
+ app: prometheus-blackbox-exporter
+ release: prometheus-stack
+```
+
+> pod monitor
+
+```yaml
+apiVersion: monitoring.coreos.com/v1
+kind: PodMonitor
+metadata:
+ name: black-box-exporter-monitor
+ namespace: monitoring
+ labels:
+ release: prometheus-stack
+spec:
+ selector:
+ matchLabels:
+ app: prometheus-blackbox-exporter
+ namespaceSelector:
+ matchNames:
+ - monitoring
+ podMetricsEndpoints:
+ - port: http
+ - interval: 1s
+```
+
+[Detailed setup guide for Prometheus operator with pod monitors](../integrations/prometheus)
+
+#### For Multiple chaos delegate s with multiple prometheus instances - scraping chaos-exporter metrics and events along with other metrics
+
+
+
+Data flow and topological diagram
+
+
+- Scrape job and service monitor remain same as in case of Control plane chaos delegate / self chaos delegate , the individual [Prometheus instances can be connected](configure-datasource) as separate data sources to the Chaos center. [Separate dashboards can be created](manage-app-dashboard) by selecting specific chaos delegate s and their corresponding data source which is essentially a Prometheus time series database, collecting metrics from the chaos delegate cluster for application / infra metrics, chaos events and chaos verdicts.
+
+#### For Multiple chaos delegate s with single prometheus - scraping chaos-exporter metrics and events along with other metrics
+
+- Separate dashboards can be created by selecting specific chaos delegate s and the data source which is essentially a Prometheus time series database, collecting metrics from the chaos delegate cluster for application / infra metrics, chaos events and chaos verdicts.
+
+
+
+Data flow and topological diagram
+
+
+_Scrape jobs:_
+
+- **Chaos-exporter - chaos delegate -1**
+
+```yaml
+- job_name: 'chaos-exporter-agent-1'
+ static_configs:
+ - targets: ['']
+ relabel_configs:
+ - target_label: instance
+ replacement: 'chaos-exporter-service'
+```
+
+- **Chaos-exporter - chaos delegate -2**
+
+```yaml
+- job_name: 'chaos-exporter-agent-2'
+ static_configs:
+ - targets: ['']
+ relabel_configs:
+ - target_label: instance
+ replacement: 'chaos-exporter-service'
+```
+
+- **Kube state metrics exporter - chaos delegate -1**
+
+```yaml
+- job_name: 'kube-state-metrics-agent-1'
+ static_configs:
+ - targets: ['']
+```
+
+- **Kube state metrics exporter - chaos delegate -2**
+
+```yaml
+- job_name: 'kube-state-metrics-agent-2'
+ static_configs:
+ - targets: ['']
+```
+
+- [Node exporter](https://github.com/litmuschaos/litmus/blob/master/monitoring/utils/prometheus/prometheus-scrape-configuration/02-prometheus-configMap.yaml)
+- [Black box exporter](https://github.com/litmuschaos/litmus/blob/master/monitoring/utils/prometheus/prometheus-scrape-configuration/02-prometheus-configMap.yaml)
+- [cAdvisor](https://github.com/litmuschaos/litmus/blob/master/monitoring/utils/prometheus/prometheus-scrape-configuration/02-prometheus-configMap.yaml)
+
+[Detailed setup guide for Prometheus deployment with scrape configuration](../integrations/prometheus)
+
+_Service endpoint, spec and monitors:_
+
+- **Chaos-exporter - chaos delegate -1**
+
+```yaml
+kind: Service
+apiVersion: v1
+metadata:
+ name: chaos-exporter-agent-1
+ namespace: monitoring
+spec:
+ type: ClusterIP
+ ports:
+ - name: tcp
+ port: 8080
+ targetPort: 8080
+---
+kind: Endpoints
+apiVersion: v1
+metadata:
+ name: chaos-exporter-agent-1
+ namespace: monitoring
+subsets:
+ - addresses:
+ - ip:
+ ports:
+ - name: tcp
+ port: 8080
+---
+apiVersion: monitoring.coreos.com/v1
+kind: ServiceMonitor
+metadata:
+ labels:
+ k8s-app: chaos-exporter-agent-1
+ name: chaos-exporter-agent-1
+ namespace: monitoring
+spec:
+ jobLabel: app
+ selector:
+ matchLabels:
+ app: chaos-exporter-agent-1
+ namespaceSelector:
+ matchNames:
+ - monitoring
+ endpoints:
+ - interval: 1s
+ port: tcp
+ metricRelabelings:
+ - targetLabel: instance
+ replacement: 'chaos-exporter-service'
+```
+
+- **Chaos-exporter - chaos delegate -2**
+
+```yaml
+kind: Service
+apiVersion: v1
+metadata:
+ name: chaos-exporter-agent-2
+ namespace: monitoring
+spec:
+ type: ClusterIP
+ ports:
+ - name: tcp
+ port: 8080
+ targetPort: 8080
+---
+kind: Endpoints
+apiVersion: v1
+metadata:
+ name: chaos-exporter-agent-2
+ namespace: monitoring
+subsets:
+ - addresses:
+ - ip:
+ ports:
+ - name: tcp
+ port: 8080
+---
+apiVersion: monitoring.coreos.com/v1
+kind: ServiceMonitor
+metadata:
+ labels:
+ k8s-app: chaos-exporter-agent-2
+ name: chaos-exporter-agent-2
+ namespace: monitoring
+spec:
+ jobLabel: app
+ selector:
+ matchLabels:
+ app: chaos-exporter-agent-2
+ namespaceSelector:
+ matchNames:
+ - monitoring
+ endpoints:
+ - interval: 1s
+ port: tcp
+ metricRelabelings:
+ - targetLabel: instance
+ replacement: 'chaos-exporter-service'
+```
+
+- **Kube state metrics exporter - chaos delegate -1**
+
+```yaml
+kind: Service
+apiVersion: v1
+metadata:
+ name: kube-state-metrics-agent-1
+ namespace: monitoring
+spec:
+ type: ClusterIP
+ ports:
+ - name: tcp
+ port: 8080
+ targetPort: 8080
+---
+kind: Endpoints
+apiVersion: v1
+metadata:
+ name: kube-state-metrics-agent-1
+ namespace: monitoring
+subsets:
+ - addresses:
+ - ip:
+ ports:
+ - name: tcp
+ port: 8080
+---
+apiVersion: monitoring.coreos.com/v1
+kind: ServiceMonitor
+metadata:
+ labels:
+ k8s-app: kube-state-metrics-agent-1
+ name: kube-state-metrics-agent-1
+ namespace: monitoring
+spec:
+ jobLabel: app
+ selector:
+ matchLabels:
+ app: kube-state-metrics-agent-1
+ namespaceSelector:
+ matchNames:
+ - monitoring
+ endpoints:
+ - interval: 30s
+ port: tcp
+```
+
+- **Kube state metrics exporter - chaos delegate -2**
+
+```yaml
+kind: Service
+apiVersion: v1
+metadata:
+ name: kube-state-metrics-agent-2
+ namespace: monitoring
+spec:
+ type: ClusterIP
+ ports:
+ - name: tcp
+ port: 8080
+ targetPort: 8080
+---
+kind: Endpoints
+apiVersion: v1
+metadata:
+ name: kube-state-metrics-agent-2
+ namespace: monitoring
+subsets:
+ - addresses:
+ - ip:
+ ports:
+ - name: tcp
+ port: 8080
+---
+apiVersion: monitoring.coreos.com/v1
+kind: ServiceMonitor
+metadata:
+ labels:
+ k8s-app: kube-state-metrics-agent-2
+ name: kube-state-metrics-agent-2
+ namespace: monitoring
+spec:
+ jobLabel: app
+ selector:
+ matchLabels:
+ app: kube-state-metrics-agent-2
+ namespaceSelector:
+ matchNames:
+ - monitoring
+ endpoints:
+ - interval: 30s
+ port: tcp
+```
+
+- [Node exporter](https://github.com/litmuschaos/litmus/blob/master/monitoring/utils/metrics-exporters-with-service-monitors/node-exporter/service-monitor.yaml)
+- [Black box exporter](https://github.com/litmuschaos/litmus/blob/master/monitoring/utils/metrics-exporters-with-service-monitors/prometheus-blackbox-exporter-metrics/service-monitor.yaml)
+
+[Detailed setup guide for Prometheus operator with service monitors](../integrations/prometheus.md)
+
+### Resources
+
+
+
+### Learn more
+
+- [Observability Setup](observability-set-up.md)
+- [Configure Data Source](configure-datasource.md)
+- [Manage Application Dashboards](manage-app-dashboard.md)
diff --git a/website/versioned_docs/version-2.13.0/user-guides/setup-with-ingress.md b/website/versioned_docs/version-2.13.0/user-guides/setup-with-ingress.md
new file mode 100644
index 0000000..31ff881
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/user-guides/setup-with-ingress.md
@@ -0,0 +1,155 @@
+---
+id: setup-with-ingress
+title: Install Litmus ChaosCenter with Ingress
+sidebar_label: Setup With Ingress
+---
+
+---
+
+## Prerequisites
+
+Before setting up endpoint with Ingress make sure the [Litmus ChaosCenter](../getting-started/resources.md#chaoscenter) is installed in either one of these scopes
+
+- [Cluster Scope](chaoscenter-cluster-scope-installation.md)
+- [Namespace Scope](chaoscenter-namespace-scope-installation.md)
+
+## Install ChaosCenter with Ingress
+
+With Litmus-2.0.0, ChaosCenter can be installed with ingress.
+In the following doc, we will use the Nginx ingress controller for ingress setup.
+
+1. By default, the service type is `NodePort`. For Ingress, we need to change the service type to `ClusterIP` in the following services.
+
+- `litmusportal-frontend-service`
+- `litmusportal-server-service`
+
+2. Install Nginx Ingress Controller along with Kubernetes RBAC roles and bindings, please refer [here](https://kubernetes.github.io/ingress-nginx/deploy/#installation-guide)
+
+> - Set the environment variable **INGRESS** as true in the litmusportal-server deployment.
+
+Example:
+```bash
+kubectl set env deployment/litmusportal-server -n litmus --containers="graphql-server" INGRESS="true"
+```
+
+> - If you're changing ingress name from **litmus-ingress** to a different name, make sure to update the **INGRESS_NAME** environment variable in the litmusportal-server deployment
+
+Example:
+```bash
+kubectl set env deployment/litmusportal-server -n litmus --containers="graphql-server" INGRESS_NAME="litmus-ingress"
+```
+
+### With HTTP
+
+Sample litmus ingress manifest With HTTP
+
+```yaml
+apiVersion: networking.k8s.io/v1
+kind: Ingress
+metadata:
+ annotations:
+ kubernetes.io/ingress.class: nginx
+ nginx.ingress.kubernetes.io/rewrite-target: /$1
+ name: litmus-ingress
+spec:
+ rules:
+ - host: ''
+ http:
+ paths:
+ - backend:
+ service:
+ name: litmusportal-frontend-service
+ port:
+ number: 9091
+ path: /(.*)
+ pathType: ImplementationSpecific
+ - backend:
+ service:
+ name: litmusportal-server-service
+ port:
+ number: 9002
+ path: /backend/(.*)
+ pathType: ImplementationSpecific
+```
+
+```bash
+kubectl apply -f -n
+```
+
+### With HTTPS
+
+1. Install CertManager
+
+```bash
+kubectl create namespace cert-manager
+helm repo add jetstack https://charts.jetstack.io
+helm install cert-manager jetstack/cert-manager --namespace cert-manager --create-namespace --version v1.3.0 --set installCRDs=true
+```
+
+2. Install LetsEncrypt Cluster Issuer
+
+```yaml
+apiVersion: cert-manager.io/v1alpha2
+kind: ClusterIssuer
+metadata:
+ name: letsencrypt
+spec:
+ acme:
+ server: https://acme-v02.api.letsencrypt.org/directory
+ email: "your@mail.com"
+ privateKeySecretRef:
+ name: letsencrypt
+ solvers:
+ - http01:
+ ingress:
+ class: nginx
+```
+
+3. Sample Litmus Portal Ingress Manifest with HTTPS
+
+```yaml
+apiVersion: networking.k8s.io/v1
+kind: Ingress
+metadata:
+ annotations:
+ cert-manager.io/cluster-issuer: letsencrypt
+ kubernetes.io/ingress.class: nginx
+ nginx.ingress.kubernetes.io/rewrite-target: /$1
+ labels:
+ component: litmusportal-frontend
+ name: litmusportal-ingress
+ namespace: litmus
+spec:
+ rules:
+ - host: ''
+ http:
+ paths:
+ - backend:
+ service:
+ name: litmusportal-frontend-service
+ port:
+ number: 9091
+ path: /(.*)
+ pathType: ImplementationSpecific
+ - backend:
+ service:
+ name: litmusportal-server-service
+ port:
+ number: 9002
+ path: /backend/(.*)
+ pathType: ImplementationSpecific
+ tls:
+ - hosts:
+ - ''
+ secretName: litmuspreview-tls-secret
+```
+
+```bash
+kubectl apply -f -n
+```
+
+## Learn more
+
+- [Setup Endpoints and Access ChaosCenter without Ingress](setup-without-ingress.md)
+- [Install ChaosCenter in Namespace Scope](chaoscenter-namespace-scope-installation.md)
+- [Install ChaosCenter in Cluster Scope](chaoscenter-cluster-scope-installation.md)
diff --git a/website/versioned_docs/version-2.13.0/user-guides/setup-without-ingress.md b/website/versioned_docs/version-2.13.0/user-guides/setup-without-ingress.md
new file mode 100644
index 0000000..fbb53bd
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/user-guides/setup-without-ingress.md
@@ -0,0 +1,81 @@
+---
+id: setup-without-ingress
+title: Setting up Endpoints without Ingress
+sidebar_label: Setup without Ingress
+---
+
+---
+
+## Prerequisites
+
+Before setting up endpoint without Ingress make sure the [Litmus ChaosCenter](../getting-started/resources.md#chaoscenter) is installed in either one of these scopes
+
+- [Cluster Scope](chaoscenter-cluster-scope-installation.md)
+- [Namespace Scope](chaoscenter-namespace-scope-installation.md)
+
+## **With NodePort**
+
+To setup and login to Litmus Portal expand the available services just created and copy the `PORT` of the `litmusportal-frontend-service` service
+
+```bash
+kubectl get svc -n
+```
+
+Expected Output
+
+```bash
+NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
+chaos-litmus-portal-mongo ClusterIP 10.104.107.117 27017/TCP 2m
+litmusportal-frontend-service NodePort 10.101.81.70 9091:30385/TCP 2m
+litmusportal-server-service NodePort 10.108.151.79 9002:32456/TCP,9003:31160/TCP 2m
+```
+
+> **Note**: In this case, the PORT for `litmusportal-frontend-service` is `30385`. Yours will be different.
+
+## **With LoadBalancer**
+
+To setup and login to Litmus Portal with LoadBalancer, patch the Frontend Service `litmusportal-frontend-service` and expose the External IP.
+
+```bash
+kubectl patch svc litmusportal-frontend-service -p '{"spec": {"type": "LoadBalancer"}}' -n
+```
+
+Expected Output
+
+```bash
+NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
+chaos-litmus-portal-mongo ClusterIP 10.104.107.117 27017/TCP 2m
+litmusportal-frontend-service NodePort 10.101.81.70 9091:30385/TCP 2m
+litmusportal-server-service NodePort 10.108.151.79 9002:32456/TCP,9003:31160/TCP 2m
+```
+
+## **Accessing the ChaosCenter**
+
+Once you have the PORT copied in your clipboard, simply use your IP and PORT in this manner `:` to access the Litmus ChaosCenter.
+
+For example:
+
+```yaml
+http://172.17.0.3:30385/
+```
+
+> Where `172.17.0.3` is my NodeIP and `30385` is the frontend service PORT. If using a LoadBalancer, the only change would be to provide a `:`
+
+You should be able to see the Login Page of Litmus ChaosCenter. The **default credentials** are
+
+```yaml
+Username: admin
+Password: litmus
+```
+
+
+
+By default you are assigned with a default project with Owner permissions.
+
+
+
+## Learn more
+
+- [Setup Endpoints and Access ChaosCenter with Ingress](setup-with-ingress.md)
+- [Install ChaosCenter in Namespace Scope](chaoscenter-namespace-scope-installation.md)
+- [Install ChaosCenter in Cluster Scope](chaoscenter-cluster-scope-installation.md)
diff --git a/website/versioned_docs/version-2.13.0/user-guides/share-app-dashboard.md b/website/versioned_docs/version-2.13.0/user-guides/share-app-dashboard.md
new file mode 100644
index 0000000..f718be1
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/user-guides/share-app-dashboard.md
@@ -0,0 +1,19 @@
+---
+id: share-app-dashboard
+title: Sharing Application Dashboards
+sidebar_label: Sharing Application Dashboards
+---
+
+---
+
+## Uploading and downloading a dashboard
+
+- **Upload the JSON:** During the dashboard creation process, you can upload your JSON file having all the configurations of the dashboard. To read about the configurations and format of the JSON file for the application dashboard [click here](../concepts/app-infra-monitoring.md). To learn more about the schema of the dashboard JSON [click here](https://raw.githubusercontent.com/litmuschaos/litmus/master/monitoring/portal-dashboards/schema.json).
+- **Changing configuration step remains the same:** After uploading the JSON file you can make changes in the configuration of the dashboard same. The steps for changing the configuration and tuning the queries remain the same as for pre-defined dashboards. To learn about dashboard configuration and tuning the queries [click here](editing-queries-app-dashboard.md).
+- **Downloading a dashboard:** To download the dashboard, go to the Application dashboard tab, click on the more options for the particular dashboard from the Table and download the JSON file for the dashboard
+
+To learn more about the dashboard and view examples [click here](https://github.com/litmuschaos/chaos-charts/tree/master/monitoring/dashboards/litmus-portal)
+
+## Learn more
+
+- [Manage Application Dashboard](manage-app-dashboard.md)
diff --git a/website/versioned_docs/version-2.13.0/user-guides/uninstall-litmus.md b/website/versioned_docs/version-2.13.0/user-guides/uninstall-litmus.md
new file mode 100644
index 0000000..11fc308
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/user-guides/uninstall-litmus.md
@@ -0,0 +1,129 @@
+---
+id: uninstall-litmus
+title: Uninstalling Litmus
+sidebar_label: Uninstall Litmus
+---
+
+---
+
+## Chaos Delegate
+
+To disconnect the [Chaos Delegate](../getting-started/resources.md#chaosagents) connected to the [ChaosCenter](../getting-started/resources.md#chaoscenter), follow these steps -
+
+1. Remove the ChaosEngines of the respective Chaos Delegate
+
+ ```bash
+ kubectl delete chaosengine --all -
+ ```
+
+ > If ChaosEngines is unable to delete successfully then the Kubernetes finalizers need to be removed manually.
+
+2. Login to the ChaosCenter and navigate to the Chaos Delegates Tab.
+3. Click on the `Disconnect icon` of the respective Chaos Delegate you want to disconnect.
+4. On the Modal that appears, confirm your selection by clicking `Yes` and the selected Chaos Delegate would be disconnected from the ChaosCenter.
+ :::note
+ The above disconnect would remove the subscriber component from Chaos Delegate and thus removing the connectivity between the Chaos Delegate and the ChaosCenter.
+
+ If the Chaos Delegate is not reachable it would remove only the entry from the database of the ChaosCenter
+ :::
+
+### Remove the CRs
+
+To remove the CRs Litmus uses, use the following command:
+
+- To remove individual CRs
+
+```bash
+kubectl delete chaosexperiments -n
+kubectl delete chaosresults -n
+kubectl delete workflows -n
+kubectl delete cronworkflows -n
+kubectl delete eventtrackerpolicies -n
+```
+
+- To remove all CRs
+
+```bash
+kubectl delete chaosengine,chaosexperiments,chaosresults --all
+kubectl delete workflows cronworflows --all
+kubectl delete eventtrackerpolicies -n
+```
+
+### Delete the Deployments
+
+To remove the respective deployments of the Chaos Delegates you need to manually delete them.
+
+```bash
+kubectl delete deployment chaos-operator-ce event-tracker workflow-controller chaos-exporter -n
+```
+
+### Removing Service Account, Role Bindings and Roles
+
+#### For Cluster Scope
+
+```bash
+kubectl delete sa argo argo-chaos litmus-admin litmus-cluster-scope event-tracker-sa -n -
+kubectl delete clusterrolebindings argo-binding chaos-cluster-role-binding event-tracker-clusterole-binding litmus-admin litmus-cluster-scope subscriber-cluster-role-binding
+kubectl delete clusterrole litmus-admin chaos-cluster-role subscriber-cluster-role event-tracker-cluster-role litmus-cluster-scope argo-aggregate-to-admin argo-aggregate-to-edit argo-aggregate-to-view argo-cluster-role
+```
+
+#### For Namespace Scope
+
+```bash
+kubectl delete sa rolebindings role --all -n
+```
+
+---
+
+## Remove the Litmus CRDs
+
+:::note
+If the Litmus CRDs are deleted in the Cluster Scope all the respective custom resources in the individual namespaces would stop working.
+:::
+
+To remove all the CRDs Litmus uses, use the following command:
+
+```bash
+kubectl delete -f https://raw.githubusercontent.com/litmuschaos/litmus/master/litmus-portal/manifests/litmus-portal-crds.yml
+```
+
+---
+
+## ChaosCenter
+
+> To remove the Self Chaos Delegate Resources you need to follow the above Chaos Delegate Uninstall process
+
+To uninstall the ChaosCenter from the system, follow these steps -
+
+### Using Kubectl
+
+#### For Cluster Scope
+
+- **Litmus 2.13.0**
+
+ ```bash
+ kubectl delete -f https://raw.githubusercontent.com/litmuschaos/litmus/2.13.0/docs/2.13.0/litmus-2.13.0.yaml
+ ```
+
+ > To delete any specific version of the ChaosCenter, replace the above command with the below command. `kubectl delete -f https://raw.githubusercontent.com/litmuschaos/litmus//mkdocs/docs/.yaml`
+
+- **Litmus Master Manifest**
+
+ ```bash
+ kubectl delete -f https://raw.githubusercontent.com/litmuschaos/litmus/master/litmus-portal/manifests/cluster-k8s-manifest.yml
+ ```
+
+#### For Namespace Scope
+
+```bash
+kubectl delete -f ${LITMUS_PORTAL_NAMESPACE}-ns-scoped-litmus-portal-manifest.yml -n ${LITMUS_PORTAL_NAMESPACE}
+```
+
+### Using Helm
+
+```bash
+helm uninstall litmuschaos --namespace litmus
+kubectl delete ns litmus
+```
+
+> The namespace doesn't have to be `litmus` necessarily, instead it should be the same namespace where Litmus ChaosCenter is installed.
diff --git a/website/versioned_docs/version-2.13.0/user-guides/upgrade.md b/website/versioned_docs/version-2.13.0/user-guides/upgrade.md
new file mode 100644
index 0000000..8ab96b4
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/user-guides/upgrade.md
@@ -0,0 +1,44 @@
+---
+id: upgrade
+title: Upgrade Litmus ChaosCenter to Latest Version
+sidebar_label: Upgrade
+---
+
+---
+
+## Upgrade ChaosCenter
+
+To upgrade Litmus ChaosCenter from 2.12.0 to 2.13.0, you can follow these steps:
+
+> Note: This step is not required if using Helm, Helm upgrade should work.
+
+1. Upgrade the control plane (ChaosCenter)
+ To upgrade ChaosCenter, you can re-apply the manifest using the kubectl.
+
+ ```bash
+ kubectl apply -f https://raw.githubusercontent.com/litmuschaos/litmus/master/mkdocs/docs/2.13.0/litmus-2.13.0.yaml
+ ```
+
+## Upgrade Mongodb DB Schema
+
+> Note: This step is not required if using Helm, Helm upgrade should work.
+
+To upgrade the DB schema, deploy the [upgrade-agent](https://raw.githubusercontent.com/litmuschaos/litmus/master/litmus-portal/upgrade-agents/control-plane/upgrade-agent.yaml) in your k8s cluster where ChaosCenter is installed. This manifest will create a Job, which will upgrade the mongoDB schema.
+
+`kubectl apply -f https://raw.githubusercontent.com/litmuschaos/litmus/master/litmus-portal/upgrade-agents/control-plane/upgrade-agent.yaml`
+
+## Upgrade Chaos Delegate
+
+To upgrade your Chaos Delegate, you can follow these steps:
+
+1. If an upgrade is available, you will get an option to upgrade your chaos delegate in the ChaosCenter. Upon clicking on the upgrade option, a modal will pop up providing you the litmusctl command which you can execute and your Chaos Delegate will be upgraded.
+
+
+
+Alternatively you can run the following command using litmusctl in the cluster containing the chaos delegate by providing `` and ``.
+
+```
+litmusctl upgrade agent --cluster-id="" --project-id=""
+```
+
+> Note: v0.7.0 of [litmusctl](https://github.com/litmuschaos/litmusctl/blob/master/README.md) is required.
diff --git a/website/versioned_docs/version-2.13.0/user-guides/view-chaos-impact.md b/website/versioned_docs/version-2.13.0/user-guides/view-chaos-impact.md
new file mode 100644
index 0000000..425cb3b
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/user-guides/view-chaos-impact.md
@@ -0,0 +1,88 @@
+---
+id: view-chaos-impact
+title: Viewing Chaos Impact on Applications Metrics Across Chaos Delegate βs Scope
+sidebar_label: Viewing Chaos Impact
+---
+
+---
+
+After creating a dashboard, you view the corresponding metrics along with the chaos events in order to understand the impact of the chaos on various applicatons.
+
+
+
+Viewing particular application dashboard
+
+
+## Dashboard Navigation
+
+- **Dashboard Info:** All the dashboard meta-data (name, type, data source, chaos delegate ), selected applications and selected panels are displayed in this selection. To check on the data source connected with the dashboard click on the attached data source link. You may select/deselect the items listed in the selected applications and selected panels field to visualize the appropriate data.
+
+
+
+Viewing the information related to the dashboard
+
+
+
+
+Viewing more options
+
+
+- **More Options:**
+
+ - Configure: To make changes in the metadata and/or fine-tune the queries. To learn about configuring a dashboard [click here.](manage-app-dashboard.md)
+ - Clone: To make a copy of the current dashboard click on the clone button. Enter new name of the dashboard and click on `ok`
+
+ - Download a JSON: To download the complete dashboard configuration in JSON format.
+
+ - PDF report: For downloading all the metric data in report format with graphs and summary. This feature is under development and will be made available in an upcoming version.
+
+
+
+Creating a copy of the dashboard
+
+
+- **Select a time interval:** To visualize the metric data for a specific period, you may select the date and time for the start and end of the interval.
+
+- **Refresh rate:** As the metrics data for a given data source is updated so to query and update all the graphs on the dashboard you may provide a refresh rate. By default, the refresh rate is set at 15 seconds.
+
+
+
+Setting up refersh rate for the dashboard
+
+
+- **Hard Refresh:** To perform a refresh explicitly a hard refresh option is given to the user.
+
+- **View chaos metric info:** For the particular graph, if you want to view the chaos scenario -related information in the table then you may first expand the graph and hover over the specific chaos event to view all its chaos scenario -related information.
+
+- **Popout:** To open the particular graph in a modal.
+
+
+
+View individulal graph in modal
+
+
+- **Edit particular panel:** To edit the queries for the specific panel. On clicking on the `Edit` button you will be directed to the dashboard configuration page where you can tune the queries. To learn more about query editing [click here](editing-queries-app-dashboard.md).
+
+- **Show chaos during this interval:** Among all the chaos injections that have been scheduled by the user, chaos events that lie within the selected time interval are listed in form of a table. You may select/deselect the specific chaos events to visualize them on the graphs as an overlay for the chaos during. Please note that all the chaos events come along with the lasted verdict corresponding to the chaos scenario .
+
+
+
+Selecting/deselecting chaos metric
+
+
+- Edit: Click to edit the chaos annotations.
+ - Event query: Queries related to the chaos injection events. You may edit them as per your requirement.
+ - Verdict query: Query related to the verdict/results of the chaos injection. You may edit them as per your requirement.
+
+
+
+Editing chaos metric queries
+
+
+- **Switch between dashboards for the same chaos delegate :** You can switch between the dashboards for the selected chaos delegate . To view a different dashboard for the given chaos delegate , click the dropdown option placed next to the dashboard name which contains the list of all the configured dashboards for that chaos delegate and select a particular dashbord.
+
+## Learn more
+
+- [Manage Application Dashboard](manage-app-dashboard.md)
+- [Editing Panel Queries](editing-queries-app-dashboard.md)
+- [Sharing Application Dashboards](share-app-dashboard.md)
diff --git a/website/versioned_docs/version-2.13.0/user-guides/view-user.md b/website/versioned_docs/version-2.13.0/user-guides/view-user.md
new file mode 100644
index 0000000..5de74ee
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/user-guides/view-user.md
@@ -0,0 +1,21 @@
+---
+id: view-user
+title: View all users
+sidebar_label: View users
+---
+
+---
+
+> In the `/settings` route (settings on the sidebar) the `User Management` tab can be used to access the user management feature by the admin. We recommend learning about the concept of [user management](../concepts/user-management.md) before proceeding with the following user guides.
+
+## View users
+
+The admin can access the user management tab to check the list of all users present in the portal.
+
+
+
+## Learn more
+
+- [Create a user](create-user.md)
+- [Reset the password of a user](reset-password.md)
+- [Deactivate a user](deactivate-user.md)
diff --git a/website/versioned_sidebars/version-2.13.0-sidebars.json b/website/versioned_sidebars/version-2.13.0-sidebars.json
new file mode 100644
index 0000000..8624610
--- /dev/null
+++ b/website/versioned_sidebars/version-2.13.0-sidebars.json
@@ -0,0 +1,160 @@
+{
+ "docs": [
+ {
+ "Introduction": [
+ "introduction/what-is-litmus",
+ "introduction/features",
+ "introduction/usage",
+ "introduction/core-principles",
+ "introduction/community",
+ "introduction/other-links"
+ ]
+ },
+ {
+ "Getting Started": [
+ "getting-started/resources",
+ "getting-started/installation",
+ "getting-started/run-your-first-workflow"
+ ]
+ },
+ {
+ "Architecture": [
+ "architecture/overview",
+ "architecture/architecture-summary",
+ "architecture/chaos-control-plane",
+ "architecture/chaos-execution-plane",
+ "architecture/chaos-experiment-flow",
+ {
+ "Chaos Observability Flow": [
+ "architecture/chaos-observability-flow-overview",
+ "architecture/chaos-observability-flow-visualization",
+ "architecture/chaos-observability-flow-logging",
+ "architecture/chaos-observability-flow-monitoring",
+ "architecture/chaos-observability-flow-summarisation",
+ "architecture/chaos-observability-flow-analytics"
+ ]
+ }
+ ]
+ },
+ {
+ "Concepts": [
+ "concepts/overview",
+ "concepts/chaos-experiment",
+ "concepts/probes",
+ "concepts/chaos-engine",
+ "concepts/chaos-result",
+ "concepts/chaoshub",
+ {
+ "Chaos Scenario": [
+ "concepts/chaos-workflow",
+ "concepts/visualize-workflow"
+ ]
+ },
+ {
+ "Observability": [
+ "concepts/workflow-statistics",
+ "concepts/app-infra-monitoring",
+ "concepts/datasource",
+ "concepts/open-observability"
+ ]
+ },
+ "concepts/user-management",
+ "concepts/projects",
+ "concepts/teaming",
+ "concepts/gitops",
+ "concepts/oauth-dex-concept"
+ ]
+ },
+ {
+ "User Guides": [
+ "user-guides/overview",
+ {
+ "Advanced Installation": [
+ {
+ "ChaosCenter": [
+ "user-guides/chaoscenter-oauth-dex-installation",
+ "user-guides/chaoscenter-cluster-scope-installation",
+ "user-guides/chaoscenter-namespace-scope-installation",
+ "user-guides/setup-without-ingress",
+ "user-guides/setup-with-ingress"
+ ]
+ },
+ "user-guides/chaosagents-installation"
+ ]
+ },
+ {
+ "Injecting Fault": [
+ "user-guides/schedule-workflow",
+ "user-guides/observe-workflow",
+ "user-guides/edit-schedule",
+ "user-guides/save-as-template",
+ "user-guides/download-workflow-manifest",
+ "user-guides/re-run-workflow",
+ "user-guides/delete-workflow",
+ "user-guides/construct-workflow"
+ ]
+ },
+ {
+ "Observing Chaos": [
+ "user-guides/observability-set-up",
+ "user-guides/analyze-workflow",
+ "user-guides/comparative-analysis",
+ "user-guides/setup-datasource",
+ "user-guides/configure-datasource",
+ "user-guides/manage-app-dashboard",
+ "user-guides/editing-queries-app-dashboard",
+ "user-guides/view-chaos-impact",
+ "user-guides/share-app-dashboard"
+ ]
+ },
+ "user-guides/account-settings",
+ {
+ "User Management": [
+ "user-guides/create-user",
+ "user-guides/view-user",
+ "user-guides/reset-password",
+ "user-guides/deactivate-user"
+ ]
+ },
+ {
+ "Managing Projects": [
+ "user-guides/change-project-name",
+ "user-guides/leave-project"
+ ]
+ },
+ {
+ "Teaming": [
+ "user-guides/invite-team-member",
+ "user-guides/edit-invite",
+ "user-guides/accept-invite",
+ "user-guides/remove-team-member"
+ ]
+ },
+ "user-guides/gitops-configuration",
+ "user-guides/image-registry",
+ "user-guides/uninstall-litmus",
+ "user-guides/upgrade"
+ ]
+ },
+ {
+ "Litmusctl": [
+ "litmusctl/installation",
+ {
+ "Connect Agent": [
+ "litmusctl/usage-non-interactive-mode",
+ "litmusctl/usage-interactive-mode"
+ ]
+ },
+ "litmusctl/chaos-workflow-creation"
+ ]
+ },
+ {
+ "Integrations": [
+ "integrations/prometheus",
+ "integrations/grafana"
+ ]
+ },
+ "troubleshooting",
+ "faq"
+ ]
+}
diff --git a/website/versions.json b/website/versions.json
index d5cb1f3..47798ae 100644
--- a/website/versions.json
+++ b/website/versions.json
@@ -1,4 +1,5 @@
[
+ "2.13.0",
"2.12.0",
"2.11.0",
"2.10.0",
![Architecture Overview]({require("../assets/architecture-summary.png").default})
+
+The Litmus architecture can be segregated into two parts:
+
+1. **Control Plane:** Contains the components required for the functioning of Chaos Center, the website-based portal for Litmus.
+
+2. **Execution Plane:** Contains the components required for the injection of chaos in the target resources.
+
+Chaos Center can be used for creating, scheduling, and monitoring Chaos Scenarios, a set of chaos experiments defined in a definitive sequence to achieve desired chaos impact on the target resources upon execution. Users can log in to the Chaos Center using valid login credentials and leverage the interactive web UI to define their chaos scenario to target multiple aspects of their infrastructure. Once the user creates a Chaos Scenario using the Chaos Center, 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 delegate is being used, or in the target cluster if an external chaos delegate is being used. The Execution Plane interprets the Chaos Scenario 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 Scenario 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 Scenario runs to execute chaos as part of the CI/CD pipeline based on a set of defined conditions using GitOps.
diff --git a/website/versioned_docs/version-2.13.0/architecture/chaos-control-plane.md b/website/versioned_docs/version-2.13.0/architecture/chaos-control-plane.md
new file mode 100644
index 0000000..5a83e0b
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/architecture/chaos-control-plane.md
@@ -0,0 +1,40 @@
+---
+id: chaos-control-plane
+title: Chaos Control Plane
+sidebar_label: Chaos Control Plane
+---
+
+---
+
+![Chaos Control Plane]({require("../assets/chaos-control-plane.png").default})
+
+Chaos Control Plane consists of micro-services responsible for the functioning of the Chaos Center, the website-based portal that can be used for interacting with Litmus, apart from the CLI. Chaos Plane facilitates the creation and scheduling of chaos scenarios, system observability during the event of chaos, and post-processing and analysis of experiment results.
+
+## Chaos Control Plane Components
+
+- **Authentication Server:** A Golang micro-service that is responsible for authorizing, authenticating the requests received from Chaos Center 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.
+
+- **Backend Server:** A GraphQL based Golang micro-service that serves the requests received from Chaos Center, by either querying the database for the relevant information or by fetching information from the Execution Plane.
+
+- **Database:** A NoSQL MongoDB database micro-service that is accountable for storing users' information, past chaos scenarios, saved chaos scenario templates, user projects, ChaosHubs, and GitOps details, among the other information.
+
+- **Chaos Center:** Refers to the interfaces used by Litmus for creation and scheduling of chaos scenarios, system observability during chaos injection, and post chaos result analysis. It includes:
+
+ - **Web UI:** A React.js based frontend application micro-service with built-in system observability capabilities and an analytics dashboard. It also facilitates teams of users to collaborate over chaos scenarios using role-based user accounts.
+
+ - **Litmusctl:** A command-line tool that allows management of Litmus Chaos Delegate Infrastructure components. It can be used to create chaos delegates, project, and manage multiple Litmus accounts.
+
+ - **Litmus API:** Refers to two different Litmus APIs, namely Litmus Authentication API and Litmus Portal API:
+
+ - **Litmus Authentication API:** Used to authenticate the identity of a user and to perform several user and project specific tasks like create new users, update profile, update password, create project, invite users to project, get project details etc. It uses the Authentication Server to perform these tasks.
+
+ - **Litmus Portal API:** Provides command-line and UI experience for managing and monitoring the events around chaos scenarios. It uses the Backend Server to perform its functions.
+
+## Standard Chaos Control Plane Flow
+
+1. The User logs in to the ChaosCenter using a valid login credential. A default project is created for the user on initial login. Every user is a part of a project and has a role assigned to them. To schedule a chaos scenario, the user needs to have an Editor or Owner role assigned in the project.
+2. The user uploads a Chaos Scenario manifest using the ChaosCenter, which is received by the Backend Server.
+3. Backend Server stores the manifest in the Database and also sends it to the Chaos Delegate.
+4. Chaos Delegate uses the Chaos Scenario manifest to inject chaos into the target resources. The steps of the Chaos Scenario execution can be visualized using the ChaosCenter.
+5. Chaos Delegate returns the results of the chaos experiments that were a part of the chaos scenario back to the Backend Server, along with the experiment logs.
+6. Backend Server then sends the chaos experiment results and logs to the ChaosCenter. It also stores the results into the Database for generating post-chaos scenario statistics and information.
diff --git a/website/versioned_docs/version-2.13.0/architecture/chaos-execution-plane.md b/website/versioned_docs/version-2.13.0/architecture/chaos-execution-plane.md
new file mode 100644
index 0000000..4b8a888
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/architecture/chaos-execution-plane.md
@@ -0,0 +1,64 @@
+---
+id: chaos-execution-plane
+title: Chaos Execution Plane
+sidebar_label: Chaos Execution Plane
+---
+
+---
+
+![Chaos Execution Plane]({require("../assets/chaos-execution-plane.png").default})
+
+Chaos Execution Plane contains the components responsible for orchestrating the chaos injection in the target resources. They get installed in either an external target cluster if an external chaos delegate is being used or in the host cluster containing the control plane if a self chaos delegate is being used. It can be further segregated into Litmus Chaos Delegate Infrastructure components and Litmus Backend Execution Infrastructure components.
+
+## Litmus Execution Plane Components
+
+Litmus Chaos Delegate Infrastructure components help facilitate the chaos injection, manage chaos observability, and enable chaos automation for target resources. These components include:
+
+1. **Workflow Controller:** The Argo Workflow Controller responsible for the creation of Chaos Scenarios using the Chaos Scenario CR.
+
+2. **Subscriber:** Serves as the link between the Chaos Execution Plane and the Control Plane. It has a few distinct responsibilities such as performing health check of all the components in Chaos Execution Plane, creation of a Chaos Scenario CR from a Chaos Scenario template, watching for Chaos Scenario events during its execution, and sending the chaos scenario result to the Control Plane.
+
+3. **Event Tracker:** An optional component that is capable of triggering automated chaos scenario runs based on a set of defined conditions for any given resources in the cluster. It is a controller that manages EventTrackerPolicy CR, which is basically the set of defined conditions that is validated by Event Tracker. If the current state of the tracked resources match with the state defined in the EventTrackerPolicy CR, the chaos scenario run run gets triggered. This feature can only be used if GitOps is enabled.
+
+4. **Chaos Exporter:** An optional component that facilitates external observability in Litmus by exporting the chaos metrics generated during the chaos injection as time-series data to the Prometheus DB for its processing and analysis.
+
+Litmus Backend Execution Infrastructure components orchestrate the execution of Chaos Scenario in target resources. These components include:
+
+1. **Chaos Scenario CR:** Refers to the Argo Workflow CR which describes the steps that are executed as a part of the chaos scenario. It is used to define failures during a certain workload condition (such as, say, percentage load), multiple (parallel) failures of dependent and independent services etc.
+
+2. **ChaosExperiment CR:** Used for defining the low-level execution information for any Litmus chaos experiment as well as to store the various experiment tunables.
+
+3. **ChaosEngine CR:** Used to hold information about how the chaos experiments are executed. It connects an application instance with one or more chaos experiments while allowing the users to specify run-level details.
+
+4. **Chaos Operator:** A Kubernetes custom-controller that manages the lifecycle of certain resources or applications intending to validate their "desired state". It helps reconcile the state of the ChaosEngine by performing specific actions upon CRUD of the ChaosEngine. It also defines a secondary resource (the ChaosEngine Runner pod), which is created & managed by it to implement the reconcile functions.
+
+![Chaos Operator]({require("../assets/chaos-execution-plane-chaos-operator.png").default})
+![Chaos Runner]({require("../assets/chaos-execution-plane-chaos-runner.png").default})
+![Chaos Experiment Flow]({require("../assets/experiment-flow.png").default})
+
+The experiment execution is triggered upon the creation of a ChaosEngine resource. The ChaosEngine resource interacts with Chaos Runner, which is created by the Chaos Operator. The Chaos Runner creates Experiment Jobs that execute the experiment business logic. Typically, these ChaosEngines are embedded within the 'steps' of a Litmus Chaos Scenario. However, one may also create and apply the Chaos Engines manually, and then the chaos-operator reconciles this resource and triggers the experiment execution. Chaos experiments are classified as:
+
+- Kubernetes Experiments
+ - Pod-Level Chaos
+ - Node-Level Chaos
+- Application Chaos
+- Cloud Infrastructure
+
+## Chaos Experiment Flow Steps
+
+1. Chaos experiment execution gets triggered by the Experiment Job.
+2. Experiment tunables and low-level execution details are fetched.
+3. ChaosResult gets initialized and its verdict is updated as "Awaited" to indicate that the experiment is currently running.
+4. Steady-state condition for the respective experiment is validated. If the condition is found to be invalid, the experiment execution is stopped and the ChaosResult is updated as "Fail".
+5. Once the steady-state condition is validated, experiment resources are created to facilitate the chaos injection.
+6. Chaos injection is performed on the target resources for the specified chaos duration.
+7. Chaos injection gets reverted.
+8. Post chaos status-check is performed to ensure that the steady-state is still maintained.
+9. If the check is invalid, the ChaosEngine and ChaosResult verdicts are updated as "Fail", otherwise they are updated as "Pass".
+10. Experiment execution ends.
diff --git a/website/versioned_docs/version-2.13.0/architecture/chaos-observability-flow-analytics.md b/website/versioned_docs/version-2.13.0/architecture/chaos-observability-flow-analytics.md
new file mode 100644
index 0000000..82ce547
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/architecture/chaos-observability-flow-analytics.md
@@ -0,0 +1,23 @@
+---
+id: chaos-observability-flow-analytics
+title: Analytics
+sidebar_label: Analytics
+---
+
+---
+
+![Chaos Observability Flow Analytics]({require("../assets/chaos-observability-flow-analytics.png").default})
+
+Analytics is an integral part of Chaos Engineering, as it offers key insights that are required to fully understand a system during the chaos and functions as a decision-making tool for improving system resiliency.
+
+In Litmus, chaos scenario run statistics and information are generated post the chaos scenario execution, which can be accessed directly using the ChaosCenter.
+
+## Observability Flow for Analytics
+
+1. In the Chaos Execution Plane, the ChaosEngine Details and ChaosResult are fetched by the Chaos Delegate.
+2. Chaos Delegate then forwards them to the Backend Server in the Chaos Control Plane and later they get stored into the Database.
+3. User specifies the Chaos Scenario Schedule for which the Chaos Scenario statistics and information is to be fetched as an input in the ChaosCenter.
+4. The request for the Chaos Scenario statistics and information is received by the Backend Server.
+5. Backend Server queries the Database for the details of past Chaos Scenario Runs.
+6. Aggregated Chaos Scenario statistics based on the ChaosResult verdict and probe success percentage are fetched from the Database by Backend Server.
+7. Chaos Scenario statistics and information are forwarded to ChaosCenter by Backend Server.
diff --git a/website/versioned_docs/version-2.13.0/architecture/chaos-observability-flow-logging.md b/website/versioned_docs/version-2.13.0/architecture/chaos-observability-flow-logging.md
new file mode 100644
index 0000000..ffc57fe
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/architecture/chaos-observability-flow-logging.md
@@ -0,0 +1,23 @@
+---
+id: chaos-observability-flow-logging
+title: Logging
+sidebar_label: Logging
+---
+
+---
+
+![Chaos Observability Flow Logging]({require("../assets/chaos-observability-flow-logging.png").default})
+
+Logging is a pivotal observability aspect in LitmusChaos as it allows the user to track the exact system behavior during the scenario of a chaos. The logs can be classified into one of the following:
+
+- **Litmus Checker Logs:** Logs generated as part of the validation for chaos resources that are required to execute a chaos experiment.
+- **Experiment Logs:** Logs generated as part of the steps performed during the chaos experiment, including pre-chaos check logs, chaos injection logs, chaos probes logs, and post-chaos check logs.
+- **Non-Chaos Scenario Step Logs:** Logs generated as part of the chaos scenario steps that facilitate the execution of the chaos experiment, such as chaos experiment installation step logs, chaos revert step logs, etc.
+
+## Observability Flow for Logging
+
+1. User requests the logs for any particular chaos scenario step using the ChaosCenter.
+2. The request for the logs is received by the Backend Server and is forwarded to the Subscriber.
+3. The subscriber checks if the chaos scenario step is a Chaos Experiment step or not.
+4. If the chaos scenario step is a Chaos Experiment step, then the Litmus Checker logs and the Chaos Experiment Logs are fetched from the ChaosEngine CR by the subscriber. Else, the logs of the chaos scenario step pod is fetched from the respective chaos scenario step pod by the subscriber.
+5. The fetched logs are returned to the Backend Server, which returns them to the ChaosCenter.
diff --git a/website/versioned_docs/version-2.13.0/architecture/chaos-observability-flow-monitoring.md b/website/versioned_docs/version-2.13.0/architecture/chaos-observability-flow-monitoring.md
new file mode 100644
index 0000000..968a44a
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/architecture/chaos-observability-flow-monitoring.md
@@ -0,0 +1,38 @@
+---
+id: chaos-observability-flow-monitoring
+title: Monitoring
+sidebar_label: Monitoring
+---
+
+---
+
+Monitoring is a key part to effectively watch and understand the state of the systems. In Litmus, the monitoring is split into a two-fold approach:
+- Metrics Monitoring
+- Events Monitoring
+
+## Metrics Monitoring
+
+![Chaos Observability Flow Metrics]({require("../assets/chaos-observability-flow-metrics.png").default})
+![Chaos Observability Flow Events]({require("../assets/chaos-observability-flow-events.png").default})
+![Chaos Observability Flow Summarisation]({require("../assets/chaos-observability-flow-summarisation.png").default})
+
+Summarisation is the process of aggregating the information pertaining to a Chaos Experiment's execution over time.
+
+In Litmus, summarisation is performed using the ChaosResult CR. It stores all the information relevant to a ChaosExperiment's execution over time, including events, experiment verdict, probe success percentage, target resource details, etc.
+
+## Observability Flow for Summarisation
+
+1. In the Chaos Execution Plane, the ChaosEngine Details and Chaos Result are fetched by the Chaos Delegate.
+2. Chaos Delegate then forwards them to the Backend Server in the Chaos Control Plane and later they get stored into the Database.
+3. When a user requests for the ChaosResult for a particular Chaos Experiment using the ChaosCenter, the request is received by the Backend Server.
+4. Backend Server queries the Database for the particular ChaosResult for the input Chaos Experiment.
+5. The ChaosResult is fetched from the Database by the Backend Server.
+6. ChaosResult is forwarded to the ChaosCenter.
diff --git a/website/versioned_docs/version-2.13.0/architecture/chaos-observability-flow-visualization.md b/website/versioned_docs/version-2.13.0/architecture/chaos-observability-flow-visualization.md
new file mode 100644
index 0000000..d9a1782
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/architecture/chaos-observability-flow-visualization.md
@@ -0,0 +1,15 @@
+---
+id: chaos-observability-flow-visualization
+title: Visualization
+sidebar_label: Visualization
+---
+
+---
+
+![Chaos Observability Flow Visualisation]({require("../assets/argo-graph.png").default})
+
+Chaos scenario visualization constitutes an integral part of the system observability during chaos in Litmus.
+
+- It is a visual representation of the steps performed as part of the Chaos Scenario CR execution.
+- Every step is represented as a node, which also depicts the status of the respective node that it represents.
+- All the nodes are connected in a sequential order to account for the order of execution of the respective steps.
diff --git a/website/versioned_docs/version-2.13.0/architecture/overview.md b/website/versioned_docs/version-2.13.0/architecture/overview.md
new file mode 100644
index 0000000..adfd6b6
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/architecture/overview.md
@@ -0,0 +1,29 @@
+---
+id: overview
+title: Overview
+sidebar_label: Overview
+---
+
+---
+
+The Architecture section contains the component overview, sequence diagrams and description of flow of information through the Litmus architecture.
+
+### [Architecture Summary](architecture-summary.md)
+
+A very high level overview of the entire Litmus architecture with the objective of highlighting the flow of information through the various components.
+
+### [Control Plane](chaos-control-plane.md)
+
+Consists of micro-services responsible for the functioning of the ChaosCenter, the web based portal used for creating, scheduling, and monitoring chaos scenarios.
+
+### [Execution Plane](chaos-execution-plane.md)
+
+Contains the components required for the orchestration of chaos injection in the target resources.
+
+### [Chaos Experiment Flow](chaos-experiment-flow.md)
+
+Flow of information during the execution of Litmus chaos experiments, grouped into the categories such as pod-level, node-level, application-level, and public-cloud.
+
+### [Chaos Observability Flow](chaos-observability-flow-overview.md)
+
+Information flow for monitoring and observability during and post chaos using built-in Litmus analytics dashboard as well as external observability tools.
diff --git a/website/versioned_docs/version-2.13.0/assets/architecture-summary.png b/website/versioned_docs/version-2.13.0/assets/architecture-summary.png
new file mode 100644
index 0000000..5093488
Binary files /dev/null and b/website/versioned_docs/version-2.13.0/assets/architecture-summary.png differ
diff --git a/website/versioned_docs/version-2.13.0/assets/architecture.png b/website/versioned_docs/version-2.13.0/assets/architecture.png
new file mode 100644
index 0000000..736a2b0
Binary files /dev/null and b/website/versioned_docs/version-2.13.0/assets/architecture.png differ
diff --git a/website/versioned_docs/version-2.13.0/assets/argo-chaos-workflow.png b/website/versioned_docs/version-2.13.0/assets/argo-chaos-workflow.png
new file mode 100644
index 0000000..cdb412b
Binary files /dev/null and b/website/versioned_docs/version-2.13.0/assets/argo-chaos-workflow.png differ
diff --git a/website/versioned_docs/version-2.13.0/assets/argo-graph.png b/website/versioned_docs/version-2.13.0/assets/argo-graph.png
new file mode 100644
index 0000000..58bb299
Binary files /dev/null and b/website/versioned_docs/version-2.13.0/assets/argo-graph.png differ
diff --git a/website/versioned_docs/version-2.13.0/assets/arrow.png b/website/versioned_docs/version-2.13.0/assets/arrow.png
new file mode 100644
index 0000000..89f1b06
Binary files /dev/null and b/website/versioned_docs/version-2.13.0/assets/arrow.png differ
diff --git a/website/versioned_docs/version-2.13.0/assets/chaos-center-analytics.pdf b/website/versioned_docs/version-2.13.0/assets/chaos-center-analytics.pdf
new file mode 100644
index 0000000..999b477
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/assets/chaos-center-analytics.pdf
@@ -0,0 +1,1005 @@
+%PDF-1.3
+%Ίί¬ΰ
+3 0 obj
+<>
+endobj
+4 0 obj
+<<
+/Length 7581
+>>
+stream
+0.5670000000000001 w
+0 G
+1. g
+0. G
+BT
+/F1 10 Tf
+11.5 TL
+0. g
+28.3464566929133888 813.5435433070865656 Td
+(Litmus Portal Report Version: ci) Tj
+ET
+BT
+/F1 10 Tf
+11.5 TL
+0. g
+28.3464566929133888 799.3703149606299121 Td
+(Time of Generation:) Tj
+ET
+BT
+/F1 10 Tf
+11.5 TL
+0. g
+119.0551181102362364 799.3703149606299121 Td
+(Mon Aug 02 2021 17:52:36 GMT+0530 \(India Standard Time\)) Tj
+ET
+BT
+/F1 10 Tf
+11.5 TL
+0. g
+28.3464566929133888 785.1970866141732586 Td
+(Total Number of Chaos Workflow Schedules under consideration:) Tj
+ET
+BT
+/F1 10 Tf
+11.5 TL
+0. g
+323.1496062992126213 785.1970866141732586 Td
+(2) Tj
+ET
+BT
+/F1 10 Tf
+11.5 TL
+0. g
+28.3464566929133888 771.0238582677164914 Td
+(Total Number of Chaos Workflow Runs under consideration:) Tj
+ET
+BT
+/F1 10 Tf
+11.5 TL
+0. g
+297.6377952755905767 771.0238582677164914 Td
+(3) Tj
+ET
+q
+85.0393700787401627 0 0 35.4330708661417333 467.7165354330709306 778.1104724409448181 cm
+/I0 Do
+Q
+0. 748.346692913385823 m
+850.3937007874017127 748.346692913385823 l
+S
+14.1732283464566944 w
+BT
+/F1 10 Tf
+11.5 TL
+0. g
+77.9527559055118218 731.3388188976377933 Td
+(Workflow Run Details Table & Workflow Schedules Table with Resilience Score Comparison Graph) Tj
+ET
+0.96 0.96 1. rg
+0. G
+0.141732283464567 w
+5.6692913385826778 717.1655905511810261 53.4595121859613869 -67.5 re
+B
+BT
+/F10 10 Tf
+11.5 TL
+0. g
+10.6692913385826778 703.6655905511811397 Td
+(Cluster) Tj
+T* (Name) Tj
+ET
+0.96 0.96 1. rg
+0. G
+0.141732283464567 w
+59.1288035245440611 717.1655905511810261 160.2999999999999829 -67.5 re
+B
+BT
+/F10 10 Tf
+11.5 TL
+0. g
+64.1288035245440682 703.6655905511811397 Td
+(Workflow Name) Tj
+ET
+0.96 0.96 1. rg
+0. G
+0.141732283464567 w
+219.4288035245440369 717.1655905511810261 124.4543650889434474 -67.5 re
+B
+BT
+/F10 10 Tf
+11.5 TL
+0. g
+224.4288035245440369 703.6655905511811397 Td
+(Date-Time) Tj
+ET
+0.96 0.96 1. rg
+0. G
+0.141732283464567 w
+343.8831686134874985 717.1655905511810261 56.7182923192130062 -67.5 re
+B
+BT
+/F10 10 Tf
+11.5 TL
+0. g
+348.8831686134874985 703.6655905511811397 Td
+(#Expts.) Tj
+T* (Passed) Tj
+ET
+0.96 0.96 1. rg
+0. G
+0.141732283464567 w
+400.6014609327005473 717.1655905511810261 55.0113122494145443 -67.5 re
+B
+BT
+/F10 10 Tf
+11.5 TL
+0. g
+405.6014609327005473 703.6655905511811397 Td
+(#Expts.) Tj
+T* (Failed) Tj
+ET
+0.96 0.96 1. rg
+0. G
+0.141732283464567 w
+455.6127731821150633 717.1655905511810261 62.5375425571623609 -67.5 re
+B
+BT
+/F10 10 Tf
+11.5 TL
+0. g
+460.6127731821150633 703.6655905511811397 Td
+(Reliability) Tj
+T* (Score) Tj
+ET
+0.96 0.96 1. rg
+0. G
+0.141732283464567 w
+518.1503157392774028 717.1655905511810261 71.4603929220180447 -67.5 re
+B
+BT
+/F10 10 Tf
+11.5 TL
+0. g
+523.1503157392774028 703.6655905511811397 Td
+(Experiment) Tj
+T* (Details) Tj
+T* (Name) Tj
+T* (Weight /) Tj
+T* (Verdict) Tj
+ET
+0.96 0.96 1. rg
+0. G
+0.141732283464567 w
+5.6692913385826778 649.6655905511810261 53.4595121859613869 -44.4999999999999929 re
+B
+BT
+/F9 10 Tf
+11.5 TL
+0. g
+10.6692913385826778 636.1655905511810261 Td
+(shbd) Tj
+ET
+0.96 0.96 1. rg
+0. G
+0.141732283464567 w
+59.1288035245440611 649.6655905511810261 160.2999999999999829 -44.4999999999999929 re
+B
+BT
+/F9 10 Tf
+11.5 TL
+0. g
+64.1288035245440682 636.1655905511810261 Td
+(custom-chaos-workflow-1627897674) Tj
+ET
+0.96 0.96 1. rg
+0. G
+0.141732283464567 w
+219.4288035245440369 649.6655905511810261 124.4543650889434474 -44.4999999999999929 re
+B
+BT
+/F9 10 Tf
+11.5 TL
+0. g
+224.4288035245440369 636.1655905511810261 Td
+(Monday 02/08/2021) Tj
+T* (17:19:00 +05:30) Tj
+ET
+0.96 0.96 1. rg
+0. G
+0.141732283464567 w
+343.8831686134874985 649.6655905511810261 56.7182923192130062 -44.4999999999999929 re
+B
+BT
+/F9 10 Tf
+11.5 TL
+0. g
+348.8831686134874985 636.1655905511810261 Td
+(0) Tj
+ET
+0.96 0.96 1. rg
+0. G
+0.141732283464567 w
+400.6014609327005473 649.6655905511810261 55.0113122494145443 -44.4999999999999929 re
+B
+BT
+/F9 10 Tf
+11.5 TL
+0. g
+405.6014609327005473 636.1655905511810261 Td
+(1) Tj
+ET
+0.96 0.96 1. rg
+0. G
+0.141732283464567 w
+455.6127731821150633 649.6655905511810261 62.5375425571623609 -44.4999999999999929 re
+B
+BT
+/F9 10 Tf
+11.5 TL
+0. g
+460.6127731821150633 636.1655905511810261 Td
+(0.00%) Tj
+ET
+0.96 0.96 1. rg
+0. G
+0.141732283464567 w
+518.1503157392774028 649.6655905511810261 71.4603929220180447 -44.4999999999999929 re
+B
+BT
+/F9 10 Tf
+11.5 TL
+0. g
+523.1503157392774028 636.1655905511810261 Td
+(pod-delete) Tj
+T* (10 / Fail) Tj
+T* () Tj
+ET
+0.96 0.96 1. rg
+0. G
+0.141732283464567 w
+5.6692913385826778 605.1655905511810261 53.4595121859613869 -44.4999999999999929 re
+B
+BT
+/F9 10 Tf
+11.5 TL
+0. g
+10.6692913385826778 591.6655905511811397 Td
+(shbd) Tj
+ET
+0.96 0.96 1. rg
+0. G
+0.141732283464567 w
+59.1288035245440611 605.1655905511810261 160.2999999999999829 -44.4999999999999929 re
+B
+BT
+/F9 10 Tf
+11.5 TL
+0. g
+64.1288035245440682 591.6655905511811397 Td
+(custom-chaos-workflow-1627897674) Tj
+ET
+0.96 0.96 1. rg
+0. G
+0.141732283464567 w
+219.4288035245440369 605.1655905511810261 124.4543650889434474 -44.4999999999999929 re
+B
+BT
+/F9 10 Tf
+11.5 TL
+0. g
+224.4288035245440369 591.6655905511811397 Td
+(Monday 02/08/2021) Tj
+T* (16:19:00 +05:30) Tj
+ET
+0.96 0.96 1. rg
+0. G
+0.141732283464567 w
+343.8831686134874985 605.1655905511810261 56.7182923192130062 -44.4999999999999929 re
+B
+BT
+/F9 10 Tf
+11.5 TL
+0. g
+348.8831686134874985 591.6655905511811397 Td
+(0) Tj
+ET
+0.96 0.96 1. rg
+0. G
+0.141732283464567 w
+400.6014609327005473 605.1655905511810261 55.0113122494145443 -44.4999999999999929 re
+B
+BT
+/F9 10 Tf
+11.5 TL
+0. g
+405.6014609327005473 591.6655905511811397 Td
+(1) Tj
+ET
+0.96 0.96 1. rg
+0. G
+0.141732283464567 w
+455.6127731821150633 605.1655905511810261 62.5375425571623609 -44.4999999999999929 re
+B
+BT
+/F9 10 Tf
+11.5 TL
+0. g
+460.6127731821150633 591.6655905511811397 Td
+(0.00%) Tj
+ET
+0.96 0.96 1. rg
+0. G
+0.141732283464567 w
+518.1503157392774028 605.1655905511810261 71.4603929220180447 -44.4999999999999929 re
+B
+BT
+/F9 10 Tf
+11.5 TL
+0. g
+523.1503157392774028 591.6655905511811397 Td
+(pod-delete) Tj
+T* (10 / Fail) Tj
+T* () Tj
+ET
+0.96 0.96 1. rg
+0. G
+0.141732283464567 w
+5.6692913385826778 560.6655905511810261 53.4595121859613869 -44.4999999999999929 re
+B
+BT
+/F9 10 Tf
+11.5 TL
+0. g
+10.6692913385826778 547.1655905511811397 Td
+(shbd) Tj
+ET
+0.96 0.96 1. rg
+0. G
+0.141732283464567 w
+59.1288035245440611 560.6655905511810261 160.2999999999999829 -44.4999999999999929 re
+B
+BT
+/F9 10 Tf
+11.5 TL
+0. g
+64.1288035245440682 547.1655905511811397 Td
+(custom-chaos-workflow-1627897674) Tj
+ET
+0.96 0.96 1. rg
+0. G
+0.141732283464567 w
+219.4288035245440369 560.6655905511810261 124.4543650889434474 -44.4999999999999929 re
+B
+BT
+/F9 10 Tf
+11.5 TL
+0. g
+224.4288035245440369 547.1655905511811397 Td
+(Monday 02/08/2021) Tj
+T* (15:19:00 +05:30) Tj
+ET
+0.96 0.96 1. rg
+0. G
+0.141732283464567 w
+343.8831686134874985 560.6655905511810261 56.7182923192130062 -44.4999999999999929 re
+B
+BT
+/F9 10 Tf
+11.5 TL
+0. g
+348.8831686134874985 547.1655905511811397 Td
+(0) Tj
+ET
+0.96 0.96 1. rg
+0. G
+0.141732283464567 w
+400.6014609327005473 560.6655905511810261 55.0113122494145443 -44.4999999999999929 re
+B
+BT
+/F9 10 Tf
+11.5 TL
+0. g
+405.6014609327005473 547.1655905511811397 Td
+(1) Tj
+ET
+0.96 0.96 1. rg
+0. G
+0.141732283464567 w
+455.6127731821150633 560.6655905511810261 62.5375425571623609 -44.4999999999999929 re
+B
+BT
+/F9 10 Tf
+11.5 TL
+0. g
+460.6127731821150633 547.1655905511811397 Td
+(0.00%) Tj
+ET
+0.96 0.96 1. rg
+0. G
+0.141732283464567 w
+518.1503157392774028 560.6655905511810261 71.4603929220180447 -44.4999999999999929 re
+B
+BT
+/F9 10 Tf
+11.5 TL
+0. g
+523.1503157392774028 547.1655905511811397 Td
+(pod-delete) Tj
+T* (10 / Fail) Tj
+T* () Tj
+ET
+0. G
+0.141732283464567 w
+5.6692913385826778 717.1655905511810261 583.9414173228345817 -200.9999999999999716 re
+S
+endstream
+endobj
+5 0 obj
+<>
+endobj
+6 0 obj
+<<
+/Length 125
+>>
+stream
+0.5670000000000001 w
+0. G
+q
+583.9370078740157624 0 0 501.7474826370564642 5.6692913385826778 496.0480291739671657 cm
+/I1 Do
+Q
+endstream
+endobj
+1 0 obj
+<>
+endobj
+7 0 obj
+<<
+/Type /Font
+/BaseFont /Helvetica
+/Subtype /Type1
+/Encoding /WinAnsiEncoding
+/FirstChar 32
+/LastChar 255
+>>
+endobj
+8 0 obj
+<<
+/Type /Font
+/BaseFont /Helvetica-Bold
+/Subtype /Type1
+/Encoding /WinAnsiEncoding
+/FirstChar 32
+/LastChar 255
+>>
+endobj
+9 0 obj
+<<
+/Type /Font
+/BaseFont /Helvetica-Oblique
+/Subtype /Type1
+/Encoding /WinAnsiEncoding
+/FirstChar 32
+/LastChar 255
+>>
+endobj
+10 0 obj
+<<
+/Type /Font
+/BaseFont /Helvetica-BoldOblique
+/Subtype /Type1
+/Encoding /WinAnsiEncoding
+/FirstChar 32
+/LastChar 255
+>>
+endobj
+11 0 obj
+<<
+/Type /Font
+/BaseFont /Courier
+/Subtype /Type1
+/Encoding /WinAnsiEncoding
+/FirstChar 32
+/LastChar 255
+>>
+endobj
+12 0 obj
+<<
+/Type /Font
+/BaseFont /Courier-Bold
+/Subtype /Type1
+/Encoding /WinAnsiEncoding
+/FirstChar 32
+/LastChar 255
+>>
+endobj
+13 0 obj
+<<
+/Type /Font
+/BaseFont /Courier-Oblique
+/Subtype /Type1
+/Encoding /WinAnsiEncoding
+/FirstChar 32
+/LastChar 255
+>>
+endobj
+14 0 obj
+<<
+/Type /Font
+/BaseFont /Courier-BoldOblique
+/Subtype /Type1
+/Encoding /WinAnsiEncoding
+/FirstChar 32
+/LastChar 255
+>>
+endobj
+15 0 obj
+<<
+/Type /Font
+/BaseFont /Times-Roman
+/Subtype /Type1
+/Encoding /WinAnsiEncoding
+/FirstChar 32
+/LastChar 255
+>>
+endobj
+16 0 obj
+<<
+/Type /Font
+/BaseFont /Times-Bold
+/Subtype /Type1
+/Encoding /WinAnsiEncoding
+/FirstChar 32
+/LastChar 255
+>>
+endobj
+17 0 obj
+<<
+/Type /Font
+/BaseFont /Times-Italic
+/Subtype /Type1
+/Encoding /WinAnsiEncoding
+/FirstChar 32
+/LastChar 255
+>>
+endobj
+18 0 obj
+<<
+/Type /Font
+/BaseFont /Times-BoldItalic
+/Subtype /Type1
+/Encoding /WinAnsiEncoding
+/FirstChar 32
+/LastChar 255
+>>
+endobj
+19 0 obj
+<<
+/Type /Font
+/BaseFont /ZapfDingbats
+/Subtype /Type1
+/FirstChar 32
+/LastChar 255
+>>
+endobj
+20 0 obj
+<<
+/Type /Font
+/BaseFont /Symbol
+/Subtype /Type1
+/FirstChar 32
+/LastChar 255
+>>
+endobj
+21 0 obj
+<<
+/Type /XObject
+/Subtype /Image
+/Width 128
+/Height 47
+/ColorSpace /DeviceRGB
+/BitsPerComponent 8
+/DecodeParms <>
+/SMask 22 0 R
+/Length 18048
+>>
+stream
+
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έζ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έζ
έ
έ
έ
έ
έ}Φk_Ηk_Ηk_Ηk_Ηk_ΗuqΠ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έζ
έ
έ
έ
έ
έzzΤ[DΊ[DΊ[DΊ[DΊ[DΊk_Η
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έζ
έ
έ
έ
έ
έzzΤ[DΊ[DΊ[DΊ[DΊ[DΊk_Η
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έζ
έ
έ
έ
έ
έzzΤ[DΊ[DΊ[DΊ[DΊ[DΊk_Η
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έζ
έ
έ
έ
έ
έzzΤ[DΊ[DΊ[DΊ[DΊ[DΊk_Η
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έζ
έ
έ
έ
έ
έzzΤ[DΊ[DΊ[DΊ[DΊ[DΊk_Η
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έζ
έ
έ
έ
έ
έzzΤ[DΊ[DΊ[DΊ[DΊ[DΊk_Η
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έζ
έ
έ
έ
έ
έzzΤ[DΊ[DΊ[DΊ[DΊ[DΊk_Η
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έζ
έ
έ
έ
έ
έzzΤ[DΊ[DΊ[DΊ[DΊ[DΊk_Η
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έζ
έ
έ
έ
έ
έzzΤ[DΊ[DΊ[DΊ[DΊ[DΊk_Η
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έζ
έ
έ
έ
έ
έzzΤ[DΊ[DΊ[DΊ[DΊ[DΊk_Η
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έζ
έ
έ
έ
έ
έzzΤ[DΊ[DΊ[DΊ[DΊ[DΊk_Η
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έζ
έ
έ
έ
έ
έzzΤ[DΊ[DΊ[DΊ[DΊ[DΊk_Η
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έζ
έ
έ
έ
έ
έzzΤ[DΊ[DΊ[DΊ[DΊ[DΊk_Η
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έζ
έ
έ
έ
έ
έzzΤ[DΊ[DΊ[DΊ[DΊ[DΊk_Η
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έζ
έ
έ
έ
έ
έzzΤ[DΊ[DΊ[DΊ[DΊ[DΊk_Η
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έζ
έ
έ
έ
έ
έΫ₯Υ₯Υ₯Υ₯Υ₯ΥΨ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έζ
έ
έ
έ
έ
έ₯βπππππππππππππππΘΛθ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έζ
έ
έ
έ
έ
έ₯βπππππππππππππππΘΛθ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έζ
έ
έ
έ
έ
έ₯βπππππππππππππππΘΛθ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έζ
έ
έ
έ
έ
έ₯βπππππππππππππππΘΛθ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έζ
έ
έ
έ
έ
έ₯βπππππππππππππππΘΛθ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έζ
έ
έ
έ
έ
έ₯βπππππππππππππππΘΛθ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έζ
έ
έ
έ
έ
έ₯βπππππππππππππππΘΛθ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έζ
έ
έ
έ
έ
έ₯βπππππππππππππππΘΛθ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έζ
έ
έ
έ
έ
έ₯βπππππππππππππππΘΛθ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έζ
έ
έ
έ
έ
έ₯βπππππππππππππππΘΛθ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έζ
έ
έ
έ
έ
έ₯βπππππππππππππππΘΛθ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έζ
έ
έ
έ
έ
έ₯βπππππππππππππππΘΛθ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έζ
έ
έ
έ
έ
έ₯βπππππππππππππππΘΛθ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έζ
έ
έ
έ
έ
έ₯βπππππππππππππππΘΛθ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έζ
έ
έ
έ
έ
έ₯βπππππππππππππππΘΛθ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έζ
έ
έ
έ
έ
έ₯βπππππππππππππππΘΛθ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έζ
έ
έ
έ
έ
έ₯βπππππππππππππππΘΛθ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έζ
έ
έ
έ
έ
έ₯βπππππππππππππππΘΛθ
έ
έ
έγγξππππππππππππππππππππππππππππππππππππππππππππππππΊΎζ
έ
έ
έ
έζ
έ
έ
έ
έ
έ₯βπππππππππππππππΘΛθ
έ
έ
έγγξππππππππππππππππππππππππππππππππππππππππππππππππΊΎζ
έ
έ
έ
έζ
έ
έ
έ
έ
έ₯βπππππππππππππππΘΛθ
έ
έ
έγγξππππππππππππππππππππππππππππππππππππππππππππππππΊΎζ
έ
έ
έ
έζ
έ
έ
έ
έ
έ₯βπππππππππππππππΘΛθ
έ
έ
έγγξππππππππππππππππππππππππππππππππππππππππππππππππΊΎζ
έ
έ
έ
έζ
έ
έ
έ
έ
έ₯βπππππππππππππππΘΛθ
έ
έ
έγγξππππππππππππππππππππππππππππππππππππππππππππππππΊΎζ
έ
έ
έ
έζ
έ
έ
έ
έ
έΰΥΧλΥΧλΥΧλΥΧλΥΧλ³·ε
έ
έ
έΞΡκΥΧλΥΧλΥΧλΥΧλΥΧλΥΧλΥΧλΥΧλΥΧλΥΧλΥΧλΥΧλΥΧλΥΧλΥΧλΥΧλ±δ
έ
έ
έ
έζ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έζ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έΟ ά
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έή ί
ή
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έ
έί Ϋ
Ϊ
Ϊ
Ϊ
Ϊ
Ϊ
Ϊ
Ϊ
Ϊ
Ϊ
Ϊ
Ϊ
Ϊ
Ϊ
Ϊ
Ϊ
Ϊ
Ϊ
Ϊ
Ϊ
Ϊ
Ϊ
Ϊ
Ϊ
Ϊ
Ϊ
Ϊ
Ϊ
Ϊ
Ϊ
Ϊ
ΪΫ
+endstream
+endobj
+22 0 obj
+<<
+/Type /XObject
+/Subtype /Image
+/Width 128
+/Height 47
+/ColorSpace /DeviceGray
+/BitsPerComponent 8
+/DecodeParms <>
+/Length 6016
+>>
+stream
+ ` @@0 ίο @ PΟ Ώ 0@@ @@@@ @pP `P 0@0 @@ @@ Ώί ίοί ίΏ ` Ώ@ Ώί ΏοΏίοΟίί ίΏ ` ΏΏ Ώί Ώί P ίΏ ` οΟ Ώί Ώί ίΏ ` p Ώί Ώί ίΟ ίΏ ίΏ ` Ώί Ώί Ώί Ώί ίΏ ` Οο Ώί Ώί Ώί Ώί ίΏ ` `ί` Ώί Ώί Ώί Ώί ίΏ ` ί Ώί Ώί Ώί Ώί ίΏ ` ίί Ώί Ώί Ώί Ώί ίΏ ` Ώί Ώί Ώί Ώί ίΟ ` Ώο Ώί Ώί Ώί Ώί ―ο ` Ώί p@ Ώί Ώί Ώί @ ` ίί ί Ώί 0ίp` Ώί Ώί Ώί ο``― ί`@P @ Ώί P Ώί Ώί Ώί @ί 0 p pΟοΏ0 p p p `―οοΟp Οο ο Ώ Οί @```````````````````````````````@
+endstream
+endobj
+23 0 obj
+<<
+/Type /XObject
+/Subtype /Image
+/Width 1492
+/Height 1282
+/ColorSpace /DeviceRGB
+/BitsPerComponent 8
+/DecodeParms <>
+/SMask 24 0 R
+/Length 5738232
+>>
+stream
+ΩΥάxk
L<]H7Y\Ml΅ΌωψωeWt&;_Pnυτφώώώ3 G 2 2 2ηειύύύ-A 2 2L<]ΖΑΜ 2 2 2SCdτσυ 2 2 2{o½·Δ!
7 2 2 2 2ͺ’²I9[ 2 2B1U¦΅ 2 2 2’«uh 2 2 2°¨·ΡΜΥ 2 2 2 4πξρ 2 2 2 τσυ 2 2 2{oύύύ7$J 2 2 2 2 2βίδI9[ 2 2B1UΜΘΡ 3 2 2ΓΎΙΈ±Ώ 2 2 2xk
2 2 2 2΅ΌXHh 2 2 2ΩΥάτσυ 2 2 2{oέΪΰ 2 2 2hZvτσυμλξI9[ 2 2B1UΑ»ΗwΊ΄Ατσυ"8 2 2A/SVFf 2 2 2 2ylϋϊϋ%: 2 28%Kϋϋόώώώτσυ 2 2 2{oΛΗΠ 2 2 2¨ °I9[ 2 2B1UϊωϊZKj 2 2 2λκνφυχ"8 2 2 2 2;)NΜΘΡ 2 2 2znψχω₯SCd1 E#89'MgYvΒΌΘI9[ 2 2[Lkπξρpb~,@ 2ίάβτσυ 2 2 2{o£ 2 2 2_Pnθζκ 2 2 2 2 2 2 2
+4I9[ 2 2B1UΌΆΓdVs8&L"82 FUEe©‘±ϊωϊl_z 2 2!
7ψχωόόύ'< 2 26#Iιηλ 2 2 2{κθμG6Y+@%:<*OznΫΧήκθμG6Y+@&;@.R|pΪΦέτσυ 2 2 2’«δβηm`{0 D%:J:\³¬»ώώώ’«H7Y&;*?cUrΫΨίτσυ 2 2 2{ξνπym2 F"8>,Qσρτϋϊϋ€WGg.B!
77$JVFf ©ϊωϊτσυ 2 2 2ΦΪXHh%:4!H»΅Β 2 2 2΄»φυχ£SCd.B 5*?O>`£ψχωΌΆΓdVs8&L"82 FUEe©‘±ϊωϊw 2 20 D΄»Q@a(=(=UEeΏΉΕ§ 2 2 2΄»ΏΉΕ 2 2 5 2 2 2γΰε 2 2 2½·ΔβίδF5X 2 2 2 2 2 2 2qc~ωψωI9[ 2 2[LkTDe 2 2 2ίάβτσυ 2 2 2{oΎΈΔ 4 2 2F5Xτσυκθμ 2 2 2 2 2 2 2
+4I9[ 2 2B1Uχφψi\x 2 2 2 2 2 2 2K;]εγθͺ£³ 2 2 2ΙΔΞΠΛΤ 2 2 2 2αήδ΄» 2 2 2ΓΎΙΓΎΙ.B 2 2 2 2 2 2!
7₯ΒΌΘ-A 2 2 2 2 2 2 6§τσυ 2 2 23 G 2 2 2 2 2°¨·wj 2 2 2 2 2)>ήΫατσυ 2 2 2sE4W 2 2 2 2 2A0TθζκνμοK;] 2 2 2 2 2 2 2G6Yονρτσυ 2 2 2x,@ 2 24!H»΅Β 2 2 2΄»γαζ;)N 2 2 2 2 2 2 2D3Vνμοχφψi\x 2 2 2 2 2 2 2K;]εγθw 2 20 D¦ 2 2 2 2 2 3¦―ΰέγ 2 2 2}qv 2 2eWtD3V 2 2₯]Nm 2 2$9χφψχφψC2U 2 2 25"IRBc(= 2 2 2{oI9[ 2 2&; 2 2*? 6ίάβτσυ 2 2 2{oΫΧή(= 2 22 FζδθροςfXu0 D 2 2 2 2fXui[wI9[ 2 2B1Usf 2 2 2)>RBc4!H 2 2 2I8Zϊωϊιηλ 2 2 2£ 2 2 2 2©‘±t 2 2%:ωψωίάβ'< 2 2 24!HA/S 4 2 2 4ΛΗΠΫΨί&; 2 2 2B1UN=_
+4 2 2 2΄»τσυ 2 2 2)> 4G6Y-A 2 2 2,@ 2-AF5X 6 2 2 2m`{τσυ 2 2 2"8 2I8Z`Qo*? 2 2 2[LkeWt 2 2 2M<^m`{B1U 2 2 2tgτσυ 2 2 2&; 2
+4+@7$J»΅Β 2 2 2΄»aRp 2 2 2UEes[Lk 2 2 2l_zsf 2 2 2)>RBc4!H 2 2 2I8Zϊωϊw 2 2 6#8%:E4W(< 2 2 2%:ρος@.R 2 2E4WD3V 2 2ͺ’²~ 2 2i[wόόύ(= 2 2_Pn£ 2 2 2xk
ϋϋόξνπH7Y 2 2 2ΩΥάI9[ 2 2 2Q@aαήδόόύύύύτσυ 2 2 2{oονρ;)N 2 2%:ΝΦΚΕΟ 2 2 2ͺ’²I9[ 2 2B1UΞΧ 2 2 2J:\πξρϋϋόtg 2 2 2‘ͺC2U 2 2_PnaSq 2 2 2 2qc~K;] 2 2\MlcUr 2 2 2¨ώώώΞΚΣ&; 2 2cUraRp 2 2 2¬₯΄ΣΟΨ)> 2 22 Fόόύτσυ 2 2 2 6ΒΌΘφυχSCd 2 2 2YIiχφψΣΟΨ#8 2 25"Iτσυ 2 2 2 2§νμο@.R 2 2 2ΤΠΨςπσA0T.B
+4
ύύύK;] 2 2(=τσυ 2 2 2 2ylροςϊωϊ»΅Β 2 2 2΄»ώώώ$9 2 2aRp§8%K8%K>,QϋϋόΞΧ 2 2 2J:\πξρϋϋόtg 2 2 2‘ͺw 2 2 2Q@aονρσςυVFf 2 2 2―§·w 2 2 3πξρκθμ 2 2 4λκνΜΘΡ 2 2-AύύύΝΦ 2 2 2’«I8Z 2 2+@φυχΖΑΜ 2 2 2|I9[ 2 2 6κθμτσυ 2 2 2wjVFf 2 2 4·°ΎΚΕΟ 2 2 2ͺ’²I9[ 2 2B1Uv 2 2 2ΝΙσςυ'< 2 2N=_v 2 2+@ώώώώώώ,@ 2"8 4 28&Lφυχ 5 2 2€πξρ 6 2 2YJi?-Q?-QVFfονρ 5 2 2[Lk 2 2 2ΐΊΖτσυ 2 2 2dVs¦Ά 2 2 2»΅ΒZKj 2 2$9τσυ 2 2 2C2U΅Ό 2 2 2ώώώώώώώώώaRp 2 2 2φυχτσυ 2 2 2E4Wώώώ»΅Β 2 2 2΄»-A 2 28&LΝΙώώώv 2 2 2ΝΙσςυ'< 2 2N=_w 2 2 2ΚΕΟΗΒΜ 2 2 2ΕΐΛ 2 2 2Ί³ΐ¦΅ 2 2M<^ύύύ/C 2 2ΝΦ£ 2 2 2γαζ#8 2 2`Qoόόύ"8 2 2`QoI9[ 2 2>,Qτσυ 2 2 2 2 2 2 2sfΚΕΟ 2 2 2ͺ’²I9[ 2 2B1U[Lk 2 2(<ώώώXHh 2 2'<ΐΊΖ 2 2 2ΩΥάΨΤά 2 2fXuL<] 2 2δβηΖΑΜ 2 2 2ΩΥάΝΙ 2 2 2£ΝΙ 2 2 2£ΚΕΟ 2 2 2£τσυ 2 2 2{o»΅Β 2 2 2ΝΙi\x 2 2"8τσυ 2 2 2|pπξρ 2 2 2qc~ϋϋόΐΊΖreXHh1 E 2 2 2 2τσυτσυ 2 2 2wj»΅Β 2 2 2΄»zn 2 2 2 2,@YIi|ΖΑΜϋϋό[Lk 2 2(<ώώώXHh 2 2'<w 2 2 2λκνδβη 2 2 2ϋϊϋ)> 2 2vpb~ 2 2qc~ 2 2bTr 2 2C2Uσςυ 2 2 2qc~0 D 2 2M<^I9[ 2 2B1Uτσυ 2 2 2 2 2 2 2I9[ϋϊϋΚΕΟ 2 2 2ͺ’²I9[ 2 2B1UI8Z 2 28%Ki[w 2 2 2ψχωχφψ#8 2 2€‘ͺ 2 2₯ 2 2¬₯΄ 2 23 GΊ΄Α 2 2 2ͺ’²Ί΄Α 2 2 2ͺ’²ΫΧή 2 2 2{τσυ 2 2 2{o»΅Β 2 2 2ΝΙi\x 2 2"8τσυ 2 2 2ύύύ 2 2 2aRp―§·5"I 2 2 2 2 2 3 2 2 2τσυτσυ 2 2 2{o»΅Β 2 2 2΄»υτφsf 2 2 2 2 2 2 2<*OΙΔΞI8Z 2 28%Ki[w 2 2 2ψχωw 2 2 2νμοζδθ 2 2 2hZv 2 2E4W2 F 2 2ΥΡΩ΄» 2 2RBc,@ 2 2{"8 2 2_Pnϋϋό!
7 2 2_PnI9[ 2 2B1Uτσυ 2 2 2 2 2 2 2 2}ΚΕΟ 2 2 2ͺ’²I9[ 2 2B1UZKj 2 2(<ώώώWGg 2 2&;YJi 2 2oa}i\x 2 2γαζΚΕΟ 2 2tg]Nm 2 2qc~ΜΘΡ 2 2 2‘ΜΘΡ 2 2 2’ΙΔΞ 2 2 2’τσυ 2 2 2{o»΅Β 2 2 2ΝΙi\x 2 2"8τσυ 2 2 2tgιηλ 2 2 2qc~ΛΗΠ 4 2 2/Cxk
’«ΚΕΟs 2 2 2τσυτσυ 2 2 2{o»΅Β 2 2 2΄»ζδθ’«pb~C2U
+4 2 2 2+@μλξZKj 2 2(<ώώώWGg 2 2&;w 2 2 2νμοζδθ 2 2 2ͺ£³ 2 2 2 2 26#Iσςυ 6 2 2 2 2 2ΙΔΞG6Y 2 2)>υτφΓΎΙ 2 2 2{I9[ 2 2B1Uτσυ 2 2 2 2ΩΥά1 E 2 2 4ΚΕΟΚΕΟ 2 2 2ͺ’²I9[ 2 2B1Ut 2 2 2ΚΖΠσρτ&; 2 2M<^’ 2 27$J2 F 2?-Qϋϋό)> 28%K*? 2 2―§·ονρ 5 2 2VFf~r4!H4!HN=_ξνπ 5 2 2YIi 2 2 2ΏΉΕτσυ 2 2 2{o»΅Β 2 2 2ΝΙi\x 2 2"8τσυ 2 2 26#Iϋϊϋ₯ 2 2 2{o 2 2,@μλξyl 2 2 2τσυτσυ 2 2 2{o»΅Β 2 2 2΄»ώώώϋϋόϋϋόϋϋόπξρhZv 2 2 2Έ±Ώt 2 2 2ΚΖΠσρτ&; 2 2M<^w 2 2 2νμοζδθ 2 2 2λκν 4 2 2 2 2ymYIi 2 2 2 2+@όόύ’ 2 2 2tgϋϊϋμλξE4W 2 2 2ΨΤάI9[ 2 2B1Uτσυ 2 2 2qd½·Δ 2 2 28&LσρτΚΕΟ 2 2 2ͺ’²I9[ 2 2B1UΡΜΥ 2 2 2H7Yνμοϊωϊqc~ 2 2 2 ©ΦΪ 2 2 2 2 2}qcUr 2 2 2 2 3μλξ`Qo 2 2 2£ύύύΓΎΙ%: 2 2hZv_Pn 2 2 2¨ °ΡΜΥ(= 2 20 Dϋϋότσυ 2 2 2{o»΅Β 2 2 2ΝΙi\x 2 2"8τσυ 2 2 2 2ymωψωΣΟΨ0 D 2 2 2ΞΧoa} 2 24!Hϋϋόηει0 D 2 2 2τσυτσυ 2 2 2{o»΅Β 2 2 2΄»ΖΑΜ 2 2 2 £ 2 2 2ΏΉΕΡΜΥ 2 2 2H7Yνμοϊωϊqc~ 2 2 2 ©w 2 2 2νμοζδθ 2 2 2M<^ 2 2 2 2½·Δ¦ 2 2 2 2j]yφυχA/S 2 2 20 DL<]&; 2 2 2ylI9[ 2 2B1Uτσυ 2 2 2{owj 2 2 2oa}ΚΕΟ 2 2 2ͺ’²I9[ 2 2B1Uqc~ 2 2 2&;L<]0 D 2 2 2G6Yωψω2 F 2 2 2 2ΌΆΓ’« 2 2 2 2H7YΫΧή%: 2 2 2/C6#I 2 2 2
+4ΟΚΤΪΦέ%: 2 2 2=+PH7Y 4 2 2 2²ͺΉτσυ 2 2 2{o»΅Β 2 2 2ΝΙi\x 2 2"8τσυ 2 2 2(< 2(=8&L 3 2 2 2YJi‘ 2 2 2N=_{o,@ 2 2 2 2τσυτσυ 2 2 2{o»΅Β 2 2 2΄»ύύύA0T 2 2 3YIiym^Om
+4 2 25"Iφυχqc~ 2 2 2&;L<]0 D 2 2 2G6Yωψωw 2 2 2νμοζδθ 2 2 2
2 2 2%:ψχωαήδ 2 2 2 2¦΅ΰέγC2U 2 2 2 2 2 2 2m`{ψχωI9[ 2 2B1Uτσυ 2 2 2{oτσυ:(M 2 2 2³¬»ΚΕΟ 2 2 2ͺ’²I9[ 2 2B1UυτφfXu 2 2 2 2 2 2 2I8Zγαζoa} 2 2 2!
7υτφβίδ 2 2 2 2{ΎΈΔ*? 2 2 2 2 2 2 6¦―ΏΉΕ+@ 2 2 2 2 2 2 5£τσυ 2 2 2{o»΅Β 2 2 2ΝΙi\x 2 2"8τσυ 2 2 2ylO>` 2 2 2 2 2>,Qεγθπξρ<*O 2 2 2 2 2*?y 2 2 2τσυτσυ 2 2 2{o»΅Β 2 2 2΄»ΫΧή6#I 2 2 2 2 2 2 20 DΝΦυτφfXu 2 2 2 2 2 2 2I8Zγαζw 2 2 2νμοζδθ 2 2 2ΞΧ 2 2 2aRpA/S 2 2 4νμοχφψ’«QAb0 D"88%KeWtΎΈΔI9[ 2 2B1Uτσυ 2 2 2{oΚΖΠ 4 2 2+@ηειΚΕΟ 2 2 2ͺ’²I9[ 2 2B1UΉ²ΏbTr7$J"81 ETDe₯ωψω¦Ά 2 2 2UEe<*O 2 2 2ΔΏΚζδθE4W*?$9;)NviΨΤάηειF5X*?&;?-QymΧΣΫτσυ 2 2 2{o»΅Β 2 2 2ΝΙi\x 2 2"8τσυ 2 2 2{oςπσym1 E"8=+P}πξρνμο~r9'M!
76#Ii\xίάβ¦― 2 2 2τσυτσυ 2 2 2{o»΅Β 2 2 2΄»σρτN=_*?
+4,@O>`ςπσΉ²ΏbTr7$J"81 ETDe₯ωψωw 2 2 2νμοζδθ 2 2 2τσυ 2 2 2{oτσυ 2 2 2{oτσυ 2 2 2{oτσυ 2 2 2{oτσυ 2 2 2{oΔΏΚ\Ml.B#8M<^΅Όϋϋό 2Έ±ΏF5X―§·*?ΣΟΨQ@asQ@asώώώ|4!H)>ΰέγΒ½Θ 2ροςρος 2Β½ΘήΫα-A’«Β½Θ 2ρος§ 3WGg¨£¬k^z
+4~rϋϋό 2Έ±Ώ)>’«F5XΏΉΕI9[έΪΰQ@asbTri\xQ@as»΅Β 2»΅ΒΒ½Θ 2ροςρος 2Β½ΘbTri\x₯0 DζδθK;]΄»Β½Θ 2ρος)>’«ΣΟΨ 5²«Ί 2·°Ύϋϋό 2Έ±Ώ)>’«F5XQ@asbTri\xQ@as¦,@Β½Θ 2ροςρος 2Β½ΘbTri\x₯0 DΒ½Θ 2ρος)>’«qdD3Vύύύi\x{ϋϋό 2°¨·re)>(=qc~τσυΓΎΙQ@a%:1 E{oσςυ‘ͺ@.R#8=+P€ώώώ’«?-Q"8:(M¨φυχt3 G(=WGgΙΔΞΖΑΜ 2 2 2 2Β½ΘF5XΐΊΖA0T"8A0T»΅Β ©?-Q%:G6Y¦―ϋϋό 2ͺ£³ZKj!
7²ͺΉΒ½Θ 2ροςΩΥάZKj'<2 F₯Q@aQ@as’3 G#8UEeέΪΰ 2 2 2 2Ή²Ώ 3κθμ²ͺΉ 2¬₯΄κθμ 2Ί΄Αφυχu3 G%:M<^ΎΈΔQ@a’«4!HA/SQ@asνμο@.R^Omϋϊϋ?-Q 2 2 2;)NΒ½Θ 2ροςφυχu3 G%:M<^ΎΈΔtA/Syl 2δβ籩Έ
+4πξργαζfXu(=(=_PnγΰεΞΧ\Ml.B(<^OmΥΡΩΒ½Θ 2ΝΦN=_#88&L¦―ύύύ7$J"8YJiΫΨί 2Β½ΘΩΥάZKj'<2 F₯Q@aΓΎΙP?a%:;)Nyψχω 2 2 2 2 ©?-Q"8<*O§φυχu3 G%:M<^ΎΈΔQ@a¨ °6#I%:eWtρος3 G(.default})
+Data flow for application and infrastructure monitoring
+.default})
+JSON schema for monitoring dashboards
+.default})
+
+### 1. Connect a Public Git Repository
+
+You can connect to a public Git repository by simply providing the following details:
+
+- Hub Name
+- Git URL of the forked repository
+- Branch Name
+
+.default})
+
+### 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:
+
+.default})
+
+#### a. Access Token
+
+Personal Access Tokens are used as an alternative to the password for authentication to Git services.
+
+#### 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.
+
+.default})
+
+## 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.
+
+## 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 Scenarios and Experiments in a ChaosHub
+
+### 1. View the PreDefined Chaos Scenarios
+
+After connecting a ChaosHub, you can view the different pre-defined chaos scenarios present in the ChaosHub.
+
+.default})
+
+### 2. View the Chaos-Experiments
+
+Similarly, you can view the different charts and the experiment. These charts are sorted according to different categories like generic, aws, azure, kube-components etc.
+
+.default})
+
+### 3. View the experiment details
+
+You can select one of the chaos experiment and can examine the experiment details.
+The experiment page consists of all the important details like the description of the experiment, a tutorial video, the maintainer of the experiment etc.
+You can also find experiment yaml link, RBAC link and the ChaosEngine yaml link of the experiment.
+These yaml links are required for the creation of Custom Chaos Scenarios.
+
+.default})
+
+## Disconnect a ChaosHub
+
+To remove a ChaosHub from a project, you can select the **Disconnect Hub** option from the ChaosHub card.
+
+## Summary
+
+ChaosHubs are basically a collection of different clones of the Chaos-Charts repository, which consists of a variety of experiments and pre-defined chaos scenarios. You can use a ChaosHub to construct a custom chaos scenarios and tune it according to the use-case. These ChaosHubs can also be synced with the latest changes. New experiments and pre-defined chaos scenarios can also be added in the repository which can be directly used in the ChaosCenter.
+
+## Resources
+
+
+
+## Learn More
+
+- [What is a Chaos Scenario](chaos-workflow.md)
+- [Examine the ChaosResult](chaos-result.md)
diff --git a/website/versioned_docs/version-2.13.0/concepts/datasource.md b/website/versioned_docs/version-2.13.0/concepts/datasource.md
new file mode 100644
index 0000000..9faaf4b
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/concepts/datasource.md
@@ -0,0 +1,51 @@
+---
+id: datasource
+title: Manage Datasources
+sidebar_label: Datasource
+---
+
+---
+
+The primary stateful data store for litmus's chaos center is a mongoDB statefulset. It powers all the features in chaos center including authentication, chaos injection and analysis, chaos delegate connections etc. Apart from the primary data store, the portal provides a way to add Prometheus (TSDB) data sources for time series data visualization and monitoring. The principle of Open observability drives the chaos center and allows users to manage the data sources for a project in multiple topologies for chaos delegate specific and cross chaos delegate dashboards. The system allows to either have multiple data sources or a single data source scraping metrics and events from all target chaos delegates for monitoring chaos impact on
+application OR infrastructure.
+
+## Prerequisites
+
+The following should be required before knowing about managing data sources in chaos center:
+
+- [Running Chaos Scenarios](../getting-started/run-your-first-workflow.md)
+- [Prometheus TSDB](https://prometheus.io/)
+
+## Data flow architecture
+
+The chaos center provides the functionality to connect multiple prometheus data sources across projects to harness insights on application or system behavior during chaos manifested on real-time monitoring dashboards. Litmus follows an open observability model which enables users to plug metrics from any Prometheus exporter into the data source connected to a chaos center project to visualize the same on dashboards. Along with system and application metrics the metrics exposed by `chaos-exporter` service (a prometheus metrics exporter for chaos injection events and results or verdicts) on the execution plane or target chaos delegate's cluster is necessary to be ingested into the same data source to be connected to the project in order to facilitate chaos interleaving. Existing monitoring infrastructure for observing the target chaos delegate's cluster can also be used if it is prometheus based, plugging the metrics from `chaos-exporter` in such cases should be sufficient.
+
+.default})
+Data flow from data sources
+.default})
.default})
.default})
.default})
+
+The specifics of project management with respect to different first layer privilege levels (Admin/non-admin users) are discussed below:
+
+The **Admin** user of the portal has a default project (named as `adminβs project`) created on the initial login, and by default has the `owner` privileges in this project.
+
+The Admin can [create a user](../user-guides/create-user.md) (these users will be treated as **non-admin** users), and each of these users will have their own projects created on completion of their initial login. The `Owner` of a project can invite multiple users to their project, and a user can be a part of multiple projects, these features are covered under the [teaming](teaming.md) section.
+
+## Summary
+
+Projects can be imagined as separations between multiple different configurations for your chaos and help you manage collaborations between multiple teams.
+
+## Learn more
+
+- [More about project management](../user-guides/change-project-name.md)
+- [More about Teaming](teaming.md)
+- [Invite a member to your project](../user-guides/invite-team-member.md)
diff --git a/website/versioned_docs/version-2.13.0/concepts/teaming.md b/website/versioned_docs/version-2.13.0/concepts/teaming.md
new file mode 100644
index 0000000..a8abfae
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/concepts/teaming.md
@@ -0,0 +1,50 @@
+---
+id: teaming
+title: Collaborate with Teams
+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)
+
+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`.
+
+Teaming is based on the following principles and each user can have one of the 3 project roles:
+
+- **Owner:** One who created the project and owns it. Only the owner has permission to manage(invite or remove) the members in his/her project. The owner can schedule chaos scenarios, update chaos scenarios, delete chaos scenarios and view the analytics.
+- **Editor:** Members invited with the editor role can do everything an owner can except for managing the project.
+- **Viewer:** Members having a viewer role can only view the analytics related to the chaos scenarios and the chaos scenarios themselves, but are not given the permission to schedule chaos scenarios in the project.
+
+## Role privileges
+
+> Note: A user will be the owner of his/her project by default.
+
+**_As the Project Owner you can:_**
+
+- Invite other users for the following roles:
+ - Viewer
+ - Editor
+- View the list of team members with other details including their role in the project, email-id, date-time of joining the project team.
+- Rename your project.
+- Remove a member from your project.
+- Check the status of the invitation you sent to other members.
+- Edit the user role in case the invitation is pending.
+- Cancel the invitation.
+
+**_As a Viewer or Editor you can:_**
+
+- Check and Accept/Decline the received invitations.
+- Switch and browse any project you are a member of.
+- Can leave the project you are a part of, except your own.
+
+> Note: The settings page will not be visible to you if you are browsing someone elseβs project. You can only view it if you are the project owner.
+
+## Learn more
+
+- [Invite a team member](../user-guides/invite-team-member.md)
+- [Edit/Cancel an invite](../user-guides/edit-invite.md)
+- [Accept an invite](../user-guides/accept-invite.md)
+- [Remove a team member](../user-guides/remove-team-member.md)
diff --git a/website/versioned_docs/version-2.13.0/concepts/user-management.md b/website/versioned_docs/version-2.13.0/concepts/user-management.md
new file mode 100644
index 0000000..9930d58
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/concepts/user-management.md
@@ -0,0 +1,32 @@
+---
+id: 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.
+
+> 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)
+
+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.
+
+**Non-admin users:** The admin of the portal has the exclusive ability to create any number of non-admin users.
+
+## 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.
+
+**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 on different chaos delegates which have no layover between each other.)
+
+## Learn more
+
+- [View Users](../user-guides/view-user.md)
+- [Create a user](../user-guides/create-user.md)
+- [Reset password of a user](../user-guides/reset-password.md)
+- [Deactivate a user](../user-guides/deactivate-user.md)
diff --git a/website/versioned_docs/version-2.13.0/concepts/visualize-workflow.md b/website/versioned_docs/version-2.13.0/concepts/visualize-workflow.md
new file mode 100644
index 0000000..f6629d3
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/concepts/visualize-workflow.md
@@ -0,0 +1,71 @@
+---
+id: visualize-workflow
+title: Visualize the Chaos Scenario Execution
+sidebar_label: Visualize Chaos Scenario
+---
+
+---
+
+Visualization is an important aspect while doing chaos engineering. It allows the user to discover and inspect different changes that occur during a Chaos Scenario execution. .default})
+
+The Chaos Scenario Details page is divided into 2 sections:
+
+- **Graph View**: In this section a realtime graph of the chaos scenario is displayed. This graph contains valuable information regarding the status of individual steps of the chaos scenario..default})
.default})
+
+:::note
+If the selected node is an experiment pod which consists of ChaosEngine CRD, a button to Download the logs will be available. Similarly, a tab named `Chaos Results` will also be available, which displays the ChaosResult of the experiment once the chaos scenario execution is completed.
+:::
+
+- **Table View** : Similar to the Graph View, this tab consists the table view of the chaos scenario. The table consists of the different chaos scenario steps along with their status. .default})
+ .default})
+
+## Summary
+
+After scheduling a chaos scenario, a user can view the details of the running chaos scenario from the ChaosCenter. ChaosCenter provides a realtime graph that is used to visualise the chaos scenario and get the details of individual step of the chaos scenario. Important details like the logs and target applications can be viewed from ChaosCenter. These logs are also downloadable. User can view the details in 2 different ways i.e `Graph View` and `Table View`. Once the chaos scenario exection is completed, the resiliency score is calcualted and the ChaosResult for the ChaosEngine pods are available now.
+
+## Learn More
+
+- [Explore Probes](probes.md)
+- [What is a Chaos Scenario](chaos-workflow.md)
+- [Examine the ChaosResult](chaos-result.md)
diff --git a/website/versioned_docs/version-2.13.0/concepts/workflow-statistics.md b/website/versioned_docs/version-2.13.0/concepts/workflow-statistics.md
new file mode 100644
index 0000000..8ab4714
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/concepts/workflow-statistics.md
@@ -0,0 +1,50 @@
+---
+id: workflow-statistics
+title: Chaos Scenarios Statistics
+sidebar_label: Scenarios Statistics
+---
+
+---
+
+Chaos injections often tends to disrupt tightly coupled micro-services and processes. Visualizing the results and plotting analytical graphs prove to be useful under such circumstances. An analytical overview of chaos scenarios for an entire month or a year can help in benchmarking release cycles and building a viable cloud-native product. Also a comparative study over time or rather just being able to observe and plot resiliency scores across different types of chaos scenarios on different subsystems provide a conclusive summary of the reliability metrics for an application under test (AUT) and the supporting platform or infrastructure.
+
+## Prerequisites
+
+The following should be required before knowing about chaos scenario statistics:
+
+- [Chaos Scenarios](chaos-workflow.md)
+- [Visualize Chaos Scenarios](visualize-workflow.md)
+
+## Data flow architecture
+
+The chaos center automatically detects scheduled chaos scenario runs on all connected chaos delegates for a project and provides statistical graphs and visualizations. Data for chaos scenarios runs and chaos results from all the chaos delegates are stored in a mongoDB database which is then ingested into analytical pipelines in the control plane server to transform the raw data into meaningful insights for browsing and reporting.
+
+.default})
+Data flow for statistical analysis
+.default})
+
+By default you are assigned with a default project with Owner permissions.
+
+.default})
+
+## **Verify Successful Registration of the Self Chaos Delegate**
+
+Once the project is created, the cluster is automatically registered as a chaos target via installation of [Chaos Delegate](resources.md#chaosagents). This is represented as [Self Chaos Delegate](resources.md#types-of-chaosagents) in [ChaosCenter](resources.md#chaoscenter).
+
+```bash
+kubectl get pods -n litmus
+```
+
+```bash
+NAME READY STATUS RESTARTS AGE
+chaos-exporter-547b59d887-4dm58 1/1 Running 0 5m27s
+chaos-operator-ce-84ddc8f5d7-l8c6d 1/1 Running 0 5m27s
+event-tracker-5bc478cbd7-xlflb 1/1 Running 0 5m28s
+litmusportal-frontend-97c8bf86b-mx89w 1/1 Running 0 15m
+litmusportal-server-6fd57cc89-6w5pn 1/1 Running 0 15m
+litmusportal-auth-server-7b596fff9-5s6g5 1/1 Running 0 15m
+mongo-0 1/1 Running 0 15m
+subscriber-958948965-qbx29 1/1 Running 0 5m30s
+workflow-controller-78fc7b6c6-w82m7 1/1 Running 0 5m32s
+```
+
+## Resources
+
+
+
+## Learn more
+
+- [Install ChaosCenter in Namespace Scope](../user-guides/chaoscenter-namespace-scope-installation.md)
+- [Connect External Chaos Delegates to ChaosCenter](../user-guides/chaosagents-installation.md)
+- [Setup Endpoints and Access ChaosCenter without Ingress](../user-guides/setup-without-ingress.md)
+- [Setup Endpoints and Access ChaosCenter with Ingress](../user-guides/setup-with-ingress.md)
diff --git a/website/versioned_docs/version-2.13.0/getting-started/resources.md b/website/versioned_docs/version-2.13.0/getting-started/resources.md
new file mode 100644
index 0000000..8daee42
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/getting-started/resources.md
@@ -0,0 +1,69 @@
+---
+id: resources
+title: Resources
+sidebar_label: Resources
+---
+
+---
+
+## ChaosCenter
+
+The **ChaosCenter** is a single source of truth to control all the different Chaos Activities happening around Litmus. From the ChaosCenter you get the freedom to manage every single part of Litmus and shape your chaos scenarios 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)
+
+The ChaosCenter gives you access to a plethora of features, the major ones include
+
+- Chaos Scenario Creation
+
+ ![Schedule Chaos Scenario from Homepage]({require("../assets/getting-started/run-your-first-workflow/schedule-workflow-from-homepage.png").default})
![Schedule Chaos Scenario from Litmus Chaos Scenarios]({require("../assets/getting-started/run-your-first-workflow/schedule-workflow-from-litmus-workflows.png").default})
+
+![Selecting Self Chaos Delegate]({require("../assets/getting-started/run-your-first-workflow/selecting-self-agent.png").default})
+
+3. Expand the first radio button (To create a new Chaos Scenario from Predefined Chaos Scenario Templates) and select **podtato-head** from the list of Predefined Chaos Scenarios.
+
+ ![Select Podtato Head]({require("../assets/getting-started/run-your-first-workflow/select-podtato-head.png").default})
+
+4. View the Chaos Scenario details in the **Chaos Scenario Settings**, you can modify the name and description of the Chaos Scenario to suit your needs.
+
+ ![Modify Details of Podtato Head Chaos Scenario]({require("../assets/getting-started/run-your-first-workflow/workflow-settings-podtato-head.png").default})
+
+### Simulate the Chaos Scenario Steps Visualization
+
+5. View the visualization of the Litmus Chaos Scenario you are about to execute. This step also allows for you to edit or modify the YAML/tunable if required. We would just stick with the default configurations for now.
+
+ ![Visualize Podtato Head Chaos Scenario]({require("../assets/getting-started/run-your-first-workflow/podtato-head-tune-workflow.png").default})
+
+ > By default in the Podtato Head Chaos Scenario Template the steps to gracefully delete the Chaos Resources (`revert-chaos`) and also the Podtato Head application (`delete-application`) are present.
+
+### Assign Weights to the Chaos Scenario Experiments
+
+6. Assign weights to the chaos experiments that are part of the Chaos Scenario using the slider. This is typically used when there are multiple experiments as part of a Chaos Scenario. These weights influence the **Resilience Score** calculation for the Chaos Scenario.
+
+ ![Assign Weights for Chaos Scenario Experiments]({require("../assets/getting-started/run-your-first-workflow/adjust-weights-for-podtato-head.png").default})
+
+### Schedule the Podtato-Head Chaos Scenario
+
+7. Schedule the Litmus Chaos Scenario for immediate and one-time execution by selecting the **Schedule Now** option
+
+ ![Choose a Schedule for Chaos Scenario Execution]({require("../assets/getting-started/run-your-first-workflow/choose-schedule.png").default})
+
+8. Verify and click on **Finish** to start the Chaos Injection
+
+ ![Verify and Schedule the Podtato Head Chaos Scenario]({require("../assets/getting-started/run-your-first-workflow/verify-and-commit-podtato-head.png").default})
+
+### Congratulations
+
+And with that you have successfully scheduled your first Chaos Scenario with Litmus.
+
+![Podtato Head Chaos Scenario Scheduled Successfully]({require("../assets/getting-started/run-your-first-workflow/scheduled-successfully.png").default})
+
+---
+
+## Visualize and Analyze
+
+1. To check the current progress of the Podtato-Head Chaos Scenario, view the status of the Chaos Scenario from the **Litmus Chaos Scenarios** Tab.
+
+ ![Podtato Head Chaos Scenario in Running State]({require("../assets/getting-started/run-your-first-workflow/podtato-head-workflow-running.png").default})
+
+2. Litmus deploys a sample multi-replica hello-service application before going onto pull the pod-delete ChaosExperiment template. In the next step, it creates the ChaosEngine to launch the chaos injection via dedicated pods.
+
+ To see all these steps live in action on the `chaos scenario name` from the **Runs** Tab or select **Show the Chaos Scenario** from the three dot menu.
+
+ ![Podtato Head Chaos Scenario in Action]({require("../assets/getting-started/run-your-first-workflow/podtato-head-workflow-in-action.png").default})
+
+ To see them in action on the terminal itself watch the pods in the namespace where ChaosCenter is installed.
+
+ > In this case we would consider ChaosCenter to be installed in the `litmus` namespace
+
+ ```bash
+ kubectl get pods -n litmus
+ ```
+
+ Expected Output
+
+ ```bash
+ NAME READY STATUS RESTARTS AGE
+ chaos-exporter-547b59d887-4dm58 1/1 Running 0 6h16m
+ chaos-operator-ce-84ddc8f5d7-l8c6d 1/1 Running 0 6h16m
+ event-tracker-5bc478cbd7-xlflb 1/1 Running 0 6h16m
+ litmusportal-frontend-698bcb686f-xm4q5 1/1 Running 0 6h26m
+ litmusportal-server-5bb94f65d7-llzng 2/2 Running 1 6h26m
+ mongo-0 1/1 Running 0 6h26m
+ pod-delete-llu29u-vh8w9 1/1 Running 0 21s
+ podtato-5554584d7-68bts 1/1 Running 0 94s
+ podtato-5554584d7-cjmv6 0/1 ContainerCreating 0 2s
+ podtato-5554584d7-z4cwl 0/1 Terminating 0 94s
+ podtato-head-chaos-1622018315-1170130526 0/2 Completed 0 112s
+ podtato-head-chaos-1622018315-3739956689 2/2 Running 0 31s
+ podtato-head-chaos-1622018315-80657052 0/2 Completed 0 79s
+ podtato-head-pod-delete-chaosx55vh-runner 1/1 Running 0 25s
+ subscriber-958948965-qbx29 1/1 Running 0 6h16m
+ workflow-controller-78fc7b6c6-w82m7 1/1 Running 0 6h16m
+ ```
+
+3. Post Chaos Execution view the Experiment Results. Click on the **pod-delete** node on the graph to launch a results console. Click on the **Chaos Results** tab to view the details around success/failure of the steady-state hypothesis constraints (podtato-head website availability through pod deletion period) and the experiment verdict.
+
+ ![ChaosResult of Podtato Head]({require("../assets/getting-started/run-your-first-workflow/chaos-result-of-podtato-head.png").default})
+
+## Resources
+
+
+
+### Beginner Friendly Resources
+
+β¨ Below is a list of beginner-level resources, everything you need to get started in your Cloud-Native Chaos Engineering journey β¨
+
+[List of Beginner Friendly Resources](https://github.com/litmuschaos/litmus/tree/master/resources)
+
+## Various Ways of Learning Litmus
+
+- [Learn Concept](../concepts/overview.md)
+- [View User Guides](../user-guides/overview.md)
+- [Learn by Running a sample Katakoda Scenario](https://www.katacoda.com/litmusbot/scenarios/getting-started-with-litmus)
diff --git a/website/versioned_docs/version-2.13.0/glossary.md b/website/versioned_docs/version-2.13.0/glossary.md
new file mode 100644
index 0000000..b69b8a1
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/glossary.md
@@ -0,0 +1,7 @@
+---
+id: glossary
+title: Glossary
+sidebar_label: glossary
+---
+
+## Coming Soon
diff --git a/website/versioned_docs/version-2.13.0/integrations/grafana.md b/website/versioned_docs/version-2.13.0/integrations/grafana.md
new file mode 100644
index 0000000..8c149d5
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/integrations/grafana.md
@@ -0,0 +1,274 @@
+---
+id: grafana
+title: Observe chaos impact using Grafana
+sidebar_label: Grafana
+---
+
+---
+
+Chaos Engineering is the discipline of experimenting on a system to build confidence in the systemβs capability to withstand turbulent conditions in production. Monitoring a system's resilience and its performance under chaos are one of the fundamental principles of chaos engineering. Litmus has sample chaos interleaved dashboards available on Grafanaβs community dashboards as well as provisioned dashboards along with provisioned data sources. Some sample chaos interleaved dashboards can be found [here](https://github.com/litmuschaos/litmus/tree/master/monitoring/grafana-dashboards)
+
+## Before you begin
+
+The following should be required before integrating Grafana with litmus 2.0:
+
+- [Running Chaos Scenarios](../getting-started/run-your-first-workflow.md)
+- [Prometheus TSDB](https://prometheus.io/)
+- [Prometheus Integration](prometheus.md)
+- [Application and infrastructure monitoring](../concepts/app-infra-monitoring.md)
+
+## Grafana setup with provisioned data source amd dashboards using Prometheus deployment with scrape jobs
+
+The following steps can be followed to set up Grafana with Prometheus for accessing the integrated and interleaved dashboards
+
+- Clone the litmus repo
+
+```bash
+git clone https://github.com/litmuschaos/litmus.git
+cd litmus/monitoring
+```
+
+- Create monitoring namespace on the cluster
+
+```bash
+kubectl create ns monitoring
+```
+
+- Deploy prometheus components
+
+```bash
+kubectl -n monitoring apply -f utils/prometheus/prometheus-scrape-configuration/
+```
+
+- Deploy metrics exporters
+
+```bash
+kubectl -n monitoring apply -f utils/metrics-exporters/node-exporter/
+kubectl -n monitoring apply -f utils/metrics-exporters/kube-state-metrics/
+```
+
+- Deploy chaos-exporter when the cluster is not connected to litmus 2.0 control plane via litmus chaos delegate (exporter is installed as a part of the chaos delegate bundle)
+
+```bash
+kubectl -n litmus apply -f utils/metrics-exporters/litmus-metrics/chaos-exporter/
+```
+
+- Deploy Grafana
+
+```bash
+kubectl -n monitoring apply -f utils/grafana/
+```
+
+_You may access the grafana dashboard via the LoadBalancer (or NodePort) service IP or via a port-forward operation on localhost and then view it from manage dashboards section._
+
+> View the services running in the monitoring namespace
+
+```bash
+kubectl get svc -n monitoring
+```
+
+> Now copy the EXTERNAL-IP of grafana and view it in the browser
+
+Default username/password credentials: `admin/admin`
+
+### Screenshots
+
+#### Chaos Result selector dropdown:
+
+
+
+#### Chaos Engine Context (Target application's NAMESPACE_LABEL) selector dropdown:
+
+
+
+#### Chaos Engines with Experiments as Chaos Results:
+
+
+
+#### Chaos event annotations:
+
+
+
+#### Chaos Result verdict annotations:
+
+
+
+#### Interleaved Chaos events:
+
+
+
+#### Interleaved Chaos Result verdicts:
+
+
+
+#### Chaos Result verdict failure alerts:
+
+
+
+#### Chaos Result probe failure alerts:
+
+
+
+#### Systems healthy / in steady state OR no alerts to be issued:
+
+
+
+#### Systems un-healthy / failed to regain steady state after chaos / meet SLO OR alerts are issued:
+
+
+
+#### Alerts issued:
+
+
+
+## Chaos interleaving over infra and application metrics
+
+Chaos interleaving can be achieved using the `litmuschaos_awaited_experiments` and `litmuschaos_experiment_verdict` prometheus metrics which can be transformed using grafana variables and annotations into chaos injection events with metadata and results to monitor the application under test or infrastructure under test.
+
+> Sample variable configurations:
+
+_Queries:_
+
+**chaosresult_name**
+
+```json
+label_values(litmuschaos_awaited_experiments{app=~"chaos-exporter"}, chaosresult_name)
+```
+
+**chaosengine_context**
+
+```json
+label_values(litmuschaos_experiment_verdict{app=~"chaos-exporter"}, chaosengine_context)
+```
+
+#### Screenshots
+
+.default})
+Chaos result name variable
+.default})
+Chaos engine context variable
+.default})
+Chaos event annotation
+.default})
+Chaos metric annotation
+.default})
+Experiment verdict failure alert query
+.default})
+Experiment verdict failure alert configuration
+.default})
+Probe failure alert query
+.default})
+Probe failure alert configuration
+.default})
+Gauge metrics
+![]({require("../assets/introduction/community/CommunitySyncUp.webp").default})
+ ![]({require("../assets/introduction/community/CNCF.webp").default})
+ ![Core Principles]({require("../assets/introduction/core-principles/litmus-principles.png").default})
+
+Cloud Native Chaos Engineering, defined as engineering practices focused on (and built on) Kubernetes environments, applications, microservices, and infrastructure follows these core principles -
+
+## Driven by Open Source
+
+Cloud-native software provides the ideal platform for multi-cloud deployments because it is rooted in open-source standards established by the World Wide Web Consortium (W3C). Digital transformation requires real-time, event-driven data collection and the W3C βOne Webβ vision defines an ideal architecture for any data to run with any app across any W3C-compliant cloud.
+
+This principle focuses on the framework to be completely open-source under the Apache2 License to encourage broader community participation and inspection. The number of applications moving to the Kubernetes platform is limitless. At such a large scale, only the Open Chaos model will thrive and get the required adoption.
+
+## CRDs for Chaos Management
+
+Custom Resource Definition(CRD) is what you use to define a Custom Resource. This is a powerful way to extend Kubernetes capabilities beyond the default installation. These Kubernetes native CRDs defined here should be used as APIs for both Developers and SREs to build and orchestrate chaos testing. The CRDs act as standard APIs to provision and manage the chaos.
+
+## Extensible and Pluggable
+
+One lesson learned why cloud native approaches are winning is that their components can be relatively easily swapped out and new ones introduced as needed. Any standard chaos library or functionality developed by other open-source developers should be able to be integrated into and orchestrated for testing via this pluggable framework.
+
+## Broad Community Adoption
+
+Once we have the APIs, Operator, and plugin framework, we have all the ingredients needed for a common way of injecting chaos. The chaos will be run against a well-known infrastructure like Kubernetes or applications like databases or other infrastructure components like storage or networking. These chaos experiments can be reused, and a broad-based community is useful for identifying and contributing to other high-value scenarios. Hence a Chaos Engineering framework should provide a central hub or forge where open-source chaos experiments are shared, and collaboration via code is enabled.
+
+[Learn more about our community adoption](community.md)
+
+## GitOps for Chaos Management
+
+Use GitOps as an operational framework that takes DevOps best practices used for application development such as version control, collaboration, compliance, and CI/CD, and applies them to infrastructure automation. With the demands made on todayβs infrastructure, it has become increasingly crucial to implement infrastructure automation. Modern infrastructure needs to be elastic so that it can effectively manage cloud resources that are needed for continuous deployments.
diff --git a/website/versioned_docs/version-2.13.0/introduction/features.md b/website/versioned_docs/version-2.13.0/introduction/features.md
new file mode 100644
index 0000000..7cdc140
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/introduction/features.md
@@ -0,0 +1,82 @@
+---
+id: features
+title: Why should you choose Litmus?
+sidebar_label: Features
+---
+
+---
+
+The goal of the LitmusChaos project is to create a complete solution to implement chaos engineering at scale, the Kubernetes way! Of course, this had to be done incrementally by first creating a toolset for chaos injection and then adding additional features to make it a platform. Litmus 1.x achieved the goal of keeping it completely open-source, creating a [ChaosHub](../concepts/chaoshub.md) and the required CRDs, Operators, and Schedulers. With Litmus 1.x, users have a working chaos engineering toolset aligned with the original goals.
+
+Over time, with the monthly cadence releases and community engagement, we have added a lot of features and made LitmusChaos much easier for the end-users. With the launch of Litmus 2.0, a new way of chaos engineering can be performed by the users, a few high-level features are mentioned [below](features.md#advantages-of-litmus-20), however a detailed list can be found on the [release page](https://github.com/litmuschaos/litmus/releases).
+
+## Advantages of Litmus 2.0
+
+A high-level feature overview of Litmus 2.0 are as follows
+
+- The Addition of [Chaos Scenario](../concepts/chaos-workflow.md) creation, Chaos experiments become building blocks of a Chaos Scenario, to allow users to create a larger chaos scenario using sequential or parallel experiment executions.
+- Addition of [ChaosCenter](../getting-started/resources.md#chaoscenter) where you can take advantage of all these features and a lot more
+ - Chaos Scenario Creation
+
+ ![Chaos Testing in DevOps Cycle]({require("../assets/introduction/uses-of-litmus/chaos-test-devops.png").default})
+
+## Common Use Cases
+
+Typical use cases of Litmus include β failure or chaos testing in CI pipelines, increased chaos testing in staging and production and production environments, Kubernetes upgrades certification, post-upgrade validation of services, and resilience benchmarking, etc.
+
+- **For Developers:** To run chaos experiments during application development as an extension of unit testing or integration testing.
+- **For CI pipeline builders:** To run chaos as a pipeline stage to find bugs when the application is subjected to fail paths in a pipeline.
+- **For SREs:** To plan and schedule chaos experiments into the application and/or surrounding infrastructure. This practice identifies the weaknesses in the system and increases resilience.
+
+We keep hearing from SREs that they typically see a lot of resistance for introducing chaos from both developers and management. In the practice of chaos engineering, starting with small chaos tests and showing the benefits to developers and management will result in the initially required credibility. With time, the number of tests and associated resilience also will increase.
+
+![Overall Resilience]({require("../assets/introduction/uses-of-litmus/overall-resilience.png").default})
+
+Chaos Engineering is a practice. As seen above, with time, management buying and the SRE confidence will increase, and they move the chaos tests into production. This process will increase resilience metrics, as well.
+
+## Learn more
+
+- [Understand the Core Principles of Litmus](core-principles.md)
+- [Be a part of the Community](community.md)
+- [Get Started with Litmus](../getting-started/installation.md)
+- [Check out more resources about Litmus](other-links.md)
diff --git a/website/versioned_docs/version-2.13.0/introduction/what-is-litmus.md b/website/versioned_docs/version-2.13.0/introduction/what-is-litmus.md
new file mode 100644
index 0000000..4756775
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/introduction/what-is-litmus.md
@@ -0,0 +1,38 @@
+---
+id: what-is-litmus
+title: What is Litmus?
+sidebar_label: Litmus
+---
+
+---
+
+![Litmus Logo]({require("../assets/litmus-logo.png").default}){kind=logo}
+
+LitmusChaos is a Cloud-Native Chaos Engineering Framework with cross-cloud support. It is a CNCF Sandbox project with adoption across several organizations. Its mission is to help Kubernetes SREs and Developers to find weaknesses in both Non-Kubernetes as well as platforms and applications running on Kubernetes by providing a complete Chaos Engineering framework and associated Chaos Experiments.
+
+Litmus can be used to run chaos experiments initially in the staging environment and eventually in production to find bugs and vulnerabilities, fixing which leads to an increased resilience of the system. Litmus adopts a `Kubernetes-native` approach to define chaos intent in a declarative manner via custom resources.
+
+## Importance of Resilience
+
+![Importance Of Resilience]({require("../assets/introduction/litmus/importance-of-resilience.png").default})
+
+Kubernetes is being run on a variety of infrastructure, ranging from virtual machines to bare metal and a combination of them. The platformβs physical nature is a source of faults to the application that runs inside containers, as shown in the tip of the above diagram. The next layer of dependency is Kubernetes itself.
+
+Your application resilience really depends more on the underlying stack than your application itself. It is possible that once your application is stabilized, the resilience of your service that runs on Kubernetes depends on other components and infrastructure more than 90% of the time.
+
+Thus it is important to verify your application resilience whenever a change has happened in the underlying stack. **Keep verifying** is the key. Robust testing before upgrades is not good enough, mainly because you cannot possibly consider all sorts of faults during upgrade testing. This introduces the concept of Chaos Engineering. The process of "**continuously verifying** if your service is resilient against faults" is called Chaos Engineering.
+
+## What is a Chaos Experiment
+
+Chaos Experiments are fundamental units within the LitmusChaos architecture. Users can choose between readily available chaos experiments or create new ones to construct a required Chaos Scenario.
+
+## What is a Chaos Scenarios
+
+A chaos scenario is much more than a simple chaos experiment. It supports the user in defining the expected result, observing the result, analysing the overall system behaviour, and in the decision-making process if the system needs to be tuned for improving the resilience.
+
+## How to Contribute
+
+- If you are a first-time contributor, please see [Steps to Contribute](https://github.com/litmuschaos/litmus/blob/master/CONTRIBUTING.md#steps-to-contribute-).
+- If you would like to suggest new tests to be added to litmus, please go ahead and [create a new issue](https://github.com/litmuschaos/litmus/issues/new) describing your test. All you need to do is specify the workload type and the operations that you would like to perform on the workload.
+- If you would like to work on something more involved, please connect with the Litmus Contributors.
+- If you would like to make code contributions, all your commits should be signed with Developer Certificate of Origin. See [Sign your work](https://github.com/litmuschaos/litmus/blob/master/CONTRIBUTING.md#sign-your-work).
diff --git a/website/versioned_docs/version-2.13.0/litmusctl/chaos-workflow-creation.md b/website/versioned_docs/version-2.13.0/litmusctl/chaos-workflow-creation.md
new file mode 100644
index 0000000..f616d9b
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/litmusctl/chaos-workflow-creation.md
@@ -0,0 +1,131 @@
+---
+id: chaos-workflow-creation
+title: Create Scenarios using Litmusctl
+sidebar_label: Create Chaos Scenarios
+---
+
+---
+
+> Notes:
+>
+> - For litmusctl v0.10.0 or latest
+> - Compatible with Litmus 2.9.0 or latest
+
+### litmusctl Syntax
+
+`litmusctl` has a syntax to use as follows:
+
+```shell
+litmusctl [command] [TYPE] [flags]
+```
+
+- Command: refers to what you do want to perform (create, get and config)
+- Type: refers to the feature type you are performing a command against (chaos delegate, project etc.)
+- Flags: It takes some additional information for resource operations. For example, `--installation-mode` allows you to specify an installation mode.
+
+Litmusctl is using the `.litmusconfig` config file to manage multiple accounts
+
+1. If the --config flag is set, then only the given file is loaded. The flag may only be set once and no merging takes place.
+2. Otherwise, the ${HOME}/.litmusconfig file is used, and no merging takes place.
+
+---
+
+### Steps to create a Chaos Scenario
+
+- To setup an account with litmusctl
+
+```shell
+litmusctl config set-account --endpoint="" --username="" --password=""
+```
+
+- To create a Chaos Scenario by passing a manifest file
+ > Note:
+ >
+ > - To get `project-id`, apply `litmusctl get projects`
+ > - To get `chaos-delegate-id`, apply `litmusctl get chaos-delegates --project-id=""`
+
+```shell
+litmusctl create chaos-scenario -f custom-chaos-scenario.yml --project-id="" --chaos-delegate-id=""
+```
+
+#### Verify the new Chaos Scenario
+
+To verify the successful creation, you can either view the list of chaos scenarios at the ChaosCenter dashboard or run the below given command to list the chaos scenarios within a given project.
+
+```shell
+litmusctl get chaos-scenarios --project-id=""
+```
+
+**Output:**
+
+```
+CHAOS SCENARIO ID CHAOS SCENARIO NAME CHAOS SCENARIO TYPE NEXT SCHEDULE CHAOS DELEGATE ID CHAOS DELEGATE NAME LAST UPDATED BY
+9433b48c-4ab7-4544-8dab-4a7237619e09 custom-chaos-scenario-1627980541 Non Cron Scenario None f9799723-29f1-454c-b830-ae8ba7ee4c30 Self-Chaos-Delegate admin
+Showing 1 of 1 chaos scenarios
+```
+
+---
+
+### Additional commands
+
+- To list all the chaos scenario runs within a project, issue the following command.
+
+```shell
+litmusctl get chaos-scenario-runs --project-id=""
+```
+
+**Output:**
+
+```
+CHAOS SCENARIO RUN ID STATUS RESILIENCY SCORE CHAOS SCENARIO ID CHAOS SCENARIO NAME TARGET CHAOS DELEGATE LAST RUN EXECUTED BY
+8ceb712c-1ed4-40e6-adc4-01f78d281506 Running 0.00 9433b48c-4ab7-4544-8dab-4a7237619e09 custom-chaos-scenario-1627980541 Self-Chaos-Delegate June 1 2022, 10:28:02 pm admin
+Showing 1 of 1 scenario runs
+```
+
+- To describe a particular chaos scenario, issue the following command.
+
+```shell
+litmusctl describe chaos-scenario 9433b48c-4ab7-4544-8dab-4a7237619e09 --project-id=""
+```
+
+**Output:**
+
+```
+apiVersion: argoproj.io/v1alpha1
+kind: Workflow
+metadata:
+ creationTimestamp: null
+ labels:
+ cluster_id: f9799723-29f1-454c-b830-ae8ba7ee4c30
+ subject: custom-chaos-scenario_litmus
+ workflow_id: 9433b48c-4ab7-4544-8dab-4a7237619e09
+ workflows.argoproj.io/controller-instanceid: f9799723-29f1-454c-b830-ae8ba7ee4c30
+ name: custom-chaos-scenario-1627980541
+ namespace: litmus
+spec:
+...
+```
+
+- To delete a particular chaos scenario, issue the following command.
+
+```shell
+litmusctl delete chaos-scenario df91c6b2-ad33-45ae-9a2f-00cb87978657 --project-id=""
+```
+
+**Output:**
+
+```
+π Chaos scenario successfully deleted.
+```
+
+For more information related to flags, Use `litmusctl --help`.
+
+---
+
+## Learn More
+
+- [Learn More about Litmusctl](installation.md)
+- [Installing Chaos Delegate in interactive mode](./usage-interactive-mode.md)
+- [Installing Chaos Delegate in non interactive mode](./usage-non-interactive-mode.md)
+- [Setup Endpoints and Access ChaosCenter without Ingress](../user-guides/setup-without-ingress.md)
+- [Setup Endpoints and Access ChaosCenter with Ingress](../user-guides/setup-with-ingress.md)
diff --git a/website/versioned_docs/version-2.13.0/litmusctl/installation.md b/website/versioned_docs/version-2.13.0/litmusctl/installation.md
new file mode 100644
index 0000000..617b19a
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/litmusctl/installation.md
@@ -0,0 +1,223 @@
+---
+id: installation
+title: Litmusctl
+sidebar_label: Installation
+---
+
+---
+
+The Litmuschaos command-line tool, litmusctl, allows you to manage litmuschaos's chaos delegate plane. You can use litmusctl to connect and disconnect chaos delegates, create chaos scenarios, project, and manage multiple litmuschaos accounts.
+
+## Prerequisites
+
+Litmusctl CLI requires the following things:
+
+- **kubeconfig** - litmusctl needs the kubeconfig of the k8s cluster where we need to connect litmus chaos delegates. The CLI currently uses the default path of kubeconfig i.e. `~/.kube/config`.
+- **kubectl** - litmusctl is using kubectl under the hood to apply the manifest.
+ > To install kubectl, follow: [kubectl](https://kubernetes.io/docs/tasks/tools/#kubectl)
+
+## Usage
+
+For more information including a complete list of litmusctl operations, see the litmusctl reference documentation.
+
+- For v0.12.0 or latest: Click here
+- For v0.2.0 or earlier: Click here
+
+## Compatibility matrix
+
+To check compatibility of litmusctl with Chaos Center
+
+.default})
+
+Once accepted, you can switch to the project using the header or the `View Project` option as shown below:
+
+.default})
diff --git a/website/versioned_docs/version-2.13.0/user-guides/account-settings.md b/website/versioned_docs/version-2.13.0/user-guides/account-settings.md
new file mode 100644
index 0000000..35ea6fa
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/user-guides/account-settings.md
@@ -0,0 +1,38 @@
+---
+id: account-settings
+title: Account Settings
+sidebar_label: Account Settings
+---
+
+---
+
+Under the `My Account` tab, you can change your personal details such as the email, full name, and password.
+
+> Note: The username canβt be changed as it is unique.
+
+## Edit Personal Details
+
+Enter your name and your email address in the following text fields and click on the `Save Changes` button.
+
+.default})
+
+Once done successfully, youβll be getting a modal indicating a successful completion of the operation.
+
+.default})
+
+## Change Password
+
+On the same page, you can change your password by providing your current as well as your new password and then click on the `Change Password` button.
+
+.default})
+
+> Note: If you have forgotten your password, please contact your admin to reset your password
+
+On successful completion, youβll be getting a modal indicating that the password has been changed.
+
+.default})
+
+## Learn more
+
+- [Create a new user](create-user.md)
+- [View users and their details](view-user.md)
diff --git a/website/versioned_docs/version-2.13.0/user-guides/air-gapped.md b/website/versioned_docs/version-2.13.0/user-guides/air-gapped.md
new file mode 100644
index 0000000..b7ec55c
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/user-guides/air-gapped.md
@@ -0,0 +1,9 @@
+---
+id: air-gapped
+title: Run Litmus in Air-gapped Environments
+sidebar_label: Air Gapped Environment
+---
+
+---
+
+## Coming soon
diff --git a/website/versioned_docs/version-2.13.0/user-guides/analyze-workflow.md b/website/versioned_docs/version-2.13.0/user-guides/analyze-workflow.md
new file mode 100644
index 0000000..d2b24d6
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/user-guides/analyze-workflow.md
@@ -0,0 +1,59 @@
+---
+id: analyze-workflow
+title: Analyzing a Chaos scenario
+sidebar_label: Analyzing Chaos Scenario
+---
+
+---
+
+Chaos Scenario Analytics allows you to analyze their chaos scenarios (Recurring/ Nonrecurring) & helps them to keep track of the chaos scenario runs of scheduled chaos scenarios and their behaviour.
+
+## Chaos Scenario Details
+
+On the chaos scenario analytics page, in the first container, you will be able to see the details about the selected chaos scenario such as the chaos scenario name, chaos scenario id, chaos delegate details(name, namespace, etc.), and the chaos scenario run details like the last run as well as regularity.
+
+.default})
+
+## Chaos Scenario Statistics
+
+On clicking on **show statistics**, you will be able to see the experiment statistics, average resiliency score and pass/fail ratio for the chaos scenarios/experiments.
+
+.default})
+
+:::note
+
+If the selected chaos scenario is recurring or is re-run multiple times, then the average resiliency score for all the chaos scenario runs is shown. A drop-down has been provided to switch between chaos scenarios & experiments for checking the pass/fail ratio.
+
+:::
+
+.default})
+
+## Chaos Scenario Heatmap
+
+If the selected chaos scenario is recurring or is re-run multiple times, a heat map representing the days of the year showing all the chaos scenario runs for the selected chaos scenario can be observed. On hovering over a point in the heat map, the average resiliency score for that particular day will be shown in the form of a tool-tip.
+
+.default})
+
+## Chaos Scenario Activity
+
+On clicking on a heat map entry, a stacked bar graph representing the pass/fail ratio is shown, on which you can see the chaos scenario runs on that day and hover over the bars to see the resiliency for that particular chaos scenario run on that day.
+
+.default})
+
+:::info
+
+You can check Pass Count, Fail Count of Experiments & Resiliency Score by hovering over the bar for that chaos scenario run.
+
+:::
+
+## Experiments Table
+
+On clicking on a bar, more details about the chaos scenario run represented by that stacked bar are presented in a tabular format. A table having individual experiments details is presented to the user, which helps them to get insights about the experiments.
+
+.default})
+
+## Learn more
+
+- [Compare Chaos Scenarios](comparative-analysis.md)
+- [Manage Application Dashboard](manage-app-dashboard.md)
+- [Configure Datasource](configure-datasource.md)
diff --git a/website/versioned_docs/version-2.13.0/user-guides/change-project-name.md b/website/versioned_docs/version-2.13.0/user-guides/change-project-name.md
new file mode 100644
index 0000000..380727e
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/user-guides/change-project-name.md
@@ -0,0 +1,38 @@
+---
+id: change-project-name
+title: Changing Project Name
+sidebar_label: Change Project Name
+---
+
+---
+
+Owners have the ability to change the name of their project if they wish to do so.
+
+## Before you begin
+
+The concept of `Projects` is discussed [here](../concepts/projects.md) and will help you build a foundational understanding of what projects mean in the ChaosCenter.
+
+## Steps
+
+### 1. Go to `My Project`
+
+Go to the `Team` section of settings and scroll to the `My project` section:
+
+.default})
+
+### 2. Enter edit mode
+
+Click on either the text (demonstrated in this example as `adminβs project`) or on the edit icon next to it to enter the edit mode:
+
+.default})
+
+### 3. Replace name
+
+Once in the editing mode, type out the name you want to replace the current name with, and click away anywhere in the screen. You will notice that the name of the project has been changed in the `My Project` section as well as the header of the portal.
+
+.default})
+
+## Learn more
+
+- [Invite a member to your project](invite-team-member.md)
+- [Remove a member from your project](remove-team-member.md)
diff --git a/website/versioned_docs/version-2.13.0/user-guides/chaosagents-installation.md b/website/versioned_docs/version-2.13.0/user-guides/chaosagents-installation.md
new file mode 100644
index 0000000..3aeb0ba
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/user-guides/chaosagents-installation.md
@@ -0,0 +1,71 @@
+---
+id: chaosagents-installation
+title: Chaos Delegate Installation
+sidebar_label: Chaos Delegate
+---
+
+---
+
+## Prerequisites
+
+- Before connecting a Chaos Delegate to the [ChaosCenter](../getting-started/resources.md#chaoscenter), learn about what is a [Chaos Delegate](../getting-started/resources.md#chaosagents) in Litmus.
+- Make sure [litmusctl](../litmusctl/installation.md) is installed.
+
+## Connecting Chaos Delegate
+
+- Learn to [connect Chaos Delegate with non interactive mode using litmuctl](../litmusctl/usage-non-interactive-mode.md)
+- Learn to [connect Chaos Delegate with interactive mode using litmuctl](../litmusctl/usage-interactive-mode.md)
+
+## Resource Requiremenets for Chaos Delegate plane components
+
+The Resource requests provided here have been estimated using data gathered manually through different methods -
+
+- Using command `kubectl top`
+- Recommendations from Vertical-Pod-Autoscaler
+- Recommendations by a great utility [Goldilocks](https://github.com/FairwindsOps/goldilocks).
+
+These resources are getting monitored continuously and the information below will be updated as the metrics changes.
+
+.default})
+.default})
+
+Similarily, In other tab, you can also compare schedules according to selected granuality.
+
+.default})
+.default})
+
+:::info
+
+You can hover over the respective graphs to get the total chaos scenario runs & total schedules respectively.
+
+:::
+
+## Total Chaos Scenario Statistics
+
+Total Chaos Scenario Statistics helps you to see how many of their scheduled have been passing/ failing & running. This helps you to see average performance of all the chaos scenario runs.
+
+.default})
+
+## Comparing Multiple Scenarios
+
+List of chaos scenarios provided on the page helps you to keep track of their scheduled chaos scenarios along with associated details like chaos scenario name, chaos delegate, starting time,etc & allows to compare the chaos scenarios by selecting them from the table.
+
+.default})
+
+For comparing the chaos scenarios, you can select the scenarios from the table & click on _**Compare Chaos Scenario**_ button.
+
+.default})
+
+Once, user clicks on _**Compare Chaos Scenario**_ button, they will be presented with a graph, which shows comparison of selected chaos scenarios with respect to resilience score.
+
+.default})
+
+You can change the granuality by clicking on drop-down in top right corner. We can choose between Hourly/ Daily/ Monthly.
+
+.default})
+
+:::note
+
+By hovering over the dots on comparison graph, you can see the resiliency score of compared chaos scenarios & also average chaos scenarios.
+
+:::
+
+.default})
+
+The Comparison report can be downloaded in PDF form using the _**export button**_ given in header of table.
+
+.default})
+
+> **Sample chaos scenario comparison report can be downloaded from [here](../assets/chaos-center-analytics.pdf)**
+
+## Learn more
+
+- [Configure Datasource](configure-datasource.md)
+- [See Chaos Scenario Analytics](analyze-workflow.md)
+- [Manage Application Dashboard](manage-app-dashboard.md)
diff --git a/website/versioned_docs/version-2.13.0/user-guides/configure-datasource.md b/website/versioned_docs/version-2.13.0/user-guides/configure-datasource.md
new file mode 100644
index 0000000..68539ca
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/user-guides/configure-datasource.md
@@ -0,0 +1,93 @@
+---
+id: configure-datasource
+title: Configuring a Datasource
+sidebar_label: Configure Datasource
+---
+
+---
+
+Litmus 2.0 provides in-house monitoring support which can be leveraged by connecting a data source to the chaos center, configured to scrape chaos event metics and application or infrastructure metics.
+
+### Before you begin
+
+To configure a data source for a chaos center project, you must first setup the data source. To learn more about data source setup [click here](setup-datasource.md)
+
+### Connecting a data source
+
+- Click on the `Observability` section from the sidebar then switch to the `Data Source` tab. Click the `Add data source` button to open the data source connection form.
+
+The _first page_ of the form requires the user to provide the general details, It also has a link to documentation around setting up a Prometheus data source (Litmus center supports Prometheus 2.1 or later) to collect chaos events and metrics along with generic node-exporter and kube-state-metrics. Form fields on page 1 for data source connection:
+
+- **Data source name** - alias.
+- **Data source type** - defaults to Prometheus in Litmus 2.0.
+- **Data source endpoint URL** - IP OR Host along with port number. The user can also use the Kubernetes DNS provided and kubelet configured fully qualified domain name (FQDN) with port for prometheus server service, prefixed with `http://` to connect a data source hosted on the control plane cluster for a secure internal connection on K8s.
+ (Ex. - http://prometheus-k8s.monitoring.svc.cluster.local:9090)
+- **Access type** - defaults to Server.
+
+.default})
+Data source connection form page - 1
+.default})
+Data source connection form page - 2
+.default})
+Data sources tab
+.default})
+Data source configuration screen
+.default})
+Data source deletion confirmation
+.default})
+Data source force delete
+.default})
+
+## 2. Add the details of the new user
+
+Add all the details of the user to be created and hit the `Create` button.
+
+.default})
+
+## 3. Confirmation of creation
+
+The user is created and you will receive a confirmation modal.
+
+.default})
+
+You will now be able to view the new user in the table in the user management tab.
+
+## Learn more
+
+- [View users](view-user.md)
+- [Reset the password of a user](reset-password.md)
+- [Deactivate a user](deactivate-user.md)
diff --git a/website/versioned_docs/version-2.13.0/user-guides/deactivate-user.md b/website/versioned_docs/version-2.13.0/user-guides/deactivate-user.md
new file mode 100644
index 0000000..78baf21
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/user-guides/deactivate-user.md
@@ -0,0 +1,31 @@
+---
+id: deactivate-user
+title: Deactivate a User
+sidebar_label: Deactivate User
+---
+
+---
+
+The Account of a created user can be deactivated if required. Once the user is deactivated, the user wonβt be able to log in or access any of the APIs. Along with this, the project in which the user was the owner of will also get deactivated and everyone who is a member of the project will lose access to that project. Admin can also reactivate the account of a deactivated user. Once the user is reactivated, complete data will get restored.
+
+## 1. Locate and deactivate the user
+
+In the user management tab, locate the user account that you'd like to deactivate and click on the horizontal options icon.
+
+.default})
+
+## 2. Confirm the user is deactivated
+
+Once deactivated, the indicator next to the user's username in the usermanagement table will turn gray.
+
+.default})
+
+## 3. Re-activate a user (Optional step)
+
+Similarly, the admin can re-activate the user from the same drop-down menu as shown:
+
+.default})
+
+## Learn more
+
+- [View users](view-user.md)
diff --git a/website/versioned_docs/version-2.13.0/user-guides/delete-workflow.md b/website/versioned_docs/version-2.13.0/user-guides/delete-workflow.md
new file mode 100644
index 0000000..66cb2d5
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/user-guides/delete-workflow.md
@@ -0,0 +1,43 @@
+---
+id: delete-workflow
+title: Delete a Chaos Scenario
+sidebar_label: Delete Chaos Scenario
+---
+
+---
+
+If required, it is possible to delete a chaos scenario schedule that you no longer wish to run against your application.
+
+:::note
+This also means that all the runs corresponding to that chaos scenario will also be deleted.
+:::
+
+## Before you begin
+
+You can learn about the concept of chaos scenarios [here](../concepts/chaos-workflow.md) and how to schedule your first chaos scenario [here](schedule-workflow.md).
+
+## 1. Go to the chaos scenarios sections
+
+In the `Chaos Scenario` page, go to the `Schedules` tab and click on the options menu for the specific schedule you wish to delete:
+
+.default})
+
+## 2. Click on the `Delete chaos scenario` option
+
+After opening the options menu and clicking on the `Delete chaos scenario` option, you'll see a prompt in order to confirm your action. Please ensure that you want to delete the selected chaos scenario and click the `Delete` button:
+
+.default})
+
+## 3. The Chaos Scenario has been deleted
+
+You will observe that the chaos scenario no longer appears in the list of schedules and has been removed.
+
+.default})
+
+As stated above, we observe that the runs have been removed as well.
+
+.default})
+
+## Learn more
+
+- [schedule a chaos scenario](schedule-workflow.md)
diff --git a/website/versioned_docs/version-2.13.0/user-guides/download-workflow-manifest.md b/website/versioned_docs/version-2.13.0/user-guides/download-workflow-manifest.md
new file mode 100644
index 0000000..ce53bd2
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/user-guides/download-workflow-manifest.md
@@ -0,0 +1,31 @@
+---
+id: download-workflow-manifest
+title: Download Chaos Scenario Manifest
+sidebar_label: Download Chaos Scenario Manifest
+---
+
+---
+
+You can save a schedule configurations manifest as a `YAML`. This section goes over the steps to achieve the same.
+
+## Before you begin
+
+You can learn how to schedule your first chaos scenario [here](schedule-workflow.md).
+
+## 1. Go to the chaos scenarios sections
+
+In the `Chaos Scenario` page, go to the `Schedules` tab and click on the options menu for the specific schedule you wish to download the manifest for:
+
+.default})
+
+## 2. Click on the `Download Manifest` option
+
+After opening the options menu, click on the `Download Manifest` option. Having downloaded a particular schedule manifest, you can see the browser downloads list to see the status of the manifest download operation and then see the `YAML` file in your system's default download directory:
+
+.default})
+
+## Learn more
+
+- [Schedule a chaos scenario](schedule-workflow.md)
+- [Re-run a chaos scenario](re-run-workflow.md)
+- [Delete a chaos scenario](delete-workflow.md)
diff --git a/website/versioned_docs/version-2.13.0/user-guides/edit-invite.md b/website/versioned_docs/version-2.13.0/user-guides/edit-invite.md
new file mode 100644
index 0000000..3fe415a
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/user-guides/edit-invite.md
@@ -0,0 +1,17 @@
+---
+id: edit-invite
+title: Edit or Cancel an invite
+sidebar_label: Edit/Cancel invite
+---
+
+---
+
+If you had a change of mind and you wanted to change the role of an invitation that has been already sent, we got you!
+
+Just go to the invited tab, change the role, and hit the `Resend` button. You can also cancel the invitation by just clicking on the `bin` icon.
+
+.default})
+
+## Learn more
+
+- [Accept an invitation](accept-invite.md)
diff --git a/website/versioned_docs/version-2.13.0/user-guides/edit-schedule.md b/website/versioned_docs/version-2.13.0/user-guides/edit-schedule.md
new file mode 100644
index 0000000..b3c066e
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/user-guides/edit-schedule.md
@@ -0,0 +1,52 @@
+---
+id: edit-schedule
+title: Edit Chaos Scenario Schedule
+sidebar_label: Edit Chaos Scenario Schedule
+---
+
+---
+
+## Before you begin
+
+You must schedule a chaos scenario. To know more about scheduling chaos scenarios click [here](schedule-workflow.md)
+
+---
+
+After you have scheduled a chaos scenario, you might have a need of changing the schedule of a recurring chaos scenario. To edit the schedule follow these steps:
+
+## 1. Select edit schedule from the menu
+
+In the `Schedules` tab of `Litmus Chaos Scenarios` page you can click on the triple dots of the schedule to access more options for it. From the menu select the `Edit Schedule` option.
+
+.default})
+Selecting Edit Schedule from the Menu
+.default})
+Summary of the Chaos Scenario with Edit button
+.default})
+Editing the Schedule
+.default})
+Create dashboard, Tune the queries step
+.default})
+Adding a panel
+.default})
+Editing a query
+.default})
+Visualization options
+.default})
+ .default})
+ .default})
+.default})
+.default})
+
+.default})
+
+## 2. Select all the members to be invited
+
+From the list of all available members, choose the ones you want to collaborate on your chaos with and decide what project level access they should have to your project (Viewer/Editor) and hit the `Send Invite` button.
+
+.default})
+
+## 3. Collaborate over the chaos!
+
+On successful invitation you will receive the confirmation dialog as shown below indicating selected members have been invited to your project.
+
+.default})
+
+## Learn more
+
+- [Edit an invitation](edit-invite.md)
+- [Accept invite](accept-invite.md)
diff --git a/website/versioned_docs/version-2.13.0/user-guides/leave-project.md b/website/versioned_docs/version-2.13.0/user-guides/leave-project.md
new file mode 100644
index 0000000..e84d23b
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/user-guides/leave-project.md
@@ -0,0 +1,24 @@
+---
+id: leave-project
+title: Leave a Project
+sidebar_label: Leave Project
+---
+
+---
+
+You can leave a project that you no longer wish to be a part of.
+
+## 1. Identify the project you want to leave
+
+In the settings page, scroll to the very bottom of the `Team` tab. Here you will see a list of all the projects you are a part of, identify the project youβd like to leave and click on the `Leave Project` button:
+
+.default})
+
+> Note: Having left the project, the number of active projects will change and the project you left can no longer be observed as a currently active project in the `Team` tab
+
+.default})
+
+## Learn more
+
+- [Invite a member to your project](invite-team-member.md)
+- [Remove a member from your project](remove-team-member.md)
diff --git a/website/versioned_docs/version-2.13.0/user-guides/manage-app-dashboard.md b/website/versioned_docs/version-2.13.0/user-guides/manage-app-dashboard.md
new file mode 100644
index 0000000..4fae3cc
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/user-guides/manage-app-dashboard.md
@@ -0,0 +1,93 @@
+---
+id: manage-app-dashboard
+title: Creating and Updating an Application Dashboard
+sidebar_label: Manage Application Dashboard
+---
+
+---
+
+Observing chaos injections and deriving insights from the chaos events is the core part of Chaos Observability. Whenever a chaos scenario run is performed its impact may be observed across different services and applications. Application dashboards provide a systematic visualization of all such events along with the performance of the individual service/application. To learn more about the dashboard schema architecture [click here](https://raw.githubusercontent.com/litmuschaos/litmus/master/monitoring/portal-dashboards/schema.json)
+
+## Before you begin
+
+To configure an application dashboard, you must first add a data source. To learn more about data sources [click here](configure-datasource.md)
+
+- If no data source is available, a banner on the application dashboard tab requests you to add it before configuring a dashboard.
+
+.default})
+Application dashboard with no configured data source
+.default})
+Application dashboard table with a configured dashboard
+.default})
+Creating a dashboard
+.default})
+Select dashboard type
+.default})
+Configuring the metadata of the dashboard
+.default})
+Selecting applications
+.default})
+Selecting the required metrics
+.default})
+Overview page, When no chaos scenarios are running
+.default})
+Overview page, When some chaos scenarios have been already scheduled
+.default})
+
+Now, you will get a banner with an option to add a dashboard for visualizing the data from the connected data sources.
+
+After setting up the dashboard, you will be able to see the dashboard on the overview page.
+
+.default})
+
+You can view, configure & download the dashboards in the form of JSON for reusability using provided buttons.
+
+You can check the chaos scenario analytics and the chaos scenario run graph by clicking on _**see chaos scenario run**_ & _**see chaos scenario analytics**_ icons for a chaos scenario from the list of chaos scenario dashboards present on the overview page.
+
+## Learn more
+
+- [Analyze a Chaos Scenario](analyze-workflow.md)
+- [Configure Datasource](configure-datasource.md)
+- [Manage Application Dashboard](manage-app-dashboard.md)
diff --git a/website/versioned_docs/version-2.13.0/user-guides/observe-workflow.md b/website/versioned_docs/version-2.13.0/user-guides/observe-workflow.md
new file mode 100644
index 0000000..a86fe9c
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/user-guides/observe-workflow.md
@@ -0,0 +1,112 @@
+---
+id: observe-workflow
+title: Observe Chaos Scenario
+sidebar_label: Observe Chaos Scenario
+---
+
+---
+
+## Before you begin
+
+You must schedule a chaos scenario. To know more about scheduling chaos scenarios click [here](schedule-workflow.md)
+
+---
+
+After scheduling a chaos scenario, you can track the status of the chaos scenario run from the `Runs` tab in the `Litmus Chaos Scenario`. The status that is currently displayed are:
+
+- Failed
+- Running
+- Completed
+
+.default})
+Chaos Scenario Runs Table showing a Running Chaos Scenario
+.default})
+Graph of Podtato Head chaos scenario
+.default})
+Graph of a non Chaos Scenario
+.default})
+Podtato Head chaos scenario with Logs
+.default})
+Podtato Head chaos scenario with chaos logs and chaos result of generic/pod-delete experiment
+.default})
+
+## 2. Click on the `Rerun Schedule` option
+
+After opening the options menu, click on the `Rerun Schedule` option. Having re-run a particular schedule, you can switch to the `Runs` tab and see that it has started to re-run as per the schedule configurations:
+
+.default})
+
+## Learn more
+
+- [Schedule a chaos scenario](schedule-workflow.md)
+- [Delete a chaos scenario](delete-workflow.md)
diff --git a/website/versioned_docs/version-2.13.0/user-guides/remove-team-member.md b/website/versioned_docs/version-2.13.0/user-guides/remove-team-member.md
new file mode 100644
index 0000000..1f02bf4
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/user-guides/remove-team-member.md
@@ -0,0 +1,23 @@
+---
+id: remove-team-member
+title: Remove a Team Member
+sidebar_label: Remove Team Member
+---
+
+---
+
+If you are the project owner, you have the ability to remove any members from your project as required.
+
+## Steps
+
+### 1. Identify the member to remove
+
+In the `Team` tab in the settings page, scroll down to the `My project` table, here you will be able to see all the members who have their invitation status as `accepted` for your project collaboration invite. Here, identify the user to remove and click on the red `Remove` bin icon as shown.
+
+.default})
+
+### 2. Confirmation for removal
+
+On hitting the `Remove` icon, you will be prompted to confirm the removal of the member, hit `Yes` to confirm and remove the member from your project.
+
+.default})
diff --git a/website/versioned_docs/version-2.13.0/user-guides/reset-password.md b/website/versioned_docs/version-2.13.0/user-guides/reset-password.md
new file mode 100644
index 0000000..5bb19cd
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/user-guides/reset-password.md
@@ -0,0 +1,25 @@
+---
+id: reset-password
+title: Reset Password of a User
+sidebar_label: Reset Password
+---
+
+---
+
+The admin has the ability to reset the login password for any user in the portal.
+
+## 1. Locate the user
+
+Under the `User management` tab find the user who's password needs to be updated and click on the options icon to open a drop-down and select `Edit Profile` option
+
+.default})
+
+## 2. Change the password
+
+In the `Login Details` section select the `New password` input field and type in the new password. Once done hit the `Save` button to update the password.
+
+.default})
+
+## Learn more
+
+- [View users](view-user.md)
diff --git a/website/versioned_docs/version-2.13.0/user-guides/save-as-template.md b/website/versioned_docs/version-2.13.0/user-guides/save-as-template.md
new file mode 100644
index 0000000..c021834
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/user-guides/save-as-template.md
@@ -0,0 +1,43 @@
+---
+id: save-as-template
+title: Save Chaos Scenarios as a Template
+sidebar_label: Save Chaos Scenarios as Template
+---
+
+---
+
+You can save a schedule as a template for later usage in subsequent schedules. This section goes over the steps to achieve the same.
+
+## Before you begin
+
+You can learn how to schedule your first chaos scenario [here](schedule-workflow.md).
+
+## 1. Go to the chaos scenarios sections
+
+In the `Chaos Scenario` page, go to the `Schedules` tab and click on the options menu for the specific schedule you wish to save as a template:
+
+.default})
+
+## 2. Click on the `Save Template` option
+
+After opening the options menu, click on the `Save Template` option. You will see the following modal popup. Here you can edit the chaos scenario `YAML` and provide a name and description for the template you are creating:
+
+.default})
+
+## 3. Save the changes
+
+After having made all the changes you wish to preserve as a template, click the `Save Changes` button to save your template.
+
+.default})
+
+## 4. Use your new template
+
+You can now see your template under the `Create a new chaos scenario by cloning an existing chaos scenario` option in the chaos scenario scheduling steps and can directly use it for your chaos.
+
+.default})
+
+## Learn more
+
+- [Schedule a chaos scenario](schedule-workflow.md)
+- [Re-run a chaos scenario](re-run-workflow.md)
+- [Delete a chaos scenario](delete-workflow.md)
diff --git a/website/versioned_docs/version-2.13.0/user-guides/schedule-workflow.md b/website/versioned_docs/version-2.13.0/user-guides/schedule-workflow.md
new file mode 100644
index 0000000..058965e
--- /dev/null
+++ b/website/versioned_docs/version-2.13.0/user-guides/schedule-workflow.md
@@ -0,0 +1,155 @@
+---
+id: schedule-workflow
+title: Schedule a Chaos Scenario
+sidebar_label: Schedule Chaos Scenario
+---
+
+---
+
+## Before you begin
+
+You must connect an Chaos Delegate before scheduling a chaos scenario . There might be a default `Self Chaos Delegate` automatically created or you can [connect an external Chaos Delegate ](../litmusctl/installation.md).
+
+---
+
+Click on the **Schedule a chaos scenario ** button on the home page or **Schedule chaos scenario ** button in Litmus Chaos Scenarios page to get started.
+
+.default})
+Home Page
+.default})
+Selecting a Chaos Delegate
+.default})
+Choosing a Chaos Scenario
+.default})
+Change name and description
+.default})
+Tuning a Predefined Chaos Scenario (Podtato Head)
+.default})
+Editing Experiment Sequence
+.default})
+Adding Experiments to Chaos Scenario (Available after choosing a Hub in previous step)
+.default})
+.default})
+Adjust Experiment Weights
+.default})
+Scheduling a Cron Chaos Scenario
+.default})
+View Summary and Commit
+.default})
+Data flow and topological diagram
+.default})
+Data flow and topological diagram
+.default})
+Data flow and topological diagram
+![Disconnect Icon]({require("../assets/user-guides/uninstall-litmus/disconnect-icon.png").default}){kind=icon}
of the respective Chaos Delegate you want to disconnect.
+4. On the Modal that appears, confirm your selection by clicking `Yes` and the selected Chaos Delegate would be disconnected from the ChaosCenter.
+ :::note
+ The above disconnect would remove the subscriber component from Chaos Delegate and thus removing the connectivity between the Chaos Delegate and the ChaosCenter.
+
+ If the Chaos Delegate is not reachable it would remove only the entry from the database of the ChaosCenter
+ :::
+
+### Remove the CRs
+
+To remove the CRs Litmus uses, use the following command:
+
+- To remove individual CRs
+
+```bash
+kubectl delete chaosexperiments .default})
+
+Alternatively you can run the following command using litmusctl in the cluster containing the chaos delegate by providing `.default})
+Viewing particular application dashboard
+.default})
+Viewing the information related to the dashboard
+.default})
+Viewing more options
+.default})
+Creating a copy of the dashboard
+.default})
+Setting up refersh rate for the dashboard
+.default})
+View individulal graph in modal
+.default})
+Selecting/deselecting chaos metric
+.default})
+Editing chaos metric queries
+.default})
+
+## Learn more
+
+- [Create a user](create-user.md)
+- [Reset the password of a user](reset-password.md)
+- [Deactivate a user](deactivate-user.md)
diff --git a/website/versioned_sidebars/version-2.13.0-sidebars.json b/website/versioned_sidebars/version-2.13.0-sidebars.json
new file mode 100644
index 0000000..8624610
--- /dev/null
+++ b/website/versioned_sidebars/version-2.13.0-sidebars.json
@@ -0,0 +1,160 @@
+{
+ "docs": [
+ {
+ "Introduction": [
+ "introduction/what-is-litmus",
+ "introduction/features",
+ "introduction/usage",
+ "introduction/core-principles",
+ "introduction/community",
+ "introduction/other-links"
+ ]
+ },
+ {
+ "Getting Started": [
+ "getting-started/resources",
+ "getting-started/installation",
+ "getting-started/run-your-first-workflow"
+ ]
+ },
+ {
+ "Architecture": [
+ "architecture/overview",
+ "architecture/architecture-summary",
+ "architecture/chaos-control-plane",
+ "architecture/chaos-execution-plane",
+ "architecture/chaos-experiment-flow",
+ {
+ "Chaos Observability Flow": [
+ "architecture/chaos-observability-flow-overview",
+ "architecture/chaos-observability-flow-visualization",
+ "architecture/chaos-observability-flow-logging",
+ "architecture/chaos-observability-flow-monitoring",
+ "architecture/chaos-observability-flow-summarisation",
+ "architecture/chaos-observability-flow-analytics"
+ ]
+ }
+ ]
+ },
+ {
+ "Concepts": [
+ "concepts/overview",
+ "concepts/chaos-experiment",
+ "concepts/probes",
+ "concepts/chaos-engine",
+ "concepts/chaos-result",
+ "concepts/chaoshub",
+ {
+ "Chaos Scenario": [
+ "concepts/chaos-workflow",
+ "concepts/visualize-workflow"
+ ]
+ },
+ {
+ "Observability": [
+ "concepts/workflow-statistics",
+ "concepts/app-infra-monitoring",
+ "concepts/datasource",
+ "concepts/open-observability"
+ ]
+ },
+ "concepts/user-management",
+ "concepts/projects",
+ "concepts/teaming",
+ "concepts/gitops",
+ "concepts/oauth-dex-concept"
+ ]
+ },
+ {
+ "User Guides": [
+ "user-guides/overview",
+ {
+ "Advanced Installation": [
+ {
+ "ChaosCenter": [
+ "user-guides/chaoscenter-oauth-dex-installation",
+ "user-guides/chaoscenter-cluster-scope-installation",
+ "user-guides/chaoscenter-namespace-scope-installation",
+ "user-guides/setup-without-ingress",
+ "user-guides/setup-with-ingress"
+ ]
+ },
+ "user-guides/chaosagents-installation"
+ ]
+ },
+ {
+ "Injecting Fault": [
+ "user-guides/schedule-workflow",
+ "user-guides/observe-workflow",
+ "user-guides/edit-schedule",
+ "user-guides/save-as-template",
+ "user-guides/download-workflow-manifest",
+ "user-guides/re-run-workflow",
+ "user-guides/delete-workflow",
+ "user-guides/construct-workflow"
+ ]
+ },
+ {
+ "Observing Chaos": [
+ "user-guides/observability-set-up",
+ "user-guides/analyze-workflow",
+ "user-guides/comparative-analysis",
+ "user-guides/setup-datasource",
+ "user-guides/configure-datasource",
+ "user-guides/manage-app-dashboard",
+ "user-guides/editing-queries-app-dashboard",
+ "user-guides/view-chaos-impact",
+ "user-guides/share-app-dashboard"
+ ]
+ },
+ "user-guides/account-settings",
+ {
+ "User Management": [
+ "user-guides/create-user",
+ "user-guides/view-user",
+ "user-guides/reset-password",
+ "user-guides/deactivate-user"
+ ]
+ },
+ {
+ "Managing Projects": [
+ "user-guides/change-project-name",
+ "user-guides/leave-project"
+ ]
+ },
+ {
+ "Teaming": [
+ "user-guides/invite-team-member",
+ "user-guides/edit-invite",
+ "user-guides/accept-invite",
+ "user-guides/remove-team-member"
+ ]
+ },
+ "user-guides/gitops-configuration",
+ "user-guides/image-registry",
+ "user-guides/uninstall-litmus",
+ "user-guides/upgrade"
+ ]
+ },
+ {
+ "Litmusctl": [
+ "litmusctl/installation",
+ {
+ "Connect Agent": [
+ "litmusctl/usage-non-interactive-mode",
+ "litmusctl/usage-interactive-mode"
+ ]
+ },
+ "litmusctl/chaos-workflow-creation"
+ ]
+ },
+ {
+ "Integrations": [
+ "integrations/prometheus",
+ "integrations/grafana"
+ ]
+ },
+ "troubleshooting",
+ "faq"
+ ]
+}
diff --git a/website/versions.json b/website/versions.json
index d5cb1f3..47798ae 100644
--- a/website/versions.json
+++ b/website/versions.json
@@ -1,4 +1,5 @@
[
+ "2.13.0",
"2.12.0",
"2.11.0",
"2.10.0",