diff --git a/website/versioned_docs/version-3.10.0/architecture/architecture-summary.md b/website/versioned_docs/version-3.10.0/architecture/architecture-summary.md new file mode 100644 index 00000000..76db8e86 --- /dev/null +++ b/website/versioned_docs/version-3.10.0/architecture/architecture-summary.md @@ -0,0 +1,28 @@ +--- +id: architecture-summary +title: Architecture summary +sidebar_label: Architecture summary +--- + +--- + +Architecture Overview + +The Litmus architecture can be segregated into two parts: + +1. **Control plane:** Contains the components required for the functioning of ChaosCenter, the website-based portal for Litmus. + +2. **Execution plane:** Contains the components required for the injection of chaos in the target resources. + +- Control plane can be used for creating and scheduling chaos experiments, which is a set of chaos faults defined in a definitive sequence to achieve desired chaos impact on the target resources upon execution. Users can log in to the ChaosCenter using the web UI or the APIs to define a chaos experiment and assess the resilience of target workloads. + +- Once the user creates a chaos experiment using the ChaosCenter, it is passed on to the execution plane. The Execution plane can be present either in the same cluster as the ChaosCenter if the self chaos infrastructure is being used, or in a remote cluster if an external chaos infrastructure is being used. The Execution plane interprets the chaos experiment as a list of actions that will inject chaos into the target workloads. It ensures efficient orchestration of chaos in various cloud-native environments using Kubernetes custom resources. + +- Once the chaos experiment is executed, Execution plane sends the chaos result to the control plane for their post-processing using either the built-in monitoring dashboard of Litmus or using external observability tools such as Prometheus DB and Grafana dashboard. Litmus also achieves automated chaos experiment runs to execute chaos as part of the CI/CD pipeline based on a set of defined conditions using GitOps. + +:::note +With the latest release of LitmusChaos 3.0.0: +- The term **Chaos Delegate/Agent** has been changed to **Chaos Infrastructure**. +- The term **Chaos Experiment** has been changed to **Chaos Fault**. +- The term **Chaos Scenario/Workflow** has been changed to **Chaos Experiment**. +::: diff --git a/website/versioned_docs/version-3.10.0/architecture/chaos-control-plane.md b/website/versioned_docs/version-3.10.0/architecture/chaos-control-plane.md new file mode 100644 index 00000000..0b61bde8 --- /dev/null +++ b/website/versioned_docs/version-3.10.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 + +Chaos control plane consists of micro-services responsible for the functioning of the ChaosCenter, the website-based portal that can be used for interacting with Litmus, apart from the CLI. Chaos Plane facilitates the creation and scheduling of chaos experiments, system observability during the event of chaos, and post-processing and analysis of fault results. + +## Chaos control plane components + +- **Authentication Server:** A Golang micro-service that is responsible for authorizing, authenticating the requests received from ChaosCenter and managing users along with their projects. It primarily serves the cause of user creation, user login, resetting the password, updating user information, creating project, managing project related operations. + +- **Backend Server:** A GraphQL based Golang micro-service that serves the requests received from ChaosCenter, 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 experiments, saved chaos experiment templates, user projects, ChaosHubs, and GitOps details, among the other information. + +- **ChaosCenter:** Refers to the interfaces used by Litmus for creation and scheduling of chaos experiments, 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 experiments using role-based user accounts. + + - **Litmusctl:** A command-line tool that allows management of Litmus Chaos Infrastructure components. It can be used to create chaos infrastructures, 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 experiments. 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 experiment, the user needs to have an Owner role assigned in the project. +2. The user uploads a Chaos Experiment 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 Infrastructure. +4. Chaos Infrastructure uses the Chaos Experiment manifest to inject chaos into the target resources. The steps of the Chaos Experiment execution can be visualized using the ChaosCenter. +5. Chaos Infrastructure returns the results of the chaos faults that were a part of the chaos experiment back to the Backend Server, along with the fault logs. +6. Backend Server then sends the chaos fault results and logs to the ChaosCenter. It also stores the results into the Database for generating post-chaos experiment statistics and information. diff --git a/website/versioned_docs/version-3.10.0/architecture/chaos-execution-plane.md b/website/versioned_docs/version-3.10.0/architecture/chaos-execution-plane.md new file mode 100644 index 00000000..217a2975 --- /dev/null +++ b/website/versioned_docs/version-3.10.0/architecture/chaos-execution-plane.md @@ -0,0 +1,71 @@ +--- +id: chaos-execution-plane +title: Chaos execution plane +sidebar_label: Chaos execution plane +--- + +--- + +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 infrastructure is being used or in the host cluster containing the control plane if a self chaos infrastructure is being used. It can be further segregated into Litmus Chaos Infrastructure components and Litmus Backend Execution Infrastructure components. + +## Litmus Execution Plane Components + +Litmus Chaos 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 Experiments using the Chaos Experiment 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 Experiment CR from a Chaos Experiment template, watching for Chaos Experiment events during its execution, and sending the chaos experiment result to the Control Plane. + +3. **Event Tracker:** An optional component that is capable of triggering automated chaos experiment 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 experiment 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 Experiment in target resources. These components include: + +1. **Chaos Experiment CR:** Refers to the Argo Workflow CR which describes the steps that are executed as a part of the chaos experiment. 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 fault as well as to store the various fault tunables. + +3. **ChaosEngine CR:** Used to hold information about how the chaos faults are executed. It connects an application instance with one or more chaos faults 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 +
+ +5. **ChaosResult CR:** Holds the results of a chaos fault, such as ChaosEngine reference, Fault State, Verdict of the fault (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 Faults. It is a lifecycle manager for the chaos faults that creates Fault Jobs for the execution of fault business logic and monitors the fault pods (jobs) until completion. + +
+ Chaos Runner +
+ +7. **Fault Jobs:** Refers to the pods that execute the fault logic. One fault pod is created per chaos fault in the chaos experiment. + +## Standard Chaos Execution Plane Flow + +1. Subscriber receives the Chaos Experiment manifest from the Control Plane and applies the manifest to create a Chaos Experiment CR. +2. Chaos Experiment CRs are tracked by the Argo Workflow Controller. When the Workflow Controller finds a new Chaos Experiment CR, it creates the ChaosExperiment(Chaos Fault) CRs and the ChaosEngine CRs for the chaos faults that are a part of the chaos experiment. +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(Chaos fault) CR and overrides them with values from the ChaosEngine CR. It then constructs the Fault Jobs and monitors them until their completion. +6. Fault Jobs execute the fault business logic and undertake chaos injection on target resources. Once done, the ChaosResult is updated with the fault 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 Experiment is executed. + +:::note +With the latest release of LitmusChaos 3.0.0: +- The term **Chaos Delegate/Agent** has been changed to **Chaos Infrastructure**. +- The term **Chaos Experiment** has been changed to **Chaos Fault**. +- The term **Chaos Scenario/Workflow** has been changed to **Chaos Experiment**. +::: diff --git a/website/versioned_docs/version-3.10.0/architecture/chaos-experiment-flow.md b/website/versioned_docs/version-3.10.0/architecture/chaos-experiment-flow.md new file mode 100644 index 00000000..62437069 --- /dev/null +++ b/website/versioned_docs/version-3.10.0/architecture/chaos-experiment-flow.md @@ -0,0 +1,37 @@ +--- +id: chaos-fault-flow +title: Chaos fault flow +sidebar_label: Chaos fault flow +--- + +--- + +Chaos Fault Flow + +The fault 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 Fault Jobs that execute the fault business logic. Typically, these ChaosEngines are embedded within the 'steps' of a Litmus Chaos Experiment. However, one may also create and apply the Chaos Engines manually, and then the chaos-operator reconciles this resource and triggers the fault execution. Chaos faults are classified as: + +- Kubernetes Faults + - Pod-Level Chaos + - Node-Level Chaos +- Application Chaos +- Cloud Infrastructure + +## Chaos Fault Flow Steps + +1. Chaos fault execution gets triggered by the Fault Job. +2. Fault tunables and low-level execution details are fetched. +3. ChaosResult gets initialized and its verdict is updated as "Awaited" to indicate that the fault is currently running. +4. Steady-state condition for the respective fault is validated. If the condition is found to be invalid, the fault execution is stopped and the ChaosResult is updated as "Fail". +5. Once the steady-state condition is validated, fault 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. Fault execution ends. + +:::note +With the latest release of LitmusChaos 3.0.0: +- The term **Chaos Delegate/Agent** has been changed to **Chaos Infrastructure**. +- The term **Chaos Experiment** has been changed to **Chaos Fault**. +- The term **Chaos Scenario/Workflow** has been changed to **Chaos Experiment**. +::: diff --git a/website/versioned_docs/version-3.10.0/architecture/overview.md b/website/versioned_docs/version-3.10.0/architecture/overview.md new file mode 100644 index 00000000..71d9a6cf --- /dev/null +++ b/website/versioned_docs/version-3.10.0/architecture/overview.md @@ -0,0 +1,25 @@ +--- +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 Fault 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. diff --git a/website/versioned_docs/version-3.10.0/assets/architecture-summary.png b/website/versioned_docs/version-3.10.0/assets/architecture-summary.png new file mode 100644 index 00000000..50934882 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/architecture-summary.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/architecture.png b/website/versioned_docs/version-3.10.0/assets/architecture.png new file mode 100644 index 00000000..736a2b0f Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/architecture.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/argo-chaos-workflow.png b/website/versioned_docs/version-3.10.0/assets/argo-chaos-workflow.png new file mode 100644 index 00000000..cdb412b2 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/argo-chaos-workflow.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/argo-graph.png b/website/versioned_docs/version-3.10.0/assets/argo-graph.png new file mode 100644 index 00000000..58bb2991 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/argo-graph.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/arrow.png b/website/versioned_docs/version-3.10.0/assets/arrow.png new file mode 100644 index 00000000..89f1b061 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/arrow.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/chaos-center-analytics.pdf b/website/versioned_docs/version-3.10.0/assets/chaos-center-analytics.pdf new file mode 100644 index 00000000..999b477c Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/chaos-center-analytics.pdf differ diff --git a/website/versioned_docs/version-3.10.0/assets/chaos-control-plane.png b/website/versioned_docs/version-3.10.0/assets/chaos-control-plane.png new file mode 100644 index 00000000..7b6c2dc2 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/chaos-control-plane.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/chaos-execution-plane-chaos-operator.png b/website/versioned_docs/version-3.10.0/assets/chaos-execution-plane-chaos-operator.png new file mode 100644 index 00000000..ae39b735 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/chaos-execution-plane-chaos-operator.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/chaos-execution-plane-chaos-runner.png b/website/versioned_docs/version-3.10.0/assets/chaos-execution-plane-chaos-runner.png new file mode 100644 index 00000000..a628c8cf Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/chaos-execution-plane-chaos-runner.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/chaos-execution-plane.png b/website/versioned_docs/version-3.10.0/assets/chaos-execution-plane.png new file mode 100644 index 00000000..422f7587 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/chaos-execution-plane.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/chaos-hub.png b/website/versioned_docs/version-3.10.0/assets/chaos-hub.png new file mode 100644 index 00000000..d945f3d3 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/chaos-hub.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/chaos-observability-flow-analytics.png b/website/versioned_docs/version-3.10.0/assets/chaos-observability-flow-analytics.png new file mode 100644 index 00000000..cef7e61e Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/chaos-observability-flow-analytics.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/chaos-observability-flow-events.png b/website/versioned_docs/version-3.10.0/assets/chaos-observability-flow-events.png new file mode 100644 index 00000000..379a2f4f Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/chaos-observability-flow-events.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/chaos-observability-flow-logging.png b/website/versioned_docs/version-3.10.0/assets/chaos-observability-flow-logging.png new file mode 100644 index 00000000..cc89f30a Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/chaos-observability-flow-logging.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/chaos-observability-flow-metrics.png b/website/versioned_docs/version-3.10.0/assets/chaos-observability-flow-metrics.png new file mode 100644 index 00000000..ff0a685d Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/chaos-observability-flow-metrics.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/chaos-observability-flow-summarisation.png b/website/versioned_docs/version-3.10.0/assets/chaos-observability-flow-summarisation.png new file mode 100644 index 00000000..6098b954 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/chaos-observability-flow-summarisation.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/concepts/authentication/architecture.png b/website/versioned_docs/version-3.10.0/assets/concepts/authentication/architecture.png new file mode 100644 index 00000000..9a7ed95f Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/concepts/authentication/architecture.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/concepts/chaoshub/chaoshub-add-private.png b/website/versioned_docs/version-3.10.0/assets/concepts/chaoshub/chaoshub-add-private.png new file mode 100644 index 00000000..7032fc29 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/concepts/chaoshub/chaoshub-add-private.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/concepts/chaoshub/chaoshub-add-public.png b/website/versioned_docs/version-3.10.0/assets/concepts/chaoshub/chaoshub-add-public.png new file mode 100644 index 00000000..92dbd089 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/concepts/chaoshub/chaoshub-add-public.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/concepts/chaoshub/chaoshub-after-add.png b/website/versioned_docs/version-3.10.0/assets/concepts/chaoshub/chaoshub-after-add.png new file mode 100644 index 00000000..7df0b8d4 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/concepts/chaoshub/chaoshub-after-add.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/concepts/chaoshub/chaoshub-chaos-charts.png b/website/versioned_docs/version-3.10.0/assets/concepts/chaoshub/chaoshub-chaos-charts.png new file mode 100644 index 00000000..4a2cc116 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/concepts/chaoshub/chaoshub-chaos-charts.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/concepts/chaoshub/chaoshub-default.png b/website/versioned_docs/version-3.10.0/assets/concepts/chaoshub/chaoshub-default.png new file mode 100644 index 00000000..9ed1fbaa Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/concepts/chaoshub/chaoshub-default.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/concepts/chaoshub/chaoshub-exp-details.png b/website/versioned_docs/version-3.10.0/assets/concepts/chaoshub/chaoshub-exp-details.png new file mode 100644 index 00000000..74b42fd6 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/concepts/chaoshub/chaoshub-exp-details.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/concepts/chaoshub/chaoshub-predefined-experiments.png b/website/versioned_docs/version-3.10.0/assets/concepts/chaoshub/chaoshub-predefined-experiments.png new file mode 100644 index 00000000..ba0ebd2f Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/concepts/chaoshub/chaoshub-predefined-experiments.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/concepts/gitops/architecture.png b/website/versioned_docs/version-3.10.0/assets/concepts/gitops/architecture.png new file mode 100644 index 00000000..69ed4b3e Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/concepts/gitops/architecture.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/concepts/gitops/litmus-components.png b/website/versioned_docs/version-3.10.0/assets/concepts/gitops/litmus-components.png new file mode 100644 index 00000000..780d52f7 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/concepts/gitops/litmus-components.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/concepts/observability/app-infra-monitoring/app-infra-monitoring-dataflow.png b/website/versioned_docs/version-3.10.0/assets/concepts/observability/app-infra-monitoring/app-infra-monitoring-dataflow.png new file mode 100644 index 00000000..6a489177 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/concepts/observability/app-infra-monitoring/app-infra-monitoring-dataflow.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/concepts/observability/app-infra-monitoring/dashboard-schema.png b/website/versioned_docs/version-3.10.0/assets/concepts/observability/app-infra-monitoring/dashboard-schema.png new file mode 100644 index 00000000..147c216a Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/concepts/observability/app-infra-monitoring/dashboard-schema.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/concepts/observability/data-source/data-source.png b/website/versioned_docs/version-3.10.0/assets/concepts/observability/data-source/data-source.png new file mode 100644 index 00000000..51b5b5a5 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/concepts/observability/data-source/data-source.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/concepts/observability/workflow-statistics/workflow-statistics-dataflow.png b/website/versioned_docs/version-3.10.0/assets/concepts/observability/workflow-statistics/workflow-statistics-dataflow.png new file mode 100644 index 00000000..d0b70ccd Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/concepts/observability/workflow-statistics/workflow-statistics-dataflow.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/concepts/projects/flow-chart.png b/website/versioned_docs/version-3.10.0/assets/concepts/projects/flow-chart.png new file mode 100644 index 00000000..f7ce35d4 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/concepts/projects/flow-chart.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/disconnect-image.png b/website/versioned_docs/version-3.10.0/assets/disconnect-image.png new file mode 100644 index 00000000..b4286ba5 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/disconnect-image.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/experiment-flow.png b/website/versioned_docs/version-3.10.0/assets/experiment-flow.png new file mode 100644 index 00000000..6e79ad7f Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/experiment-flow.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/favicon.ico b/website/versioned_docs/version-3.10.0/assets/favicon.ico new file mode 100644 index 00000000..42db2693 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/favicon.ico differ diff --git a/website/versioned_docs/version-3.10.0/assets/getstarted.svg b/website/versioned_docs/version-3.10.0/assets/getstarted.svg new file mode 100644 index 00000000..cefa5547 --- /dev/null +++ b/website/versioned_docs/version-3.10.0/assets/getstarted.svg @@ -0,0 +1,429 @@ + + + + + + + + + + + + + + +chaos:~$#BuildandapplyChaosEngineCRtounleashChaosEvery1.0s:kubectlgetpoFriOct419:32:352019 + + +chaos:~$ + + +chaos:~$vichaosengine.yamlNAMEREADYSTATUSRESTARTSAGE + + +chaos:~$hello-deploy-dd59b8956-hxcjv1/1Running019m + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +HelloWorldisonlineHTTP/2200OK + + +HelloWorldisonlineHTTP/2200OK + + +HelloWorldisonlineHTTP/2200OK + + +HelloWorldisonlineHTTP/2200OK + + +HelloWorldisonlineHTTP/2200OK + + +HelloWorldisonlineHTTP/2200OK + + +HelloWorldisonlineHTTP/2200OK + + +HelloWorldisonlineHTTP/2200OK + + +HelloWorldisonlineHTTP/2200OK + + +HelloWorldisonlineHTTP/2200OK + + +HelloWorldisonlineHTTP/2200OK + + +HelloWorldisonlineHTTP/2200OK + + +HelloWorldisonlineHTTP/2200OK + + +HelloWorldisonlineHTTP/2200OK + + +HelloWorldisonlineHTTP/2200OK + + +HelloWorldisonlineHTTP/2200OK + + +HelloWorldisonlineHTTP/2200OK + + +HelloWorldisonlineHTTP/2200OK + + +HelloWorldisonlineHTTP/2200OK + + + + + +[demo]0:ssh*"rahul-ThinkPad-E490"01:0205-Oct-19 + + + + + + + + + + + + + + + + + + + diff --git a/website/versioned_docs/version-3.10.0/assets/getting-started/run-your-first-workflow/adjust-weights-for-podtato-head.png b/website/versioned_docs/version-3.10.0/assets/getting-started/run-your-first-workflow/adjust-weights-for-podtato-head.png new file mode 100644 index 00000000..88b1c0c1 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/getting-started/run-your-first-workflow/adjust-weights-for-podtato-head.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/getting-started/run-your-first-workflow/chaos-result-of-podtato-head.png b/website/versioned_docs/version-3.10.0/assets/getting-started/run-your-first-workflow/chaos-result-of-podtato-head.png new file mode 100644 index 00000000..b804f511 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/getting-started/run-your-first-workflow/chaos-result-of-podtato-head.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/getting-started/run-your-first-workflow/choose-schedule.png b/website/versioned_docs/version-3.10.0/assets/getting-started/run-your-first-workflow/choose-schedule.png new file mode 100644 index 00000000..f2991039 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/getting-started/run-your-first-workflow/choose-schedule.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/getting-started/run-your-first-workflow/podtato-head-tune-workflow.png b/website/versioned_docs/version-3.10.0/assets/getting-started/run-your-first-workflow/podtato-head-tune-workflow.png new file mode 100644 index 00000000..c1a5fc8d Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/getting-started/run-your-first-workflow/podtato-head-tune-workflow.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/getting-started/run-your-first-workflow/podtato-head-workflow-in-action.png b/website/versioned_docs/version-3.10.0/assets/getting-started/run-your-first-workflow/podtato-head-workflow-in-action.png new file mode 100644 index 00000000..a5a6ef5b Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/getting-started/run-your-first-workflow/podtato-head-workflow-in-action.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/getting-started/run-your-first-workflow/podtato-head-workflow-running.png b/website/versioned_docs/version-3.10.0/assets/getting-started/run-your-first-workflow/podtato-head-workflow-running.png new file mode 100644 index 00000000..a8e24150 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/getting-started/run-your-first-workflow/podtato-head-workflow-running.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/getting-started/run-your-first-workflow/schedule-workflow-from-homepage.png b/website/versioned_docs/version-3.10.0/assets/getting-started/run-your-first-workflow/schedule-workflow-from-homepage.png new file mode 100644 index 00000000..89742980 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/getting-started/run-your-first-workflow/schedule-workflow-from-homepage.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/getting-started/run-your-first-workflow/schedule-workflow-from-litmus-workflows.png b/website/versioned_docs/version-3.10.0/assets/getting-started/run-your-first-workflow/schedule-workflow-from-litmus-workflows.png new file mode 100644 index 00000000..c6a6df21 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/getting-started/run-your-first-workflow/schedule-workflow-from-litmus-workflows.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/getting-started/run-your-first-workflow/scheduled-successfully.png b/website/versioned_docs/version-3.10.0/assets/getting-started/run-your-first-workflow/scheduled-successfully.png new file mode 100644 index 00000000..e8d08123 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/getting-started/run-your-first-workflow/scheduled-successfully.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/getting-started/run-your-first-workflow/select-podtato-head.png b/website/versioned_docs/version-3.10.0/assets/getting-started/run-your-first-workflow/select-podtato-head.png new file mode 100644 index 00000000..497af12d Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/getting-started/run-your-first-workflow/select-podtato-head.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/getting-started/run-your-first-workflow/selecting-self-agent.png b/website/versioned_docs/version-3.10.0/assets/getting-started/run-your-first-workflow/selecting-self-agent.png new file mode 100644 index 00000000..cbda36fc Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/getting-started/run-your-first-workflow/selecting-self-agent.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/getting-started/run-your-first-workflow/verify-and-commit-podtato-head.png b/website/versioned_docs/version-3.10.0/assets/getting-started/run-your-first-workflow/verify-and-commit-podtato-head.png new file mode 100644 index 00000000..6deb7cc9 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/getting-started/run-your-first-workflow/verify-and-commit-podtato-head.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/getting-started/run-your-first-workflow/workflow-settings-podtato-head.png b/website/versioned_docs/version-3.10.0/assets/getting-started/run-your-first-workflow/workflow-settings-podtato-head.png new file mode 100644 index 00000000..91470da6 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/getting-started/run-your-first-workflow/workflow-settings-podtato-head.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/integrations/grafana/annotation-events.png b/website/versioned_docs/version-3.10.0/assets/integrations/grafana/annotation-events.png new file mode 100644 index 00000000..3be4fac9 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/integrations/grafana/annotation-events.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/integrations/grafana/annotation-metrics.png b/website/versioned_docs/version-3.10.0/assets/integrations/grafana/annotation-metrics.png new file mode 100644 index 00000000..958ba3be Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/integrations/grafana/annotation-metrics.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/integrations/grafana/experiment-verdict-failure-alert-config.png b/website/versioned_docs/version-3.10.0/assets/integrations/grafana/experiment-verdict-failure-alert-config.png new file mode 100644 index 00000000..b7baad05 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/integrations/grafana/experiment-verdict-failure-alert-config.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/integrations/grafana/experiment-verdict-failure-alert-query.png b/website/versioned_docs/version-3.10.0/assets/integrations/grafana/experiment-verdict-failure-alert-query.png new file mode 100644 index 00000000..a66239ac Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/integrations/grafana/experiment-verdict-failure-alert-query.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/integrations/grafana/gauges.png b/website/versioned_docs/version-3.10.0/assets/integrations/grafana/gauges.png new file mode 100644 index 00000000..c825d233 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/integrations/grafana/gauges.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/integrations/grafana/probe-failure-alert-config.png b/website/versioned_docs/version-3.10.0/assets/integrations/grafana/probe-failure-alert-config.png new file mode 100644 index 00000000..2304a2f1 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/integrations/grafana/probe-failure-alert-config.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/integrations/grafana/probe-failure-alert-query.png b/website/versioned_docs/version-3.10.0/assets/integrations/grafana/probe-failure-alert-query.png new file mode 100644 index 00000000..e9724469 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/integrations/grafana/probe-failure-alert-query.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/integrations/grafana/variable-engine-context.png b/website/versioned_docs/version-3.10.0/assets/integrations/grafana/variable-engine-context.png new file mode 100644 index 00000000..bf228c23 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/integrations/grafana/variable-engine-context.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/integrations/grafana/variable-result-name.png b/website/versioned_docs/version-3.10.0/assets/integrations/grafana/variable-result-name.png new file mode 100644 index 00000000..24d0f3d4 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/integrations/grafana/variable-result-name.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/introduction/community/CNCF.webp b/website/versioned_docs/version-3.10.0/assets/introduction/community/CNCF.webp new file mode 100644 index 00000000..2d5f0cd1 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/introduction/community/CNCF.webp differ diff --git a/website/versioned_docs/version-3.10.0/assets/introduction/community/CommunitySyncUp.webp b/website/versioned_docs/version-3.10.0/assets/introduction/community/CommunitySyncUp.webp new file mode 100644 index 00000000..0560582e Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/introduction/community/CommunitySyncUp.webp differ diff --git a/website/versioned_docs/version-3.10.0/assets/introduction/core-principles/litmus-principles.png b/website/versioned_docs/version-3.10.0/assets/introduction/core-principles/litmus-principles.png new file mode 100644 index 00000000..8ed58e85 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/introduction/core-principles/litmus-principles.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/introduction/litmus/importance-of-resilience.png b/website/versioned_docs/version-3.10.0/assets/introduction/litmus/importance-of-resilience.png new file mode 100644 index 00000000..140b0b2f Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/introduction/litmus/importance-of-resilience.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/introduction/uses-of-litmus/chaos-test-devops.png b/website/versioned_docs/version-3.10.0/assets/introduction/uses-of-litmus/chaos-test-devops.png new file mode 100644 index 00000000..a129c82f Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/introduction/uses-of-litmus/chaos-test-devops.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/introduction/uses-of-litmus/overall-resilience.png b/website/versioned_docs/version-3.10.0/assets/introduction/uses-of-litmus/overall-resilience.png new file mode 100644 index 00000000..eb7de22f Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/introduction/uses-of-litmus/overall-resilience.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/join-community.png b/website/versioned_docs/version-3.10.0/assets/join-community.png new file mode 100644 index 00000000..d3720865 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/join-community.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/landing-page.png b/website/versioned_docs/version-3.10.0/assets/landing-page.png new file mode 100644 index 00000000..277a1730 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/landing-page.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/litmus-logo.png b/website/versioned_docs/version-3.10.0/assets/litmus-logo.png new file mode 100644 index 00000000..432ead63 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/litmus-logo.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/litmus-overview.png b/website/versioned_docs/version-3.10.0/assets/litmus-overview.png new file mode 100644 index 00000000..88e9f05f Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/litmus-overview.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/litmus-schematic.png b/website/versioned_docs/version-3.10.0/assets/litmus-schematic.png new file mode 100644 index 00000000..42c3e9a7 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/litmus-schematic.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/login.png b/website/versioned_docs/version-3.10.0/assets/login.png new file mode 100644 index 00000000..b105e7d6 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/login.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/node-details.png b/website/versioned_docs/version-3.10.0/assets/node-details.png new file mode 100644 index 00000000..9010fcfb Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/node-details.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/portal-arch.jpg b/website/versioned_docs/version-3.10.0/assets/portal-arch.jpg new file mode 100644 index 00000000..96014444 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/portal-arch.jpg differ diff --git a/website/versioned_docs/version-3.10.0/assets/red-blue-cluster.png b/website/versioned_docs/version-3.10.0/assets/red-blue-cluster.png new file mode 100644 index 00000000..df49e9fa Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/red-blue-cluster.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/tutorials.png b/website/versioned_docs/version-3.10.0/assets/tutorials.png new file mode 100644 index 00000000..bceb2dcf Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/tutorials.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/environment/create-environment/step-1.png b/website/versioned_docs/version-3.10.0/assets/user-guides/environment/create-environment/step-1.png new file mode 100644 index 00000000..7034c807 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/environment/create-environment/step-1.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/environment/create-environment/step-2.png b/website/versioned_docs/version-3.10.0/assets/user-guides/environment/create-environment/step-2.png new file mode 100644 index 00000000..d82ba9dc Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/environment/create-environment/step-2.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/environment/create-environment/step-3.png b/website/versioned_docs/version-3.10.0/assets/user-guides/environment/create-environment/step-3.png new file mode 100644 index 00000000..d5541a8b Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/environment/create-environment/step-3.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/environment/delete-environment/step-1.png b/website/versioned_docs/version-3.10.0/assets/user-guides/environment/delete-environment/step-1.png new file mode 100644 index 00000000..b60588d9 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/environment/delete-environment/step-1.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/environment/delete-environment/step-2.png b/website/versioned_docs/version-3.10.0/assets/user-guides/environment/delete-environment/step-2.png new file mode 100644 index 00000000..78805a11 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/environment/delete-environment/step-2.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/environment/delete-environment/step-3.png b/website/versioned_docs/version-3.10.0/assets/user-guides/environment/delete-environment/step-3.png new file mode 100644 index 00000000..c9f96118 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/environment/delete-environment/step-3.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/environment/edit-environment/step-1.png b/website/versioned_docs/version-3.10.0/assets/user-guides/environment/edit-environment/step-1.png new file mode 100644 index 00000000..ccffc89c Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/environment/edit-environment/step-1.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/environment/edit-environment/step-2.png b/website/versioned_docs/version-3.10.0/assets/user-guides/environment/edit-environment/step-2.png new file mode 100644 index 00000000..51c8ddeb Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/environment/edit-environment/step-2.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/environment/edit-environment/step-3.png b/website/versioned_docs/version-3.10.0/assets/user-guides/environment/edit-environment/step-3.png new file mode 100644 index 00000000..c7754323 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/environment/edit-environment/step-3.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/gitops/gitops-config.png b/website/versioned_docs/version-3.10.0/assets/user-guides/gitops/gitops-config.png new file mode 100644 index 00000000..b270e7a4 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/gitops/gitops-config.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/gitops/gitops.png b/website/versioned_docs/version-3.10.0/assets/user-guides/gitops/gitops.png new file mode 100644 index 00000000..a70b076c Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/gitops/gitops.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/image-registry/img-registry-changes.png b/website/versioned_docs/version-3.10.0/assets/user-guides/image-registry/img-registry-changes.png new file mode 100644 index 00000000..fb8c8db9 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/image-registry/img-registry-changes.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/image-registry/img-registry-tab.png b/website/versioned_docs/version-3.10.0/assets/user-guides/image-registry/img-registry-tab.png new file mode 100644 index 00000000..b5ecc8c6 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/image-registry/img-registry-tab.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/image-registry/img-registry-update.png b/website/versioned_docs/version-3.10.0/assets/user-guides/image-registry/img-registry-update.png new file mode 100644 index 00000000..15c7955d Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/image-registry/img-registry-update.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/image-registry/img-registry-updated.png b/website/versioned_docs/version-3.10.0/assets/user-guides/image-registry/img-registry-updated.png new file mode 100644 index 00000000..86a1a53f Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/image-registry/img-registry-updated.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/infrastructure/create-infrastructure/step-1.png b/website/versioned_docs/version-3.10.0/assets/user-guides/infrastructure/create-infrastructure/step-1.png new file mode 100644 index 00000000..fb456aea Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/infrastructure/create-infrastructure/step-1.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/infrastructure/create-infrastructure/step-2.png b/website/versioned_docs/version-3.10.0/assets/user-guides/infrastructure/create-infrastructure/step-2.png new file mode 100644 index 00000000..41ee3a04 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/infrastructure/create-infrastructure/step-2.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/infrastructure/create-infrastructure/step-3.png b/website/versioned_docs/version-3.10.0/assets/user-guides/infrastructure/create-infrastructure/step-3.png new file mode 100644 index 00000000..7764c397 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/infrastructure/create-infrastructure/step-3.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/infrastructure/create-infrastructure/step-4.png b/website/versioned_docs/version-3.10.0/assets/user-guides/infrastructure/create-infrastructure/step-4.png new file mode 100644 index 00000000..8a6a6826 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/infrastructure/create-infrastructure/step-4.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/infrastructure/create-infrastructure/step-5.png b/website/versioned_docs/version-3.10.0/assets/user-guides/infrastructure/create-infrastructure/step-5.png new file mode 100644 index 00000000..58907576 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/infrastructure/create-infrastructure/step-5.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/infrastructure/create-infrastructure/step-6.png b/website/versioned_docs/version-3.10.0/assets/user-guides/infrastructure/create-infrastructure/step-6.png new file mode 100644 index 00000000..6a997861 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/infrastructure/create-infrastructure/step-6.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/infrastructure/create-infrastructure/step-7.png b/website/versioned_docs/version-3.10.0/assets/user-guides/infrastructure/create-infrastructure/step-7.png new file mode 100644 index 00000000..121addc9 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/infrastructure/create-infrastructure/step-7.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/infrastructure/delete-infrastructure/step-1.png b/website/versioned_docs/version-3.10.0/assets/user-guides/infrastructure/delete-infrastructure/step-1.png new file mode 100644 index 00000000..1ec9271d Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/infrastructure/delete-infrastructure/step-1.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/infrastructure/delete-infrastructure/step-2.png b/website/versioned_docs/version-3.10.0/assets/user-guides/infrastructure/delete-infrastructure/step-2.png new file mode 100644 index 00000000..83a5b175 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/infrastructure/delete-infrastructure/step-2.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/infrastructure/delete-infrastructure/step-3.png b/website/versioned_docs/version-3.10.0/assets/user-guides/infrastructure/delete-infrastructure/step-3.png new file mode 100644 index 00000000..bf3624ef Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/infrastructure/delete-infrastructure/step-3.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/delete-workflow/step-1.png b/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/delete-workflow/step-1.png new file mode 100644 index 00000000..c2fefdc0 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/delete-workflow/step-1.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/delete-workflow/step-2.png b/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/delete-workflow/step-2.png new file mode 100644 index 00000000..73559664 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/delete-workflow/step-2.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/delete-workflow/step-3.png b/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/delete-workflow/step-3.png new file mode 100644 index 00000000..22ede174 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/delete-workflow/step-3.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/download-workflow-manifest/step-1.png b/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/download-workflow-manifest/step-1.png new file mode 100644 index 00000000..55fa7d9b Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/download-workflow-manifest/step-1.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/download-workflow-manifest/step-2.png b/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/download-workflow-manifest/step-2.png new file mode 100644 index 00000000..81dd4e8e Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/download-workflow-manifest/step-2.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/edit-schedule/edit-schedule-page.png b/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/edit-schedule/edit-schedule-page.png new file mode 100644 index 00000000..eaad8174 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/edit-schedule/edit-schedule-page.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/edit-schedule/edit-schedule.png b/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/edit-schedule/edit-schedule.png new file mode 100644 index 00000000..d7498869 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/edit-schedule/edit-schedule.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/edit-schedule/schedule-menu.png b/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/edit-schedule/schedule-menu.png new file mode 100644 index 00000000..00d6621c Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/edit-schedule/schedule-menu.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/observe-workflow/completed-workflow-with-chaos-results.png b/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/observe-workflow/completed-workflow-with-chaos-results.png new file mode 100644 index 00000000..72a4fc17 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/observe-workflow/completed-workflow-with-chaos-results.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/observe-workflow/experiment-table.png b/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/observe-workflow/experiment-table.png new file mode 100644 index 00000000..c381aa8f Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/observe-workflow/experiment-table.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/observe-workflow/running-workflow-with-logs.png b/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/observe-workflow/running-workflow-with-logs.png new file mode 100644 index 00000000..2cee4a09 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/observe-workflow/running-workflow-with-logs.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/observe-workflow/running-workflow.png b/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/observe-workflow/running-workflow.png new file mode 100644 index 00000000..5103edc7 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/observe-workflow/running-workflow.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/observe-workflow/runs-table.png b/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/observe-workflow/runs-table.png new file mode 100644 index 00000000..8c6e9f13 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/observe-workflow/runs-table.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/re-run-workflow/step-1.png b/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/re-run-workflow/step-1.png new file mode 100644 index 00000000..dd6aaf60 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/re-run-workflow/step-1.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/re-run-workflow/step-2.png b/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/re-run-workflow/step-2.png new file mode 100644 index 00000000..fbf72596 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/re-run-workflow/step-2.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/save-workflow-as-template/step-1.png b/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/save-workflow-as-template/step-1.png new file mode 100644 index 00000000..03607f72 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/save-workflow-as-template/step-1.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/save-workflow-as-template/step-2.png b/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/save-workflow-as-template/step-2.png new file mode 100644 index 00000000..2ddee2a3 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/save-workflow-as-template/step-2.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/save-workflow-as-template/step-3.png b/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/save-workflow-as-template/step-3.png new file mode 100644 index 00000000..2758641a Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/save-workflow-as-template/step-3.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/save-workflow-as-template/step-4.png b/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/save-workflow-as-template/step-4.png new file mode 100644 index 00000000..b10a06ee Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/save-workflow-as-template/step-4.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/schedule-workflow/add-parallel-faults.png b/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/schedule-workflow/add-parallel-faults.png new file mode 100644 index 00000000..922ab7e3 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/schedule-workflow/add-parallel-faults.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/schedule-workflow/advanced-options-experiment-creation.png b/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/schedule-workflow/advanced-options-experiment-creation.png new file mode 100644 index 00000000..5a172ca9 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/schedule-workflow/advanced-options-experiment-creation.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/schedule-workflow/chaos-experiment-save.png b/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/schedule-workflow/chaos-experiment-save.png new file mode 100644 index 00000000..6d10b6bc Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/schedule-workflow/chaos-experiment-save.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/schedule-workflow/litmus-chaos-hub.png b/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/schedule-workflow/litmus-chaos-hub.png new file mode 100644 index 00000000..86ac661b Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/schedule-workflow/litmus-chaos-hub.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/schedule-workflow/new-experiment-blank-canvas.png b/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/schedule-workflow/new-experiment-blank-canvas.png new file mode 100644 index 00000000..ad91e4bd Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/schedule-workflow/new-experiment-blank-canvas.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/schedule-workflow/new-experiment-choose-method.png b/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/schedule-workflow/new-experiment-choose-method.png new file mode 100644 index 00000000..298ef721 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/schedule-workflow/new-experiment-choose-method.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/schedule-workflow/new-experiment-identifiers.png b/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/schedule-workflow/new-experiment-identifiers.png new file mode 100644 index 00000000..9c3e4bc2 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/schedule-workflow/new-experiment-identifiers.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/schedule-workflow/new-experiment-infra-select.png b/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/schedule-workflow/new-experiment-infra-select.png new file mode 100644 index 00000000..f8029f07 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/schedule-workflow/new-experiment-infra-select.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/schedule-workflow/new-experiment-overview-home.png b/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/schedule-workflow/new-experiment-overview-home.png new file mode 100644 index 00000000..6c16bc88 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/schedule-workflow/new-experiment-overview-home.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/schedule-workflow/node-selectors.png b/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/schedule-workflow/node-selectors.png new file mode 100644 index 00000000..42fc903f Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/schedule-workflow/node-selectors.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/schedule-workflow/select-template-from-chaos-hub.png b/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/schedule-workflow/select-template-from-chaos-hub.png new file mode 100644 index 00000000..7a1339e6 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/schedule-workflow/select-template-from-chaos-hub.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/schedule-workflow/tolerations.png b/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/schedule-workflow/tolerations.png new file mode 100644 index 00000000..5d915a37 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/schedule-workflow/tolerations.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/schedule-workflow/tune-fault.png b/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/schedule-workflow/tune-fault.png new file mode 100644 index 00000000..1d6a9c65 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/injecting-fault/schedule-workflow/tune-fault.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/managing-projects/change-project-name/step-1.png b/website/versioned_docs/version-3.10.0/assets/user-guides/managing-projects/change-project-name/step-1.png new file mode 100644 index 00000000..817a90ef Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/managing-projects/change-project-name/step-1.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/managing-projects/change-project-name/step-2.png b/website/versioned_docs/version-3.10.0/assets/user-guides/managing-projects/change-project-name/step-2.png new file mode 100644 index 00000000..50f6f7df Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/managing-projects/change-project-name/step-2.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/managing-projects/change-project-name/step-3.png b/website/versioned_docs/version-3.10.0/assets/user-guides/managing-projects/change-project-name/step-3.png new file mode 100644 index 00000000..c383dafd Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/managing-projects/change-project-name/step-3.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/managing-projects/leave-project/step-1.png b/website/versioned_docs/version-3.10.0/assets/user-guides/managing-projects/leave-project/step-1.png new file mode 100644 index 00000000..44c570f0 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/managing-projects/leave-project/step-1.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/managing-projects/leave-project/step-2.png b/website/versioned_docs/version-3.10.0/assets/user-guides/managing-projects/leave-project/step-2.png new file mode 100644 index 00000000..821cbf67 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/managing-projects/leave-project/step-2.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/my-account/step-1.png b/website/versioned_docs/version-3.10.0/assets/user-guides/my-account/step-1.png new file mode 100644 index 00000000..e0a55bb9 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/my-account/step-1.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/my-account/step-2.png b/website/versioned_docs/version-3.10.0/assets/user-guides/my-account/step-2.png new file mode 100644 index 00000000..b5f5a0e4 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/my-account/step-2.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/my-account/step-3.png b/website/versioned_docs/version-3.10.0/assets/user-guides/my-account/step-3.png new file mode 100644 index 00000000..ca1b7f59 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/my-account/step-3.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/my-account/step-4.png b/website/versioned_docs/version-3.10.0/assets/user-guides/my-account/step-4.png new file mode 100644 index 00000000..04d93133 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/my-account/step-4.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/my-account/step-5.png b/website/versioned_docs/version-3.10.0/assets/user-guides/my-account/step-5.png new file mode 100644 index 00000000..f59da1cd Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/my-account/step-5.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/observability/data-source/configure.png b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/data-source/configure.png new file mode 100644 index 00000000..81855acc Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/data-source/configure.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/observability/data-source/connection-form-page-1.png b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/data-source/connection-form-page-1.png new file mode 100644 index 00000000..a9a8113a Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/data-source/connection-form-page-1.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/observability/data-source/connection-form-page-2.png b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/data-source/connection-form-page-2.png new file mode 100644 index 00000000..f875a98a Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/data-source/connection-form-page-2.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/observability/data-source/deletion-confirmation.png b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/data-source/deletion-confirmation.png new file mode 100644 index 00000000..f3c92c60 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/data-source/deletion-confirmation.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/observability/data-source/force-delete.png b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/data-source/force-delete.png new file mode 100644 index 00000000..a038dec1 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/data-source/force-delete.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/observability/data-source/multiple-agents-multiple-prometheus.png b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/data-source/multiple-agents-multiple-prometheus.png new file mode 100644 index 00000000..eedd7031 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/data-source/multiple-agents-multiple-prometheus.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/observability/data-source/multiple-agents-single-prometheus.png b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/data-source/multiple-agents-single-prometheus.png new file mode 100644 index 00000000..679750a4 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/data-source/multiple-agents-single-prometheus.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/observability/data-source/self-agent-prometheus.png b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/data-source/self-agent-prometheus.png new file mode 100644 index 00000000..76e42978 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/data-source/self-agent-prometheus.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/observability/data-source/tab.png b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/data-source/tab.png new file mode 100644 index 00000000..a31c50e7 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/data-source/tab.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/observability/setup/create-dashboard-add-panel.png b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/setup/create-dashboard-add-panel.png new file mode 100644 index 00000000..f3ea95a9 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/setup/create-dashboard-add-panel.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/observability/setup/create-dashboard-edit-query.png b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/setup/create-dashboard-edit-query.png new file mode 100644 index 00000000..f2700305 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/setup/create-dashboard-edit-query.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/observability/setup/create-dashboard-tune-queries.png b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/setup/create-dashboard-tune-queries.png new file mode 100644 index 00000000..0983032a Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/setup/create-dashboard-tune-queries.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/observability/setup/create-dashboard-visualization-options.png b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/setup/create-dashboard-visualization-options.png new file mode 100644 index 00000000..39e91237 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/setup/create-dashboard-visualization-options.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/observability/setup/manage-application-dashboard-applications-selection.png b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/setup/manage-application-dashboard-applications-selection.png new file mode 100644 index 00000000..4a531071 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/setup/manage-application-dashboard-applications-selection.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/observability/setup/manage-application-dashboard-create-dashboard.png b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/setup/manage-application-dashboard-create-dashboard.png new file mode 100644 index 00000000..6eb2729b Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/setup/manage-application-dashboard-create-dashboard.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/observability/setup/manage-application-dashboard-dashboard-type.png b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/setup/manage-application-dashboard-dashboard-type.png new file mode 100644 index 00000000..d23b34e3 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/setup/manage-application-dashboard-dashboard-type.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/observability/setup/manage-application-dashboard-metadata.png b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/setup/manage-application-dashboard-metadata.png new file mode 100644 index 00000000..0b8d57fb Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/setup/manage-application-dashboard-metadata.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/observability/setup/manage-application-dashboard-no-data-source-dashboard.png b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/setup/manage-application-dashboard-no-data-source-dashboard.png new file mode 100644 index 00000000..d8476fed Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/setup/manage-application-dashboard-no-data-source-dashboard.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/observability/setup/manage-application-dashboard-select-metrics.png b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/setup/manage-application-dashboard-select-metrics.png new file mode 100644 index 00000000..80ff010d Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/setup/manage-application-dashboard-select-metrics.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/observability/setup/manage-application-dashboard-table.png b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/setup/manage-application-dashboard-table.png new file mode 100644 index 00000000..31caedf9 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/setup/manage-application-dashboard-table.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/observability/setup/overview-first-look.png b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/setup/overview-first-look.png new file mode 100644 index 00000000..bde0b874 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/setup/overview-first-look.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/observability/setup/overview-with-dashboards.png b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/setup/overview-with-dashboards.png new file mode 100644 index 00000000..8da1f692 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/setup/overview-with-dashboards.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/observability/setup/overview-with-datasource.png b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/setup/overview-with-datasource.png new file mode 100644 index 00000000..2b638be4 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/setup/overview-with-datasource.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/observability/setup/recently-updated-workflow-dashboards.png b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/setup/recently-updated-workflow-dashboards.png new file mode 100644 index 00000000..247d1bea Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/setup/recently-updated-workflow-dashboards.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/observability/setup/view-chaos-impact-copy-dashboard.png b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/setup/view-chaos-impact-copy-dashboard.png new file mode 100644 index 00000000..c2d0770b Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/setup/view-chaos-impact-copy-dashboard.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/observability/setup/view-chaos-impact-edit-chaos-queries.png b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/setup/view-chaos-impact-edit-chaos-queries.png new file mode 100644 index 00000000..124e4ae8 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/setup/view-chaos-impact-edit-chaos-queries.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/observability/setup/view-chaos-impact-first-look.png b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/setup/view-chaos-impact-first-look.png new file mode 100644 index 00000000..02237416 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/setup/view-chaos-impact-first-look.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/observability/setup/view-chaos-impact-info.png b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/setup/view-chaos-impact-info.png new file mode 100644 index 00000000..97241981 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/setup/view-chaos-impact-info.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/observability/setup/view-chaos-impact-more-options.png b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/setup/view-chaos-impact-more-options.png new file mode 100644 index 00000000..5a7a28be Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/setup/view-chaos-impact-more-options.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/observability/setup/view-chaos-impact-popout.png b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/setup/view-chaos-impact-popout.png new file mode 100644 index 00000000..be994b8c Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/setup/view-chaos-impact-popout.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/observability/setup/view-chaos-impact-refresh-rate.png b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/setup/view-chaos-impact-refresh-rate.png new file mode 100644 index 00000000..be80064b Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/setup/view-chaos-impact-refresh-rate.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/observability/setup/view-chaos-impact-show-chaos-during-this-interval.png b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/setup/view-chaos-impact-show-chaos-during-this-interval.png new file mode 100644 index 00000000..b5c6ff1b Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/setup/view-chaos-impact-show-chaos-during-this-interval.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/observability/workflow-analysis/experiments-table.png b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/workflow-analysis/experiments-table.png new file mode 100644 index 00000000..ca6b7726 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/workflow-analysis/experiments-table.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/observability/workflow-analysis/workflow-activity.png b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/workflow-analysis/workflow-activity.png new file mode 100644 index 00000000..8670dec1 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/workflow-analysis/workflow-activity.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/observability/workflow-analysis/workflow-details.png b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/workflow-analysis/workflow-details.png new file mode 100644 index 00000000..3220f72a Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/workflow-analysis/workflow-details.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/observability/workflow-analysis/workflow-heatmap.png b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/workflow-analysis/workflow-heatmap.png new file mode 100644 index 00000000..c25e6fc6 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/workflow-analysis/workflow-heatmap.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/observability/workflow-analysis/workflow-multi-run.png b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/workflow-analysis/workflow-multi-run.png new file mode 100644 index 00000000..f05e388e Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/workflow-analysis/workflow-multi-run.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/observability/workflow-analysis/workflow-single-run.png b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/workflow-analysis/workflow-single-run.png new file mode 100644 index 00000000..ed73caae Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/workflow-analysis/workflow-single-run.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/observability/workflow-dashboard/comparison-graph-hover.png b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/workflow-dashboard/comparison-graph-hover.png new file mode 100644 index 00000000..7a01aeb3 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/workflow-dashboard/comparison-graph-hover.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/observability/workflow-dashboard/comparison-graph-with-dropdown.png b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/workflow-dashboard/comparison-graph-with-dropdown.png new file mode 100644 index 00000000..48edb1dc Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/workflow-dashboard/comparison-graph-with-dropdown.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/observability/workflow-dashboard/comparison-graph.png b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/workflow-dashboard/comparison-graph.png new file mode 100644 index 00000000..fdc88805 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/workflow-dashboard/comparison-graph.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/observability/workflow-dashboard/export-button.png b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/workflow-dashboard/export-button.png new file mode 100644 index 00000000..19935b1b Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/workflow-dashboard/export-button.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/observability/workflow-dashboard/schedules-stats-dropdown.png b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/workflow-dashboard/schedules-stats-dropdown.png new file mode 100644 index 00000000..94a21f19 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/workflow-dashboard/schedules-stats-dropdown.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/observability/workflow-dashboard/schedules-stats.png b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/workflow-dashboard/schedules-stats.png new file mode 100644 index 00000000..731c4a69 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/workflow-dashboard/schedules-stats.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/observability/workflow-dashboard/workflow-runs-stats-dropdown.png b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/workflow-dashboard/workflow-runs-stats-dropdown.png new file mode 100644 index 00000000..62882ba7 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/workflow-dashboard/workflow-runs-stats-dropdown.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/observability/workflow-dashboard/workflow-runs-stats.png b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/workflow-dashboard/workflow-runs-stats.png new file mode 100644 index 00000000..102148db Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/workflow-dashboard/workflow-runs-stats.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/observability/workflow-dashboard/workflows-comparison-table-1.png b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/workflow-dashboard/workflows-comparison-table-1.png new file mode 100644 index 00000000..a9a9c2e5 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/workflow-dashboard/workflows-comparison-table-1.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/observability/workflow-dashboard/workflows-comparison-table-2.png b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/workflow-dashboard/workflows-comparison-table-2.png new file mode 100644 index 00000000..ffacde1b Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/workflow-dashboard/workflows-comparison-table-2.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/observability/workflow-dashboard/workflows-radial-chart.png b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/workflow-dashboard/workflows-radial-chart.png new file mode 100644 index 00000000..7ab093a0 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/observability/workflow-dashboard/workflows-radial-chart.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/resilience-probes/create-probe/step-1.png b/website/versioned_docs/version-3.10.0/assets/user-guides/resilience-probes/create-probe/step-1.png new file mode 100644 index 00000000..53277c1c Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/resilience-probes/create-probe/step-1.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/resilience-probes/create-probe/step-2.png b/website/versioned_docs/version-3.10.0/assets/user-guides/resilience-probes/create-probe/step-2.png new file mode 100644 index 00000000..c11a10e8 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/resilience-probes/create-probe/step-2.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/resilience-probes/create-probe/step-3.png b/website/versioned_docs/version-3.10.0/assets/user-guides/resilience-probes/create-probe/step-3.png new file mode 100644 index 00000000..3738ae82 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/resilience-probes/create-probe/step-3.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/resilience-probes/create-probe/step-4.png b/website/versioned_docs/version-3.10.0/assets/user-guides/resilience-probes/create-probe/step-4.png new file mode 100644 index 00000000..5c5d95e4 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/resilience-probes/create-probe/step-4.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/resilience-probes/create-probe/step-5.png b/website/versioned_docs/version-3.10.0/assets/user-guides/resilience-probes/create-probe/step-5.png new file mode 100644 index 00000000..330f9543 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/resilience-probes/create-probe/step-5.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/resilience-probes/create-probe/step-6.png b/website/versioned_docs/version-3.10.0/assets/user-guides/resilience-probes/create-probe/step-6.png new file mode 100644 index 00000000..acb5ece4 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/resilience-probes/create-probe/step-6.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/resilience-probes/delete-probe/step-1.png b/website/versioned_docs/version-3.10.0/assets/user-guides/resilience-probes/delete-probe/step-1.png new file mode 100644 index 00000000..26eb2f09 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/resilience-probes/delete-probe/step-1.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/resilience-probes/delete-probe/step-2.png b/website/versioned_docs/version-3.10.0/assets/user-guides/resilience-probes/delete-probe/step-2.png new file mode 100644 index 00000000..d6714c1c Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/resilience-probes/delete-probe/step-2.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/resilience-probes/delete-probe/step-3.png b/website/versioned_docs/version-3.10.0/assets/user-guides/resilience-probes/delete-probe/step-3.png new file mode 100644 index 00000000..c1d60b56 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/resilience-probes/delete-probe/step-3.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/resilience-probes/edit-probe/step-1.png b/website/versioned_docs/version-3.10.0/assets/user-guides/resilience-probes/edit-probe/step-1.png new file mode 100644 index 00000000..d9657006 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/resilience-probes/edit-probe/step-1.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/resilience-probes/edit-probe/step-2.png b/website/versioned_docs/version-3.10.0/assets/user-guides/resilience-probes/edit-probe/step-2.png new file mode 100644 index 00000000..574e2c9b Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/resilience-probes/edit-probe/step-2.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/resilience-probes/edit-probe/step-3.png b/website/versioned_docs/version-3.10.0/assets/user-guides/resilience-probes/edit-probe/step-3.png new file mode 100644 index 00000000..573c18cb Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/resilience-probes/edit-probe/step-3.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/resilience-probes/view-probe/step-1.png b/website/versioned_docs/version-3.10.0/assets/user-guides/resilience-probes/view-probe/step-1.png new file mode 100644 index 00000000..a0767f90 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/resilience-probes/view-probe/step-1.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/resilience-probes/view-probe/step-2.png b/website/versioned_docs/version-3.10.0/assets/user-guides/resilience-probes/view-probe/step-2.png new file mode 100644 index 00000000..209ff6ae Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/resilience-probes/view-probe/step-2.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/resilience-probes/view-probe/step-3.png b/website/versioned_docs/version-3.10.0/assets/user-guides/resilience-probes/view-probe/step-3.png new file mode 100644 index 00000000..b1d73599 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/resilience-probes/view-probe/step-3.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/teaming/accept-invite/step-1.png b/website/versioned_docs/version-3.10.0/assets/user-guides/teaming/accept-invite/step-1.png new file mode 100644 index 00000000..bc0f1a02 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/teaming/accept-invite/step-1.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/teaming/accept-invite/step-2.png b/website/versioned_docs/version-3.10.0/assets/user-guides/teaming/accept-invite/step-2.png new file mode 100644 index 00000000..5dbf0ec4 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/teaming/accept-invite/step-2.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/teaming/edit-invite/step-1.png b/website/versioned_docs/version-3.10.0/assets/user-guides/teaming/edit-invite/step-1.png new file mode 100644 index 00000000..7be1d24e Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/teaming/edit-invite/step-1.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/teaming/invite-team-member/step-1.png b/website/versioned_docs/version-3.10.0/assets/user-guides/teaming/invite-team-member/step-1.png new file mode 100644 index 00000000..619578d7 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/teaming/invite-team-member/step-1.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/teaming/invite-team-member/step-2.png b/website/versioned_docs/version-3.10.0/assets/user-guides/teaming/invite-team-member/step-2.png new file mode 100644 index 00000000..63bd8398 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/teaming/invite-team-member/step-2.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/teaming/remove-team-member/step-1.png b/website/versioned_docs/version-3.10.0/assets/user-guides/teaming/remove-team-member/step-1.png new file mode 100644 index 00000000..2abdae92 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/teaming/remove-team-member/step-1.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/teaming/remove-team-member/step-2.png b/website/versioned_docs/version-3.10.0/assets/user-guides/teaming/remove-team-member/step-2.png new file mode 100644 index 00000000..763a923f Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/teaming/remove-team-member/step-2.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/uninstall-litmus/disconnect-icon.png b/website/versioned_docs/version-3.10.0/assets/user-guides/uninstall-litmus/disconnect-icon.png new file mode 100644 index 00000000..e01cd45e Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/uninstall-litmus/disconnect-icon.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/upgrade/upgrade-agent.png b/website/versioned_docs/version-3.10.0/assets/user-guides/upgrade/upgrade-agent.png new file mode 100644 index 00000000..1b803d5a Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/upgrade/upgrade-agent.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/user-management/create-user/step-1.png b/website/versioned_docs/version-3.10.0/assets/user-guides/user-management/create-user/step-1.png new file mode 100644 index 00000000..bf97a3f7 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/user-management/create-user/step-1.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/user-management/create-user/step-2.png b/website/versioned_docs/version-3.10.0/assets/user-guides/user-management/create-user/step-2.png new file mode 100644 index 00000000..e40b11be Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/user-management/create-user/step-2.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/user-management/create-user/step-3.png b/website/versioned_docs/version-3.10.0/assets/user-guides/user-management/create-user/step-3.png new file mode 100644 index 00000000..eac68c99 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/user-management/create-user/step-3.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/user-management/deactivate-user/step-1.png b/website/versioned_docs/version-3.10.0/assets/user-guides/user-management/deactivate-user/step-1.png new file mode 100644 index 00000000..413ac2d9 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/user-management/deactivate-user/step-1.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/user-management/deactivate-user/step-2.png b/website/versioned_docs/version-3.10.0/assets/user-guides/user-management/deactivate-user/step-2.png new file mode 100644 index 00000000..8f83055a Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/user-management/deactivate-user/step-2.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/user-management/deactivate-user/step-3.png b/website/versioned_docs/version-3.10.0/assets/user-guides/user-management/deactivate-user/step-3.png new file mode 100644 index 00000000..df0d1f13 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/user-management/deactivate-user/step-3.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/user-management/reset-password/step-1.png b/website/versioned_docs/version-3.10.0/assets/user-guides/user-management/reset-password/step-1.png new file mode 100644 index 00000000..1d0474f4 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/user-management/reset-password/step-1.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/user-management/reset-password/step-2.png b/website/versioned_docs/version-3.10.0/assets/user-guides/user-management/reset-password/step-2.png new file mode 100644 index 00000000..c1b98676 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/user-management/reset-password/step-2.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/user-guides/user-management/view-user/step-1.png b/website/versioned_docs/version-3.10.0/assets/user-guides/user-management/view-user/step-1.png new file mode 100644 index 00000000..19fc30e9 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/user-guides/user-management/view-user/step-1.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/workflow-observe-completed.png b/website/versioned_docs/version-3.10.0/assets/workflow-observe-completed.png new file mode 100644 index 00000000..cb29658e Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/workflow-observe-completed.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/workflow-observe-log.png b/website/versioned_docs/version-3.10.0/assets/workflow-observe-log.png new file mode 100644 index 00000000..c2fd5c71 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/workflow-observe-log.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/workflow-observe-running.png b/website/versioned_docs/version-3.10.0/assets/workflow-observe-running.png new file mode 100644 index 00000000..f4a93b10 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/workflow-observe-running.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/workflow-observe-select.png b/website/versioned_docs/version-3.10.0/assets/workflow-observe-select.png new file mode 100644 index 00000000..7b6d4374 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/workflow-observe-select.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/workflow-observe-table-logs.png b/website/versioned_docs/version-3.10.0/assets/workflow-observe-table-logs.png new file mode 100644 index 00000000..37c41ca0 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/workflow-observe-table-logs.png differ diff --git a/website/versioned_docs/version-3.10.0/assets/workflow-observe-table.png b/website/versioned_docs/version-3.10.0/assets/workflow-observe-table.png new file mode 100644 index 00000000..f3b655d6 Binary files /dev/null and b/website/versioned_docs/version-3.10.0/assets/workflow-observe-table.png differ diff --git a/website/versioned_docs/version-3.10.0/best-practices.md b/website/versioned_docs/version-3.10.0/best-practices.md new file mode 100644 index 00000000..ff53dda5 --- /dev/null +++ b/website/versioned_docs/version-3.10.0/best-practices.md @@ -0,0 +1,27 @@ +--- +id: best-practices +title: Best Practices +sidebar_label: Best Practices +--- + +--- + +## Probes + +#### Restrict execution scope + +- In the case where a malicious, privileged user (who doesn't have cluster access) tries to extract the SA token from the probe pod and leverages it for destructive action, the recommended way to prevent it would be to have a reduced scope within the service account itself i.e. create an RBAC without loopholes. + + The RBAC for the agent itself can be subject to scrutiny before deployment, it can be restricted to a namespace with verbs against restricted resources, etc. The agent setup can be performed using Helm too, with changes to templates undergoing review. + + The intent of the command probe pod is to allow the users to perform custom checks which allow them to either (a) validate the impact of chaos, either within or outside the cluster (b) manually trigger remediation or (c) perform tasks that complement the chaos itself (such as load etc.,). + + Having a restrictive scope for this feature would depend on what kind of tasks are allowed by the cluster/devops admins within the purview of (a), (b), (c) - rather than being imposed from within the product by default. If some of the validations involve performing kube-api calls, we would need to support that / binding the admin's decision. + +- Only users with **Executor** roles can carry out executing probes. Project **Owners**, however, wield the authority to create, edit, and execute probes, shaping them to suit project needs and objectives. This division ensures efficient probe management, with the Executors handling execution and the project Owners overseeing customization and design. + +#### Future Roadmap + +- Resilience probes addition and execution are to be supported via ChaosHub and is also expected to have preset templates. The change entails probes being introduced as first class citizens/resources within the platform that can be reused across experiments via Hub. In this context, the ability to create and modify experiments/probes can be provided to a owner persona, with the probes being maintained in a Git repository (with its introduction in ChaosHub), which is also expected to have the right number of approvals for use. These are then executed as is by the executor persona on the platform. + +- Adding a command scanner to restrict malicious linux commands/attacks used against cmdProbes via enhanced checks. Integrate the command scanner into the CREATE and UPDATE APIs of cmdProbes ensures that all commands passed through these interfaces are subjected to thorough scrutiny. This involves modifying the API endpoints to include the command scanning functionality and implementing appropriate validation logic. diff --git a/website/versioned_docs/version-3.10.0/concepts/chaos-workflow.md b/website/versioned_docs/version-3.10.0/concepts/chaos-workflow.md new file mode 100644 index 00000000..824590e6 --- /dev/null +++ b/website/versioned_docs/version-3.10.0/concepts/chaos-workflow.md @@ -0,0 +1,428 @@ +--- +id: chaos-workflow +title: Chaos experiment +sidebar_label: Chaos experiment +--- + +--- + +Chaos experiments gives you the flexibility to create complex, real-life failure scenarios that are used to validate your target workloads. At the same time, chaos experiments are declarative and can be constructed using the ChaosCenter UI without any programmatic intervention. + +A chaos experiment is composed of chaos faults that are arranged in a specific order to create a failure scenario. The chaos faults target various aspects of an application, including the constituent microservices and underlying infrastructure. You can tune the parameters associated with these faults to impart the desired chaos behavior. + +- It is useful in automating a series of pre-conditioning steps or action which is necessary to be performed before triggering the chaos injection. + +- A Chaos Experiment can also be used to perform different operations parallelly to achieve a desired chaos impact. + +:::note +With the latest release of LitmusChaos 3.0.0: +The term **Chaos Experiment** has been changed to **Chaos Fault**. +The term **Chaos Scenario/Workflow** has been changed to **Chaos Experiment**. +::: + +## Prerequisites + +The following should be required before creating a Chaos Experiment: + +- [ChaosCenter](../getting-started/resources.md#chaoscenter) +- [Chaos Infrastructure](../getting-started/resources.md#chaosagents) +- [Probes](probes.md) + +## Defining and executing a chaos experiment + +LitmusChaos leverages the popular GitOps tool **Argo** to achieve this goal. Argo enables the creation of different chaos experiments together in form of chaos experiments which are extremely simple and efficient to use. + +With the help of **ChaosCenter**, chaos experiments with different types of faults can be created. In a Chaos Experiment, the faults can be set to execute in parallel to each other and the user can tune the chaos experiment by adding additional steps to simulate a desired fault that might occur in the production stage. + +### Chaos experiment life cycle + +Here is a sample pod-delete chaos experiment 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: 3.0.0 + 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:3.0.0 + 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: 3.0.0 + 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 experiment is similar to that of a Kubernetes Object. It consists of mandatory fields like `apiVersion`, `kind`, `metadata`, `spec`. + +The **spec** in a Chaos Experiment is where the different steps are mentioned and the overall life cycle of the chaos experiment is described. +We can see different `templates` are present in the spec of a chaos experiment. + +``` +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 faults, executing the chaos engine of the faults, and at the end we have the revert chaos step which deletes/removes the resources that were created as part of the chaos experiment. + +Some additional checks can be added with the faults in the form of probes. These probes are defined in the ChaosEngines of the faults and are updated when the fault execution takes place. +The overall chaos experiment result can be viewed with the ChaosResult CRD which contains the `verdict` and the `probeSuccessPercentage` (a ratio of successful checks v/s total probes). + +## Chaos experiment run + +A chaos experiment run can be defined as a single/one-time execution of the chaos experiment. There can be multiple runs of a single chaos experiment. If the chaos experiment consists of a cron syntax, it will run periodically according to the cron provided in the chaos experiment. + +## Resilience Score + +**Resiliency score** is an overall measure of the resiliency of a system for a given chaos experiment, which is obtained upon executing the constituent experiment faults on that system. + +While creating a chaos experiment, certain weights are assigned to all the faults present in the chaos experiment. These weights signify the priority/importance of the fault. The higher the weight, the more significant the fault is. + +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 fault, we look for the Probe Success Percentage for that fault itself (Post Chaos) and calculate the total resilience result for that fault as a multiplication of the weight given and the probe success percentage returned after the Chaos Run. + +``` +Total Resilience for one single fault = (Weight Given to that fault * Probe Success Percentage) +Overall Resilience Score = Total Test Result / Sum of the assigned weights of the faults +``` + +## Cron chaos experiment + +Cron Chaos Experiment is a type of chaos experiment that runs on a pre-defined schedule. It consists of a mandatory field `spec.schedule`. A cron syntax is provided in this field at which the chaos experiment execution takes +place. + +Here's a sample Cron Chaos Experiment 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 experiment, we can see the cron syntax at `spec.schedule` is + +``` +spec: + schedule: 10 0-23 * * * +``` + +This means the chaos experiment will be executed at the 10th minute of every hour. + +A chaos experiment can be changed into Cron Chaos Experiment from the ChaosCenter. +While scheduling a chaos experiment, in the `Schedule` step, there are few options as part of Recurring Schedules. These include: + +- Every hour +- Every Day +- Every Week +- Every Month + +## Summary + +A chaos experiment is a combination of different steps combined together to perform a specific chaos use-case on a Kubernetes system. These steps can include installing fault steps, ChaosEngine CR for target selection, revert-chaos steps, etc. Chaos Experiments can be scheduled for a later time with the help of Cron Chaos Experiments. +These chaos experiments consist of a cron syntax that is used for scheduling a chaos experiment. Once the chaos experiment execution is completed, the resiliency of the targeted application is calculated. Several weights are assigned to different faults in the chaos experiment. These weights are used along with the ProbeSuccessPercentage to find out the resiliency score. + +## Learn More + +- [Explore Probes](probes.md) +- [Visualize a Chaos Experiment](visualize-experiment.md) diff --git a/website/versioned_docs/version-3.10.0/concepts/chaoshub.md b/website/versioned_docs/version-3.10.0/concepts/chaoshub.md new file mode 100644 index 00000000..15ccac93 --- /dev/null +++ b/website/versioned_docs/version-3.10.0/concepts/chaoshub.md @@ -0,0 +1,105 @@ +--- +id: chaoshub +title: ChaosHub +sidebar_label: ChaosHub +--- + +--- + +A ChaosHub is a collection of experiment templates and faults that you can use to create and launch chaos experiments. Both experiments and faults are stored as manifests in an appropriate directory structure. This way, new experiment templates and faults can be added directly to the repository as files. In addition, the experiment templates can be derived from the existing experiments to be saved in ChaosHub from the web UI. + +- ChaosHub is accessed using a Git service provider such as GitHub, where ChaosHub exists as a repository. This allows native version control and management of the faults and experiment artifacts. + +- Chaos experiments can be created from the public [ChaosHub](http://hub.litmuschaos.io/) which is already connected to your ChaosCenter, or a custom ChaosHub which is a [fork](https://github.com/litmuschaos/chaos-charts) of the public ChaosHub where custom faults can be stored. + +## Prerequisites + +The following are the prerequisites for creating a Chaos Experiment: + +- 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 to a Git repository using ChaosHub + +With ChaosHub, you can construct chaos experiments by selecting, tuning and sequencing different faults together from their connected ChaosHubs. + +You can make changes in your forked repositories and sync it with the Portal to get the latest changes from the fork. + +By default, a public ChaosHub is provided when the ChaosCenter is installed for the first time. + + + +### 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 ChaosHub, you need provide the hub name, Git URL of the forked repository and the branch name similar to that of public hub and the repository can be connected in two ways: + + + +#### a. Access token + +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 experiments and experiments in a ChaosHub + +### 1. View the PreDefined Chaos Experiments + +After connecting a ChaosHub, you can view the different pre-defined chaos experiments present in the ChaosHub. + + + +### 2. View the Chaos Faults + +Similarly, you can view the different charts and the fault. These charts are sorted according to different categories like generic, AWS, Azure, Kube-Components etc. + + + +### 3. View the fault details + +You can select one of the chaos faults and can examine the fault details. The fault page consists of all the important details like the description of the fault, a tutorial video, the maintainer of the fault, etc. + +You can also find the Experiment manifest URL, RBAC URL, and the ChaosEngine URLs of the fault. +These URLs are required for the creation of custom chaos experiments. + + + +## Disconnect a ChaosHub + +To remove a ChaosHub from a project, you can select the **Disconnect Hub** option from the ChaosHub card. + +## Summary + +You can select one of the chaos faults and can examine the fault details.The fault page consists of all the important details like the description of the fault, a tutorial video, the maintainer of the fault, etc. +You can also find the Experiment URL URL, RBAC URL, and the ChaosEngine yaml URL of the fault. +These yaml URLs are required for the creation of Custom Chaos Experiments. + +## Learn More + +- [What is a Chaos Experiment](chaos-workflow.md) diff --git a/website/versioned_docs/version-3.10.0/concepts/gitops.md b/website/versioned_docs/version-3.10.0/concepts/gitops.md new file mode 100644 index 00000000..05c725ab --- /dev/null +++ b/website/versioned_docs/version-3.10.0/concepts/gitops.md @@ -0,0 +1,49 @@ +--- +id: gitops +title: Litmus with GitOps +sidebar_label: GitOps +--- + +--- + +## Prerequisites + +- Chaos Infrastructure +- [Chaos Experiment](chaos-workflow.md) + +The GitOps feature in Litmus enables you to configure a single source of truth for your chaos experiments and faults, 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 experiments directly from git enabling a vast scope of automation in CI/CD pipelines. + +:::note +With the latest release of LitmusChaos 3.0.0: + +
  • The term Chaos Experiment has been changed to Chaos Fault.
  • +
  • The term Chaos Scenario/Workflow has been changed to Chaos Experiment.
  • +::: + +## 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 experiments 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 experiments 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 infrastructure and can be more than one, other is the self chaos infrastructure where the Litmus(red cluster) is installed. After a chaos infrastructure 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: The 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 experiment using `workflow_id` from the git repository. Once it gets the required chaos experiment, it will send it to the subscriber which is responsible for applying the chaos experiment to the target cluster. After the chaos experiment 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 experiment identity which will be subscribed by the target application deployment and it is present in the chaos experiment 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. + +## Learn More + +- [Configuring GitOps](../user-guides/gitops-configuration.md) +- [Schedule a Chaos Experiment](../user-guides/schedule-experiment.md) +- [Observe a Chaos Experiment](../user-guides/observe-experiment.md) diff --git a/website/versioned_docs/version-3.10.0/concepts/infrastructure.md b/website/versioned_docs/version-3.10.0/concepts/infrastructure.md new file mode 100644 index 00000000..32f743d1 --- /dev/null +++ b/website/versioned_docs/version-3.10.0/concepts/infrastructure.md @@ -0,0 +1,31 @@ +--- +id: chaos-infrastructure +title: Chaos infrastructure +sidebar_label: Chaos infrastructure +--- + +Chaos infrastructure is a service that runs in your target environment and aids the Litmus control plane in accessing and injecting chaos at a cloud-native scale. All the chaos infrastructure services adhere to the principle of least privilege, where the services execute with the minimum number of required permissions. A chaos infrastructure can be created under a Chaos Environment. + +:::note +With the latest release of LitmusChaos 3.0.0 the term **Chaos Delegate/Agent** has been changed to **Chaos Infrastructure**. +::: + +## Chaos environment + +An environment represents where you are installing your chaos infrastructure and acts as an additional level of abstraction for the same. You categorize each environment as prod or non-prod. + +### Access types + +Chaos infrastructure can be created in two modes: + +- **Cluster Wide:** This mode of infrastructure installation allows targeting resources across the entire cluster, in all the namespaces, as part of an experiment. +- **Namespace Mode:** This mode of infrastructure installation allows targeting resources only in the namespace where the chaos infrastructure is deployed. + +:::note +- There can only be one cluster-wide chaos infrastructure per cluster. +- There may be multiple namespace-scoped chaos infrastructures per cluster. +::: + +## Learn more + +- [How to connect a Chaos Infrastructure](../user-guides/chaos-infrastructure-installation.md) diff --git a/website/versioned_docs/version-3.10.0/concepts/oauth-dex-concept.md b/website/versioned_docs/version-3.10.0/concepts/oauth-dex-concept.md new file mode 100644 index 00000000..0ac2cd33 --- /dev/null +++ b/website/versioned_docs/version-3.10.0/concepts/oauth-dex-concept.md @@ -0,0 +1,44 @@ +--- +id: oauth-dex-concept +title: Authentication in ChaosCenter +sidebar_label: Authentication in ChaosCenter +--- + +--- + +## 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 **litmusctl** and **litmusportal-frontend** make use of this server. + +In order to provide enhanced and seamless login features, we wanted to integrate OAuth and other authentication mechanisms such as OpenID connect. To have flexibility, litmus-portal makes use of an additional component, [Dex OIDC server](https://dexidp.io/). + +Dex is a highly extensible cloud-native OIDC provider that is able to take care of various authentication mechanisms. With Dex being deployed, the authentication-server can communicate with the dex-server which enables the 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-3.10.0/concepts/overview.md b/website/versioned_docs/version-3.10.0/concepts/overview.md new file mode 100644 index 00000000..5f2e2134 --- /dev/null +++ b/website/versioned_docs/version-3.10.0/concepts/overview.md @@ -0,0 +1,41 @@ +--- +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. + +### [Probes](probes.md) + +Probes are pluggable checks that can be defined within the ChaosEngine for any Chaos Fault. + +### [ChaosHub](chaoshub.md) + +ChaosHub allows you to orchestrate chaos experiments from the Public **[ChaosHub](http://hub.litmuschaos.io/)** or an alternate source for the Faults. + +### [Chaos Experiment](chaos-workflow.md) + +Chaos Experiment is a set of different operations coupled together to achieve desired chaos impact on a Kubernetes Cluster. + +### [Chaos Infrastructure](infrastructure.md) + +Chaos infrastructure is a service that runs in your target environment and aids Litmus control plane in accessing and injecting chaos. + +### [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 experiment with multiple different projects across different chaos infrastructures. + +### [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 experiments and faults. diff --git a/website/versioned_docs/version-3.10.0/concepts/probes.md b/website/versioned_docs/version-3.10.0/concepts/probes.md new file mode 100644 index 00000000..4547c756 --- /dev/null +++ b/website/versioned_docs/version-3.10.0/concepts/probes.md @@ -0,0 +1,1137 @@ +--- +id: probes +title: Resilience Probes +sidebar_label: Resilience Probes +--- + +--- + +Resilience Probes are pluggable checks that can be defined within the ChaosEngine for any Chaos Experiment. The fault pods execute these checks based on the mode they are defined in & factor their success as necessary conditions in determining the verdict of the fault (along with the standard `in-built` checks). + +## Prerequisites + +To understand the concepts of Probes better make sure you are aware of the [ChaosEngine](glossary.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. +- **initialDelay**: Represents the initial waiting time interval for the probes. +- **stopOnFailure**: It can be set to true/false to stop or continue the fault execution after probe fails. + +:::note +If probe needs any additional RBAC permissions other than the fault'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 fault uses to gauge health/service availability (or other custom conditions) as part of the entry/exit criteria. The received status code is mapped against an expected status. It supports HTTP `Get` and `Post` methods. + +In HTTP `Get` method, it sends an HTTP `GET` request to the provided URL and matches the response code based on the given criteria (`==`, `!=`, `oneOf`). + +In HTTP `Post` method, it sends an HTTP `POST` request to the provided URL. The http body can be provided in the `body` field. In the case of a complex POST request in which the body spans multiple lines, the `bodyPath` attribute can be used to provide the path to a file consisting of the same. This file can be made available to the fault pod via a ConfigMap resource, with the ConfigMap name being defined in the [ChaosEngine](glossary.md) OR the ChaosExperiment CR. +It can be defined at `.spec.experiments[].spec.probe` inside ChaosEngine. + +> `body` and `bodyPath` are mutually exclusive + +```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: 5s + interval: 5s + retry: 1 + probePollingInterval: 2s +``` + +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 fault 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: 5s + interval: 5s + retry: 1 + initialDelay: 5s +``` + +> `source.hostNetwork` can be set to `true` to allow access to the node network namespace for the pod executing the probe + +For insights into efficient chaos probe practices and our roadmap for the future, check out the [best practices](../best-practices.md#probes). + +### 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 fault 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: 5s + interval: 5s + 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 fault 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 fault 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: 5s + interval: 5s + retry: 1 +``` + +
    + +--- + +## Probe Status & Deriving Inferences + +The litmus chaos faults 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 fault 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 a fault 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 fault 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 fault 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: 5s + interval: 5s + 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: 5s + interval: 5s + 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
    DescriptionFlag to hold the name of the probe
    TypeMandatory
    Rangen/a type: string
    NotesThe .name holds the name of the probe. It can be set based on the usecase
    + + + + + + + + + + + + + + + + + + + + + + +
    Field.type
    DescriptionFlag to hold the type of the probe
    TypeMandatory
    Range httpProbe, k8sProbe, cmdProbe, promProbe
    NotesThe .type supports four type of probes. It can one of the httpProbe, k8sProbe, cmdProbe, promProbe
    + + + + + + + + + + + + + + + + + + + + + + +
    Field.mode
    DescriptionFlag to hold the mode of the probe
    TypeMandatory
    Range SOT, EOT, Edge, Continuous, OnChaos
    NotesThe .mode supports five modes of probes. It can one of the SOT, EOT, Edge, Continuous, OnChaos
    + + + + + + + + + + + + + + + + + + + + + + +
    Field.data
    DescriptionFlag to hold the data for the create operation of the k8sProbe
    TypeOptional
    Rangen/a type: string
    NotesThe .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
    DescriptionFlag to hold the group of the kubernetes resource for the k8sProbe
    TypeMandatory
    Range n/a type: string
    NotesThe .k8sProbe/inputs.group contains group of the kubernetes resource on which k8sProbe performs the specified operation
    + + + + + + + + + + + + + + + + + + + + + + +
    Field.k8sProbe/inputs.version
    DescriptionFlag to hold the apiVersion of the kubernetes resource for the k8sProbe
    TypeMandatory
    Range n/a type: string
    NotesThe .k8sProbe/inputs.version contains apiVersion of the kubernetes resource on which k8sProbe performs the specified operation
    + + + + + + + + + + + + + + + + + + + + + + +
    Field.k8sProbe/inputs.resource
    DescriptionFlag to hold the kubernetes resource name for the k8sProbe
    TypeMandatory
    Range n/a type: string
    NotesThe .k8sProbe/inputs.resource contains the kubernetes resource name on which k8sProbe performs the specified operation
    + + + + + + + + + + + + + + + + + + + + + + +
    Field.k8sProbe/inputs.namespace
    DescriptionFlag to hold the namespace of the kubernetes resource for the k8sProbe
    TypeMandatory
    Range n/a type: string
    NotesThe .k8sProbe/inputs.namespace contains namespace of the kubernetes resource on which k8sProbe performs the specified operation
    + + + + + + + + + + + + + + + + + + + + + + +
    Field.k8sProbe/inputs.fieldSelector
    DescriptionFlag to hold the fieldSelectors of the kubernetes resource for the k8sProbe
    TypeOptional
    Range n/a type: string
    NotesThe .k8sProbe/inputs.fieldSelector contains fieldSelector to derived the kubernetes resource on which k8sProbe performs the specified operation
    + + + + + + + + + + + + + + + + + + + + + + +
    Field.k8sProbe/inputs.labelSelector
    DescriptionFlag to hold the labelSelectors of the kubernetes resource for the k8sProbe
    TypeOptional
    Range n/a type: string
    NotesThe .k8sProbe/inputs.labelSelector contains labelSelector to derived the kubernetes resource on which k8sProbe performs the specified operation
    + + + + + + + + + + + + + + + + + + + + + + +
    Field.k8sProbe/inputs.operation
    DescriptionFlag to hold the operation type for the k8sProbe
    TypeMandatory
    Rangecreate, delete, present, absent
    NotesThe .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
    DescriptionFlag to hold the command for the cmdProbe
    TypeMandatory
    Rangen/a type: string
    NotesThe .cmdProbe/inputs.command contains the shell command, which should be run as part of cmdProbe
    + + + + + + + + + + + + + + + + + + + + + + +
    Field.cmdProbe/inputs.source.image
    DescriptionFlag to hold the image for the cmdProbe
    TypeOptional
    Rangeany source docker image
    NotesThe .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
    DescriptionFlag to allow or deny the .cmdProbe/inputs.source.image access to the node network namespace
    TypeOptional
    Rangetrue, false
    NotesThe .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
    DescriptionFlag to hold the URL for the httpProbe
    TypeMandatory
    Range n/a type: string
    NotesThe .httpProbe/inputs.url contains the URL which the fault uses to gauge health/service availability (or other custom conditions) as part of the entry/exit criteria.
    + + + + + + + + + + + + + + + + + + + + + + +
    Field.httpProbe/inputs.insecureSkipVerify
    DescriptionFlag to hold the flag to skip certificate checks for the httpProbe
    TypeOptional
    Range true, false
    NotesThe .httpProbe/inputs.insecureSkipVerify contains flag to skip certificate checks.
    + + + + + + + + + + + + + + + + + + + + + + +
    Field.httpProbe/inputs.responseTimeout
    DescriptionFlag to hold the flag to response timeout for the httpProbe
    TypeOptional
    Range n/a type: integer
    NotesThe .httpProbe/inputs.responseTimeout contains flag to provide the response timeout for the http Get/Post request.
    + + + + + + + + + + + + + + + + + + + + + + +
    Field.httpProbe/inputs.method.get.criteria
    DescriptionFlag to hold the criteria for the http get request
    TypeMandatory
    Range ==, !=, oneOf
    NotesThe .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
    DescriptionFlag to hold the expected response code for the get request
    TypeMandatory
    Range HTTP_RESPONSE_CODE
    NotesThe .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
    DescriptionFlag to hold the content type of the post request
    TypeMandatory
    Range n/a type: string
    NotesThe .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
    DescriptionFlag to hold the body of the http post request
    TypeMandatory
    Range n/a type: string
    NotesThe .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
    DescriptionFlag to hold the path of the http body, required for the http post request
    TypeOptional
    Range n/a type: string
    NotesThe .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 fault pod via a ConfigMap resource, with the ConfigMap name being defined in the ChaosEngine OR the ChaosExperiment CR.
    + + + + + + + + + + + + + + + + + + + + + + +
    Field.httpProbe/inputs.method.post.criteria
    DescriptionFlag to hold the criteria for the http post request
    TypeMandatory
    Range ==, !=, oneOf
    NotesThe .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
    DescriptionFlag to hold the expected response code for the post request
    TypeMandatory
    Range HTTP_RESPONSE_CODE
    NotesThe .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
    DescriptionFlag to hold the prometheus endpoints for the promProbe
    TypeMandatory
    Range n/a type: string
    NotesThe .promProbe/inputs.endpoint contains the prometheus endpoints
    + + + + + + + + + + + + + + + + + + + + + + +
    Field.promProbe/inputs.query
    DescriptionFlag to hold the promql query for the promProbe
    TypeMandatory
    Range n/a type: string
    NotesThe .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
    DescriptionFlag to hold the path of the promql query for the promProbe
    TypeOptional
    Range n/a type: string
    NotesThe .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 fault pod via a ConfigMap resource, with the ConfigMap name being defined in the ChaosEngine OR the ChaosExperiment CR.
    + +### Runproperties + + + + + + + + + + + + + + + + + + + + + + +
    Field.runProperties.probeTimeout
    DescriptionFlag to hold the timeout for the probes
    TypeMandatory
    Rangen/a type: string
    NotesThe .runProperties.probeTimeout represents the time limit for the probe to execute the specified check and return the expected data
    + + + + + + + + + + + + + + + + + + + + + + +
    Field.runProperties.retry
    DescriptionFlag to hold the retry count for the probes
    TypeMandatory
    Rangen/a type: integer
    NotesThe .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
    DescriptionFlag to hold the interval for the probes
    TypeMandatory
    Rangen/a type: string
    NotesThe .runProperties.interval contains the interval for which probes waits between subsequent retries
    + + + + + + + + + + + + + + + + + + + + + + +
    Field.runProperties.probePollingInterval
    DescriptionFlag to hold the polling interval for the probes(applicable for Continuous mode only)
    TypeOptional
    Rangen/a type: string
    NotesThe .runProperties.probePollingInterval contains the time interval for which continuous probe should be sleep after each iteration
    + + + + + + + + + + + + + + + + + + + + + + +
    Field.runProperties.initialDelay
    DescriptionFlag to hold the initial delay interval for the probes
    TypeOptional
    Rangen/a type: string
    NotesThe .runProperties.initialDelaySeconds represents the initial waiting time interval for the probes.
    + + + + + + + + + + + + + + + + + + + + + + +
    Field.runProperties.stopOnFailure
    Description Flags to hold the stop or continue the fault on probe failure
    TypeOptional
    Rangefalse type: boolean
    NotesThe .runProperties.stopOnFailure can be set to true/false to stop or continue the fault execution after probe fails
    + +### Comparator + + + + + + + + + + + + + + + + + + + + + + +
    Fieldtype
    DescriptionFlag to hold type of the data used for comparision
    TypeMandatory
    Range string, int, float
    NotesThe type contains type of data, which should be compare as part of comparision operation
    + + + + + + + + + + + + + + + + + + + + + + +
    Fieldcriteria
    DescriptionFlag to hold criteria for the comparision
    TypeMandatory
    Range it supports {`>=, <=, ==, >, <, !=, oneOf, between`} for int & float type. And equal, notEqual, contains, matches, notMatches, oneOf for string type.
    NotesThe criteria contains criteria of the comparision, which should be fulfill as part of comparision operation.
    + + + + + + + + + + + + + + + + + + + + + + +
    Fieldvalue
    DescriptionFlag to hold value for the comparision
    TypeMandatory
    Range n/a type: string
    NotesThe value contains value of the comparision, which should follow the given criteria as part of comparision operation.
    + +## 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 fault 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 faults 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 fault depends purely on the order in which they are defined in the ChaosEngine. + +:::note +With the latest release of LitmusChaos 3.0.0: + +
  • The term Chaos Experiment has been changed to Chaos Fault.
  • +
  • The term Chaos Scenario/Workflow has been changed to Chaos Experiment.
  • +::: + +## Learn more + +- [Explore the Custom Resources](glossary.md) diff --git a/website/versioned_docs/version-3.10.0/concepts/projects.md b/website/versioned_docs/version-3.10.0/concepts/projects.md new file mode 100644 index 00000000..548cb9b7 --- /dev/null +++ b/website/versioned_docs/version-3.10.0/concepts/projects.md @@ -0,0 +1,35 @@ +--- +id: projects +title: Projects +sidebar_label: Projects +--- + +--- + +The ChaosCenter comes with a project management system that can be used for working on chaos experiments with multiple different projects across different chaos infrastructures. + +## Prerequisites + +Before learning about the concept of projects, it is important to note that a project signifies a separation between Chaos infrastructures, Schedules, [Visualization](visualize-experiment.md), and Teams (discussed in the next section) configurations, and prior knowledge of these will prove fruitful in understanding the concept of projects in-depth. + +## 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-3.10.0/concepts/teaming.md b/website/versioned_docs/version-3.10.0/concepts/teaming.md new file mode 100644 index 00000000..9515905f --- /dev/null +++ b/website/versioned_docs/version-3.10.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 + +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 `Executor`, 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 create resources such as infrastructures, probes, hubs, experiments, etc, schedule chaos experiments, update and delete chaos experiments.They have both create and execute perimissions. +- **Executor:** Members invited with the executor role only have execute and view permissions which allow them to run/stop experiments, use probes etc, they don't have any create/delete permissions. +- **Viewer:** Members having a viewer role can only view the analytics related to the chaos experiments and the chaos experiments themselves, but are not given permission to schedule chaos experiments 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 + - Executor +- 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 Executor 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-3.10.0/concepts/user-management.md b/website/versioned_docs/version-3.10.0/concepts/user-management.md new file mode 100644 index 00000000..f339c178 --- /dev/null +++ b/website/versioned_docs/version-3.10.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 + +ChaosCenter supports two portal level roles for defining the privilege levels of a certain user: + +**Admin:** The admin user is created by default upon setup and can be used for logging in to the ChaosCenter using the credentials once the server pod (auth container) is up. + +**Non-admin users:** The admin of the ChaosCenter can exclusively create any number of non-admin users. + +## Role privileges + +**Admin:** It is the highest privilege role offered in the ChaosCenter which provides complete access to all the features. + +**Non-admin users:** Non-admin users get all the same privileges as an admin-level user, with the exception of the user management feature which is an admin-exclusive feature to facilitate an admin to manage their teams on the ChaosCenter. For example, in an organization there can be different teams who'd utilize different chaos infrastructures that have no layover between each other. + +## Learn more + +- [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-3.10.0/concepts/visualize-experiment.md b/website/versioned_docs/version-3.10.0/concepts/visualize-experiment.md new file mode 100644 index 00000000..be2c02fe --- /dev/null +++ b/website/versioned_docs/version-3.10.0/concepts/visualize-experiment.md @@ -0,0 +1,41 @@ +--- +id: visualize-experiment +title: Visualize chaos experiment +sidebar_label: Visualize chaos experiment +--- + +--- + +Visualization is an important aspect while doing chaos engineering. It allows the user to discover and inspect different changes that occur during a Chaos Experiment execution. With ChaosCenter, the real-time data and status of the chaos experiments can be observed. Valuable information like pod logs, chaos experiment status, and chaos results can also be viewed. + +## Prerequisites + +The following is required before visualizing a chaos experiment: + +- ChaosCenter +- [Chaos Experiments](chaos-workflow.md) + +## Create chaos experiment + +If the user chooses to **Save** and **Run** the experiment, they will be directed to the experiment execution page, where the experiment can be visualized. Otherwise, they will be taken to the chaos experiment page. + +## Visualize chaos experiment + +To observe a chaos experiment, user needs to select the highlighted experiment run box from the heatmap, it will redirect to experiment run execution page. + + +In the chaos experiment, a realtime graph of the chaos experiment is displayed. This graph contains valuable information regarding the status of individual steps of the chaos experiment. + +To view the details of each step, the user can click on the individual nodes and the right side pane will display the node details, results(once the execution is complete), and the logs related to it. +

    + + + +## Summary + +After scheduling a chaos experiment, a user can view the details of the running chaos experiment from the ChaosCenter. ChaosCenter provides a real-time graph that is used to visualize the chaos experiment and get the details of individual steps of the chaos experiment. Important details like the logs and target applications can be viewed from ChaosCenter. Once the chaos experiment execution is completed, the resiliency score is calculated and the ChaosResult for the ChaosEngine pods is available. + +## Learn More + +- [Explore Probes](probes.md) +- [What is a Chaos Experiment](chaos-workflow.md) diff --git a/website/versioned_docs/version-3.10.0/faq.md b/website/versioned_docs/version-3.10.0/faq.md new file mode 100644 index 00000000..3586151c --- /dev/null +++ b/website/versioned_docs/version-3.10.0/faq.md @@ -0,0 +1,99 @@ +--- +id: faq +title: FAQ +sidebar_label: FAQ +--- + +--- + +## Installation + +### 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 Chaoscenter-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. + +### What is the minimum system requirement to run Chaoscenter and chaos infrastructure together? + +To run Chaoscenter you need to have a minimum of 1 GiB memory and 1 core of CPU free. + +### 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. + +### Does Litmus 3.0 support backward compatibility with Litmus 2.0? + +No, LitmusChaos 3.0.0 is not backward compatible with LitmusChaos 2.0.0. + +### Can I run LitmusChaos Outside of my Kubernetes clusters? + +Yes, you can run the ansible faults 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. + +## Chaos Experiment + +### What does failed status of chaos experiment means in LitmusPortal? + +Failed status indicates that either there is some misconfiguration in the chaos experiment or the default hypothesis of fault was disproved and some of the faults in the chaos experiment failed, In such case the resiliency score will be less than 100. + +### How is resilience score calculated? + +The Resilience score is calculated on the basis of the weightage and the Probe Success Percentage of the fault. Resilience for one single fault is the multiplication of the weight given to that fault and the Probe Success Percentage. Then we get the total test result by adding the resilience score of all the faults. The Final Resilience Score is calculated by dividing the total test result by the sum of the weights of all the faults combined in the single chaos experiment. For more detail refer to [this blog](https://dev.to/litmus-chaos/how-the-resilience-score-algorithm-works-in-litmus-1d22). + +## Chaoshub + +### How can I setup chaoshub of my own gitlab repo in Chaoscenter? + +In the Chaoscenter 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 Chaoscenter and provide the GitLab URL and branch name along with the access token. After submitting, your own chaos hub is connected to the Chaoscenter. +For the SSH key, click on the SSH and it will generate a public key. You shall use this public key and put it in your GitLab account. Just go to the settings of GitLab, and 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 Chaoscenter along with the branch. After submitting, your own ChaosHub is connected to the Chaoscenter. + +## Gitops + +### How can users integrate Litmuschaos in their environment with Gitops? + +Gitops feature in Litmus enables users to sync chaos experiments from a configured git repo, any chaos experiment inserts/updates made to the repo will be monitored and picked up by ChaosCenter and will be executed on the target cluster. ChaosCenter 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 experiments can be triggered automatically. This integrates with other gitops tools like flux/argo cd and enables users to automatically run chaos experiments 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 experiments created will be stored in the configured repo in the path `litmus//.yaml`. + +## Litmusctl + +### Does Litmusctl support actions that are currently performed from the portal dashboard? + +Yes, Chaos Infrastructure connection, creation and chaos experiment execution are now being supported in Litmusctl. [documentation of litmusctl](https://github.com/litmuschaos/litmusctl/blob/master/Usage_0.23.0.md). + +### 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. + +## Usage + +### Can I use Litmus in Production? + +Yes, you can use Litmuschaos in production. Litmus has a wide variety of faults 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 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. diff --git a/website/versioned_docs/version-3.10.0/getting-started/installation.md b/website/versioned_docs/version-3.10.0/getting-started/installation.md new file mode 100644 index 00000000..77362a92 --- /dev/null +++ b/website/versioned_docs/version-3.10.0/getting-started/installation.md @@ -0,0 +1,261 @@ +--- +id: installation +title: ChaosCenter installation +sidebar_label: Installation +--- + +--- + +## Prerequisites + +- 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://app.harness.io/auth/#/signin). 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: +
  • Helm3 chart
  • +
  • Kubectl yaml spec file
  • +
    + 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 Experiments 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 infrastructure. +

    + To get started with Harness Chaos Engineering SaaS, visit Harness Chaos Engineering SaaS and register for free. You can skip the below installation steps. +
    +
    + +:::note +With 3.9.0 release, Cluster scope installation is deprecated. Now Namespaced mode is the only supported and standard installation mode. +::: + +### 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`. + +- Litmus helm chart depends on `bitnami/mongodb` [helm chart](https://github.com/bitnami/charts/tree/main/bitnami/mongodb), which uses a mongodb image not supported on ARM. If you want to install Litmus on an ARM-based server, please replace the default one with your custom mongodb arm image as shown below. + + ```bash + helm install chaos litmuschaos/litmus --namespace=litmus \ + --set portal.frontend.service.type=NodePort \ + --set mongodb.image.registry= \ + --set mongodb.image.repository= \ + --set mongodb.image.tag= + ``` + +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** + +In this method the users need to install mongo first via helm and then apply the installation manifest. Follow the instructions [here](https://github.com/litmuschaos/litmus/tree/master/chaoscenter#installation-steps-for-litmus-300-beta9). + +### **Install mongo** + +```bash + helm repo add bitnami https://charts.bitnami.com/bitnami +``` + +Mongo Values + +```bash +auth: + enabled: true + rootPassword: "1234" + # -- existingSecret Existing secret with MongoDB(®) credentials (keys: `mongodb-passwords`, `mongodb-root-password`, `mongodb-metrics-password`, ` mongodb-replica-set-key`) + existingSecret: "" +architecture: replicaset +replicaCount: 3 +persistence: + enabled: true +volumePermissions: + enabled: true +metrics: + enabled: false + prometheusRule: + enabled: false + +# bitnami/mongodb is not yet supported on ARM. +# Using unofficial tools to build bitnami/mongodb (arm64 support) +# more info: https://github.com/ZCube/bitnami-compat +#image: +# registry: ghcr.io/zcube +# repository: bitnami-compat/mongodb +# tag: 6.0.5 +``` + +```bash +helm install my-release bitnami/mongodb --values mongo-values.yml -n --create-namespace +``` + +Litmus supports for HTTP and HTTPS mode of installation. + +### Basic installation (HTTP based and allows all origins) + +Applying the manifest file will install all the required service account configuration and ChaosCenter in namespaced scope. + +```bash + kubectl apply -f https://raw.githubusercontent.com/litmuschaos/litmus/3.10.0/chaoscenter/manifests/litmus-getting-started.yaml -n +``` + +### Advanced installation (HTTPS based and CORS rules apply) + +For advanced installation visit [here](../user-guides/chaoscenter-advanced-installation.md) + +--- + +## **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 + litmusportal-frontend-55974fcf59-cxxrf 1/1 Running 0 58s + my-release-mongodb-0 1/1 Running 0 63s + my-release-mongodb-1 1/1 Running 0 63s + my-release-mongodb-2 1/1 Running 0 62s + my-release-mongodb-arbiter-0 1/1 Running 0 64s + + ``` + +- 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 + chaos-exporter ClusterIP 10.68.45.7 8080/TCP 23h + litmusportal-auth-server-service NodePort 10.68.34.91 9003:32368/TCP,3030:31051/TCP 23h + litmusportal-frontend-service NodePort 10.68.43.68 9091:30070/TCP 23h + litmusportal-server-service NodePort 10.68.33.242 9002:32455/TCP,8000:30722/TCP 23h + my-release-mongodb-arbiter-headless ClusterIP None 27017/TCP 23h + my-release-mongodb-headless ClusterIP None 27017/TCP 23h + workflow-controller-metrics ClusterIP 10.68.33.65 9090/TCP 23h + ``` + +--- + +## **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 `31846`. 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:31846/ +``` + +> Where `172.17.0.3` is my NodeIP and `31846` 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) + +**NOTE:** With advanced installation CORS rules are applied, once manifest is applied frontend loadbalancer IP needs to be added in the `ALLOWED_ORIGINS` environment in both auth and graphql server deployment. + +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 + +- [Install ChaosCenter with HTTPS](../user-guides/chaoscenter-advanced-installation.md) +- [Connect External Chaos Infrastructures to ChaosCenter](../user-guides/chaos-infrastructure-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-3.10.0/getting-started/resources.md b/website/versioned_docs/version-3.10.0/getting-started/resources.md new file mode 100644 index 00000000..4a686853 --- /dev/null +++ b/website/versioned_docs/version-3.10.0/getting-started/resources.md @@ -0,0 +1,39 @@ +--- +id: resources +title: Resources +sidebar_label: Resources +--- + +--- + +## ChaosCenter +ChaosCenter is a unified pane that controls all the functions provided by Litmus. It can be used for managing the entire lifecycle of the chaos experiments, including all the components within. + +ChaosCenter comes pre-packaged as a part of LitmusChaos installation and can be easily accessed via [Ingress](../user-guides/setup-with-ingress.md), [NodePort](../user-guides/setup-without-ingress.md#with-nodeport) or [LoadBalancer](../user-guides/setup-without-ingress.md#with-loadbalancer). Since Litmus has Cross-Cloud support, you get seamless access to the ChaosCenter irrespectively of where you deploy it. + +ChaosCenter gives you access to a plethora of features, the major ones include: + +- **Chaos experiment creation** + - From templates, custom experiments from scratch (using ChaosHubs), from pre-created YAMLs + - Experiments sequence control (parallel as well as sequential steps creation) + - Creation of either singular or cron experiments as schedules + - Attaching priority to experiments based on your use cases +- **Users and teams** + - Creation of users with Role Based Access Control + - Creating a team of multiple users + - Authenticating users +- **Chaos experiment management** + - Rolling out automated changes using GitOps + - Allowing image addition from custom image server (both public and private) + - Measure and analyze the Resilience Score of each chaos scenario + +## Chaos Infrastructures +Chaos infrastructure is a service that runs in your target environment and aids Litmus in accessing and injecting chaos to your target environment. There should always be at least one or more than one chaos infrastructure connected to the ChaosCenter to execute an experiment. + +## Types of Chaos Infrastructures + +In Litmus, chaos infrastructures can be classified into two types: + +- **Self Chaos Infrastructures:** A Chaos Infrastructure that is connected to the same cluster and namespace where the ChaosCenter is deployed. It can be used to target the workloads executing on that cluster only. + +- **External Chaos Infrastructures:** A Chaos Infrastructure that is connected to a remote Kubernetes cluster. ChaosCenter can be operated in a cross-cloud manner, which allows connecting multiple External Chaos Infrastructure to the same ChaosCenter with the help of the [litmusctl](../litmusctl/installation.md) CLI. Once connected you can manage, monitor, observe and induce chaos from the ChaosCenter to the respective External Chaos Infrastructures. diff --git a/website/versioned_docs/version-3.10.0/glossary.md b/website/versioned_docs/version-3.10.0/glossary.md new file mode 100644 index 00000000..2f99bc29 --- /dev/null +++ b/website/versioned_docs/version-3.10.0/glossary.md @@ -0,0 +1,59 @@ +--- +id: glossary +title: Glossary +sidebar_label: Glossary +--- + +:::note +Please note that Litmus 3.0 is not backward compatible and will require a fresh installation for users looking to migrate from previous versions +::: + +## Chaos Resources + +At the heart of the Litmus Platform are the chaos custom resources. This section consists of the specification (details of each field within the .spec & .status of the resources) as well as standard examples for tuning the supported parameters. + + + + + + + + + + + + + + + + + + + + + + +
    Chaos Resource NameDescriptionUser Guides
    ChaosEngineContains the ChaosEngine specifications user-guideChaosEngine
    ChaosExperimentContains the ChaosExperiment specifications user-guideChaosExperiment
    ChaosResultContains the ChaosResult specifications user-guideChaosResult
    + +## Terminology Changes + +With the latest release of LitmusChaos 3.0.0 the following terminologies have been changed: + + + + + + + + + + + + + + + + + + +
    Old terminologyUpdated terminology
    Chaos ExperimentChaos Fault
    Chaos Scenario/WorkflowChaos Experiment
    Chaos Delegate/AgentChaos Infrastructure
    diff --git a/website/versioned_docs/version-3.10.0/integrations/backstage.md b/website/versioned_docs/version-3.10.0/integrations/backstage.md new file mode 100644 index 00000000..92bbf335 --- /dev/null +++ b/website/versioned_docs/version-3.10.0/integrations/backstage.md @@ -0,0 +1,115 @@ +--- +id: backstage +title: Manage all components of Litmus in one place +sidebar_label: Backstage +--- + +--- + +[Backstage](https://backstage.io) is an open platform for building developer portals and is one of the most popular CNCF projects. It allows developers to manage cloud-native applications' numerous services and codes from a single point. Chaos engineering can verify an application's resilience. It gives you the opportunity to identify various vulnerabilities in your application. Therefore, having information about Litmus chaos experiments alongside other application elements, such as application code, and CI/CD pipeline information, is highly beneficial to developers. + +## Features + +### EntityLitmusCard + +- See the number and status of your experiments in a graph. +- See representative information about Litmus (number of Chaos Hubs, GitOps status, etc.). +- Provide a direct link to Litmus. + +![EntityLitmusCard](https://raw.githubusercontent.com/litmuschaos/backstage-plugin/master/docs/EntityLitmusCard.png) + +### EntityLitmusContent + +- The `Dev Info` section provides a number of useful links related to Litmus. +- The `Chaos Hubs` section provides information about the Chaos Hubs registered with Litmus. + - Clicking on each item will redirect you to that item's detailed page. +- The `Environments` section provides information about the environments and infrastructures registered with Litmus. + - Clicking on each item will redirect you to that item's detailed page. +- The `Experiments` section offers details on the Chaos Experiments that were created within the platform. + - If you hover over 'RECENT EXPERIMENT RUNS', you can view detailed information about the experiments including resiliency score and status. + - We can directly launch chaos experiments by clicking the play button. + +![EntityLitmusContent](https://raw.githubusercontent.com/litmuschaos/backstage-plugin/master/docs/EntityLitmusContent.png) + +## Before you begin + +- Compatible only with Litmus version [3.0.0](https://github.com/litmuschaos/litmus/releases/tag/3.0.0) or later. + +## Getting started + +1. In the `./packages/app` project add the plugin. + + ```yaml + yarn add backstage-plugin-litmus + ``` + +2. Get Litmus API Token through the Litmus UI + + 1. Click "SETTINGS" in the sidebar. + 2. Click "+ New Token" Button in the 'API Tokens' section. + ![settings_tab](https://raw.githubusercontent.com/litmuschaos/backstage-plugin/master/docs/settings_tab.png) + 3. Enter your information and click "Confirm". + ![create_dialog](https://raw.githubusercontent.com/litmuschaos/backstage-plugin/master/docs/create_dialog.png) + 4. Get the token in the "VALUE" column. + +3. In the `app-config.yaml` file root directory, add litmus proxy and info like below + ```yaml + proxy: + '/litmus': + target: 'your-own-litmus-ui-url' + changeOrigin: true + headers: + Authorization: 'Bearer ${LITMUS_AUTH_TOKEN}' + litmus: + baseUrl: 'your-own-litmus-ui-url' + apiToken: ${LITMUS_AUTH_TOKEN} + ``` +4. Add your auth key to the environmental variables + ```shell + export LITMUS_AUTH_TOKEN="your-own-token" + ``` +5. Adding annotations and values to your component file. + ```yaml + apiVersion: backstage.io/v1alpha1 + kind: Component + metadata: + name: component-name + description: 'description' + annotations: + litmuschaos.io/project-id: 'your-own-project-id' + ``` +6. Enabling frontend + + ```ts + // packages/app/src/components/catalog/EntityPage.tsx + import { isLitmusAvailable, EntityLitmusCard, EntityLitmusContent } from 'backstage-plugin-litmus' + // ... + const overviewContent = ( + + // ... + + + + + + + + // ... + + ) + // ... + const serviceEntityPage = ( + + // ... + + + + // ... + + ) + ``` + +## Resources + +- [GitHub](https://github.com/litmuschaos/backstage-plugin) +- [npm](https://www.npmjs.com/package/backstage-plugin-litmus) diff --git a/website/versioned_docs/version-3.10.0/integrations/grafana.md b/website/versioned_docs/version-3.10.0/integrations/grafana.md new file mode 100644 index 00000000..af717f1a --- /dev/null +++ b/website/versioned_docs/version-3.10.0/integrations/grafana.md @@ -0,0 +1,271 @@ +--- +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: + +- [Prometheus TSDB](https://prometheus.io/) +- [Prometheus Integration](prometheus.md) + +## Grafana setup with provisioned data source and 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: + +![image](https://github.com/litmuschaos/litmus/blob/master/monitoring/screenshots/sock-shop/chaos-result-selector.png?raw=true) + +#### Chaos Engine Context (Target application's NAMESPACE_LABEL) selector dropdown: + +![image](https://github.com/litmuschaos/litmus/blob/master/monitoring/screenshots/sock-shop/chaos-engine-context-selector.png?raw=true) + +#### Chaos Engines with Experiments as Chaos Results: + +![image](https://github.com/litmuschaos/litmus/blob/master/monitoring/screenshots/sock-shop/chaos-experiments.png?raw=true) + +#### Chaos event annotations: + +![image](https://github.com/litmuschaos/litmus/blob/master/monitoring/screenshots/sock-shop/chaos-event-annotation.png?raw=true) + +#### Chaos Result verdict annotations: + +![image](https://github.com/litmuschaos/litmus/blob/master/monitoring/screenshots/sock-shop/chaos-result-verdict-annotation.png?raw=true) + +#### Interleaved Chaos events: + +![image](https://github.com/litmuschaos/litmus/blob/master/monitoring/screenshots/sock-shop/interleaved-events.png?raw=true) + +#### Interleaved Chaos Result verdicts: + +![image](https://github.com/litmuschaos/litmus/blob/master/monitoring/screenshots/sock-shop/interleaved-results.png?raw=true) + +#### Chaos Result verdict failure alerts: + +![image](https://github.com/litmuschaos/litmus/blob/master/monitoring/screenshots/sock-shop/verdict-failure-alert.png?raw=true) + +#### Chaos Result probe failure alerts: + +![image](https://github.com/litmuschaos/litmus/blob/master/monitoring/screenshots/sock-shop/probe-failure-alert.png?raw=true) + +#### Systems healthy / in steady state OR no alerts to be issued: + +![image](https://github.com/litmuschaos/litmus/blob/master/monitoring/screenshots/sock-shop/no-alerts-issued.png?raw=true) + +#### Systems un-healthy / failed to regain steady state after chaos / meet SLO OR alerts are issued: + +![image](https://github.com/litmuschaos/litmus/blob/master/monitoring/screenshots/sock-shop/alerts-active.png?raw=true) + +#### Alerts issued: + +![image](https://github.com/litmuschaos/litmus/blob/master/monitoring/screenshots/sock-shop/alerts-sent.png?raw=true) + +## 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 + +- [Observability Setup](../user-guides/observability-set-up.md) diff --git a/website/versioned_docs/version-3.10.0/integrations/prometheus.md b/website/versioned_docs/version-3.10.0/integrations/prometheus.md new file mode 100644 index 00000000..c0d370d5 --- /dev/null +++ b/website/versioned_docs/version-3.10.0/integrations/prometheus.md @@ -0,0 +1,203 @@ +--- +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: + +- [Prometheus TSDB](https://prometheus.io/) +- [Probes](../concepts/probes.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 + +- [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-3.10.0/introduction/community.md b/website/versioned_docs/version-3.10.0/introduction/community.md new file mode 100644 index 00000000..2eaa655e --- /dev/null +++ b/website/versioned_docs/version-3.10.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. + + + + + + +
    + + +
    +
    + Community Sync Up +
    +
    + Meet and learn from the maintainers, contributors and developers of Litmus, everything about Chaos Engineering +
    +
    +
    + + +
    +
    + Kubernetes Chaos Engineering Meetup +
    +
    + Discussion about the best practices and tutorials for practicing Chaos Engineering +
    +
    +
    + +## 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-3.10.0/introduction/core-principles.md b/website/versioned_docs/version-3.10.0/introduction/core-principles.md new file mode 100644 index 00000000..ca27a9d5 --- /dev/null +++ b/website/versioned_docs/version-3.10.0/introduction/core-principles.md @@ -0,0 +1,35 @@ +--- +id: core-principles +title: Core principles of Litmus +sidebar_label: Core principles +--- + +--- + +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-3.10.0/introduction/features.md b/website/versioned_docs/version-3.10.0/introduction/features.md new file mode 100644 index 00000000..55caa812 --- /dev/null +++ b/website/versioned_docs/version-3.10.0/introduction/features.md @@ -0,0 +1,77 @@ +--- +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). + +LitmusChaos 3.0 brings a significant overhaul to its user experience, adopting a more streamlined UI for a simplified and user-friendly experience. It introduces Environments enabling users to efficiently organize their chaos infrastructures. The new Chaos Studio simplifies the process of fine-tuning chaos experiments, enhancing user capabilities. Additionally, it includes support for Resilience Probes for simplifying the management of Litmus probes. Finally, it extends compatibility to Mongo Replicas, which can be easily installed via Helm with Bitnami Mongo. + +## Advantages of Litmus 3.0 + +Here's a summary of the major highlights of LitmusChaos 3.0: +- **Redefined User Experience** + - Complete transformation of the user interface (UI) for a sleek and intuitive experience. + - Leveraging the Harness UIcore library to provide an even smoother user journey. + +- **Introduction to Environments** + - Empowers users to efficiently manage their Chaos Infrastructures. + - Helps categorize and compartmentalize chaos experiments for better organization and collaboration. + +- **Chaos Studio** + - Simplifies the adjustment of chaos parameters and configurations. + - Eliminates complex setup procedures, making chaos engineering more accessible to all users. + - Streamlines the process of fine-tuning chaos experiments. + +- **Resilience Probes** + - Resilience probes now support a plug-and-play architecture. + - Users can create probes once and utilize them repeatedly across various experiments. + - Comprehensive support for steady-state validation enhances system resilience. + - Helps users assess the robustness of their applications more effectively. + +- **MongoDB High Availability Support** + - Users can now install MongoDB Replicas via Helm using Bitnami Mongo. + - Seamless integration of chaos engineering into MongoDB infrastructure. + - Uncover weaknesses and improve the overall reliability of MongoDB setups. + +- **Terminology Changes** + - A refinement of terminology for improved clarity and consistency. + - **Chaos Agents/Delegates** are now referred to as **Chaos Infrastructures**. + - **Chaos Scenarios/Workflows** have been simplified to **Chaos Experiments**. + - **Chaos Experiments** are now called **Chaos Faults**. + +- **API Refactoring and Enhanced Code Architecture** + - Under-the-hood refactors and improvements in code architecture. + - Addition of backend unit tests to enhance code reliability. + - These technical enhancements make it easier for developers to contribute to the LitmusChaos ecosystem. + - Improved code quality and maintainability for the project. + +Litmus itself is composed of microservices. And we made sure that by adding the above features for 3.0, seamlessly integrates the additional microservices in conjunction with the existing one. Litmus 3.0 is completely backwards compatible. No features are deprecated. + +The migration path is about constructing new artifacts such as Chaos Experiments that include the current chaos experiments in use by the users. + +## Feature revision across Litmus 1.x, 2.x and 3.0 + +Litmus 3.0 culminates as well as enhances the features rolled-out through Litmus 1.x and 2.x. Below is a bird's eye view of all the enhancements made through the three major releases: + +| Litmus 1.x | Litmus 2.x | Litmus 3.0 | +| -------------------- | ------------------------------------- | -------------------------- | +| Experiments | Chaos Experiments | Revamped and simplified UX | +| Per user | Teams (Multi Tenant) | Environments | +| Per cluster | Per organisation (Cross Cloud) | Chaos Studio | +| Only Public ChaosHub | Public and Private ChaosHubs | Resilience probes | +| CLI only | CLI and GUI | Mongo DB Replicas | +| | GitOps | Refactored APIs | +| | Scalability | | +| | Integrated and Interleaved monitoring | | + +## Learn more +- [Install Litmus](../getting-started/installation.md) +- [Visualize Chaos Experiments](../concepts/visualize-experiment.md) +- Chaos Schedule +- [View the different User Guides](../user-guides/overview.md) diff --git a/website/versioned_docs/version-3.10.0/introduction/other-links.md b/website/versioned_docs/version-3.10.0/introduction/other-links.md new file mode 100644 index 00000000..060b5636 --- /dev/null +++ b/website/versioned_docs/version-3.10.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-3.10.0/introduction/usage.md b/website/versioned_docs/version-3.10.0/introduction/usage.md new file mode 100644 index 00000000..96117562 --- /dev/null +++ b/website/versioned_docs/version-3.10.0/introduction/usage.md @@ -0,0 +1,32 @@ +--- +id: usage +title: Uses of Litmus +sidebar_label: Uses of Litmus +--- + +--- + +Chaos experiments 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. + +Chaos Testing in DevOps Cycle + +## 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 + +Chaos Engineering is a culture-oriented practice. 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-3.10.0/introduction/what-is-litmus.md b/website/versioned_docs/version-3.10.0/introduction/what-is-litmus.md new file mode 100644 index 00000000..360a9241 --- /dev/null +++ b/website/versioned_docs/version-3.10.0/introduction/what-is-litmus.md @@ -0,0 +1,38 @@ +--- +id: what-is-litmus +title: What is Litmus? +sidebar_label: Litmus +--- + +--- + +Litmus Logo + +LitmusChaos is a Cloud-Native Chaos Engineering Framework with cross-cloud support. It is a CNCF Incubating 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 Kubernetes custom resources (CRs). + +## Importance of Resilience + +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-3.10.0/litmusctl/installation.md b/website/versioned_docs/version-3.10.0/litmusctl/installation.md new file mode 100644 index 00000000..583299d7 --- /dev/null +++ b/website/versioned_docs/version-3.10.0/litmusctl/installation.md @@ -0,0 +1,180 @@ +--- +id: installation +title: Litmusctl +sidebar_label: Installation +--- + +--- + +The LitmusChaos command-line tool, litmusctl, allows you to manage litmuschaos's infrastructure plane. You can use litmusctl to connect and disconnect chaos infrastructures, create chaos experiments, 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 infrastructures. 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 0.23.0 or latest: Click here + +## Installation + +To install the latest version of litmusctl follow the below steps: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Platforms1.9.01.8.01.7.01.6.01.5.01.4.01.3.01.2.0master(Unreleased)
    litmusctl-darwin-amd64 (MacOS)Click hereClick hereClick hereClick hereClick hereClick hereClick hereClick hereClick here
    litmusctl-linux-386Click hereClick hereClick hereClick hereClick hereClick hereClick hereClick hereClick here
    litmusctl-linux-amd64Click hereClick hereClick hereClick hereClick hereClick hereClick hereClick hereClick here
    litmusctl-linux-armClick hereClick hereClick hereClick hereClick hereClick hereClick hereClick hereClick here
    litmusctl-linux-arm64Click hereClick hereClick hereClick hereClick hereClick hereClick hereClick hereClick here
    litmusctl-windows-386Click hereClick hereClick hereClick hereClick hereClick hereClick hereClick hereClick here
    litmusctl-windows-amd64Click hereClick hereClick hereClick hereClick hereClick hereClick hereClick hereClick here
    litmusctl-windows-armClick hereClick hereClick hereClick hereClick hereClick hereClick hereClick hereClick here
    + +### 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-3.10.0/litmusctl/litmusctl-usage.md b/website/versioned_docs/version-3.10.0/litmusctl/litmusctl-usage.md new file mode 100644 index 00000000..251328f2 --- /dev/null +++ b/website/versioned_docs/version-3.10.0/litmusctl/litmusctl-usage.md @@ -0,0 +1,26 @@ +--- +id: litmusctl-usage +title: Litmusctl Usage +sidebar_label: Litmusctl Usage +--- + +--- + + + + + + + + + + + + + + + + + + +
    TopicUser Guides
    Connect Chaos InfrastructureClick Here
    Create Chaos ExperimentClick Here
    Additional CommandsClick Here
    diff --git a/website/versioned_docs/version-3.10.0/troubleshooting.md b/website/versioned_docs/version-3.10.0/troubleshooting.md new file mode 100644 index 00000000..c87a0530 --- /dev/null +++ b/website/versioned_docs/version-3.10.0/troubleshooting.md @@ -0,0 +1,114 @@ +--- +id: troubleshooting +title: Troubleshooting +sidebar_label: Troubleshooting +--- + +--- + +## Installation + +### Not able to connect to the LitmusChaos 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. + +### While uninstalling Chaoscenter using helm, some components like subscriber, exporter, event, chaos scenarios, etc are not removed. + +These are chaos infrastructure components, which are launched by the control plane server, so first disconnect the chaos infrastructure from the portal then uninstall the portal using helm. + +### Unable to Install Chaoscenter 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. + +## Chaos Infrastructure + +### 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 infrastructure, 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 infrastructure. + +## Chaos Experiment + +### 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 faults part of the tune chaos experiment page. + +### The probe only accepts values in `ns, us, ms, m, s, or h`. But Why do experiments fail with `must be of type integer`? + +In the logs of the Helper pod, you may face these error logs below. + +```shell +{"mainLogs":"W1003 08:59:55.273647 1 client_config.go:552] Neither --kubeconfig nor --master was specified. Using the inClusterConfig. This might not work.\n2023/10/03 08:59:55 Error Creating Resource : ChaosEngine.litmuschaos.io 'pod-network-loss-h6srhrls' is invalid: [spec.experiments[0].spec.probe[0].runProperties.interval: Invalid value: 'string': spec.experiments[0].spec.probe[0].runProperties.interval in body must be of type integer: 'string', spec.experiments[0].spec.probe[0].runProperties.probeTimeout: Invalid value: 'string': spec.experiments[0].spec.probe[0].runProperties.probeTimeout in body must be of type integer: 'string']\n"} +``` + +It's because your cluster using old CRD manifest files. So you need to delete all Litmus' CRDs and reinstall them. The definition for CRDs can be found in the Chaos Infrastructure YAML file or at this [link](https://github.com/litmuschaos/litmus/blob/master/mkdocs/docs//litmus-portal-crds-.yml). + +## Chaoshub + +### 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 faults 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 faults directory is copied, refresh the ChaosHub page in ChaosCenter. + +## Litmusctl + +### 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-3.10.0/user-guides/accept-invite.md b/website/versioned_docs/version-3.10.0/user-guides/accept-invite.md new file mode 100644 index 00000000..6f2991db --- /dev/null +++ b/website/versioned_docs/version-3.10.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 invitation project name, and decide whether to accept or decline the invitation on the settings page. + + + +Once accepted, you can switch to the project using the side nav as shown below: + + diff --git a/website/versioned_docs/version-3.10.0/user-guides/account-settings.md b/website/versioned_docs/version-3.10.0/user-guides/account-settings.md new file mode 100644 index 00000000..a7c1bbee --- /dev/null +++ b/website/versioned_docs/version-3.10.0/user-guides/account-settings.md @@ -0,0 +1,54 @@ +--- +id: account-settings +title: Account Settings +sidebar_label: Account Settings +--- + +--- + +Under the account settings, you can change your personal details such as the email, name, and password. + +> Note: The username can’t be changed as it is unique. + +To navigate to the accounts page, click on the user avatar on the bottom left of the nav-bar: + +
    +avatar nav +
    + +## Edit Personal Details + +Click the edit icon to open the edit modal: + +
    +edit icon +
    + +Enter your name and your email address in the following text fields and click on the `Confirm` button to save the new details. + +
    +edit information +
    + +## Change Password + +On the same page, you can change your password by clicking on the `Change Password` button. + +
    +edit information +
    + +To update your password enter your current password as well as the new password you wish to set and click **Confirm** + +
    +edit information +
    + +> Note: If you have forgotten your password, please contact your admin to reset your password + +On successful completion, you will be logged out and asked to re-login with you new password. + +## Learn more + +- [Create a new user](create-user.md) +- [View users and their details](view-user.md) diff --git a/website/versioned_docs/version-3.10.0/user-guides/air-gapped.md b/website/versioned_docs/version-3.10.0/user-guides/air-gapped.md new file mode 100644 index 00000000..b7ec55c6 --- /dev/null +++ b/website/versioned_docs/version-3.10.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-3.10.0/user-guides/analyze-workflow.md b/website/versioned_docs/version-3.10.0/user-guides/analyze-workflow.md new file mode 100644 index 00000000..d2b24d6a --- /dev/null +++ b/website/versioned_docs/version-3.10.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-3.10.0/user-guides/change-project-name.md b/website/versioned_docs/version-3.10.0/user-guides/change-project-name.md new file mode 100644 index 00000000..4e117af6 --- /dev/null +++ b/website/versioned_docs/version-3.10.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 `Account setting` + +Go to the `Overview` section of settings and scroll to the `Your Projects` section: + + + +### 2. Enter edit mode + +Click options icon to open the options menu and click on the edit option (demonstrated in this example as `admin-project`) 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 on the `Confirm` button. + + + +## 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-3.10.0/user-guides/chaos-infrastructure-installation.md b/website/versioned_docs/version-3.10.0/user-guides/chaos-infrastructure-installation.md new file mode 100644 index 00000000..f80768db --- /dev/null +++ b/website/versioned_docs/version-3.10.0/user-guides/chaos-infrastructure-installation.md @@ -0,0 +1,70 @@ +--- +id: chaos-infrastructure-installation +title: Chaos Infrastructure Installation +sidebar_label: Chaos Infrastructure Installation +--- + +--- + +## Prerequisites + +- Before connecting a Chaos Infrastructure to the [ChaosCenter](../getting-started/resources.md#chaoscenter), learn about what is a [Chaos Infrastructure](../getting-started/resources.md#chaosagents) in Litmus. +- Make sure [litmusctl](../litmusctl/installation.md) is installed. + +## Connecting Chaos Infrastructure + +- Learn to [connect Chaos Infrastructure with non interactive mode using litmuctl](../litmusctl/litmusctl-usage.md) + +## Resource Requiremenets for Chaos Infrastructure 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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    PodContainerCPU(Requested)Memory(Requested)
    chaos-operator-cechaos-operator-ce25m300M
    chaos-exporterchaos-exporter25m300M
    event-trackerlitmus-event-tracker25m300M
    subscribersubscriber25m300M
    workflow-controllerworkflow-controller25m300M
    + +## 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-3.10.0/user-guides/chaoscenter-advanced-installation.md b/website/versioned_docs/version-3.10.0/user-guides/chaoscenter-advanced-installation.md new file mode 100644 index 00000000..025e64be --- /dev/null +++ b/website/versioned_docs/version-3.10.0/user-guides/chaoscenter-advanced-installation.md @@ -0,0 +1,264 @@ +--- +id: chaoscenter-advanced-installation +title: ChaosCenter Advanced Installation +sidebar_label: Setup with HTTPS +--- + +--- + +## Prerequisites + +- 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://app.harness.io/auth/#/signin). 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: +
  • Helm3 chart
  • +
  • Kubectl yaml spec file
  • +
    + 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 Experiments 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 infrastructure. +

    + To get started with Harness Chaos Engineering SaaS, visit Harness Chaos Engineering SaaS and register for free. You can skip the below installation steps. +
    +
    + +:::note +With 3.9.0 release, Cluster scope installation is deprecated. Now Namespaced mode is the only supported and standard installation mode. +::: + +### 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`. + +- Litmus helm chart depends on `bitnami/mongodb` [helm chart](https://github.com/bitnami/charts/tree/main/bitnami/mongodb), which uses a mongodb image not supported on ARM. If you want to install Litmus on an ARM-based server, please replace the default one with your custom mongodb arm image as shown below. + + ```bash + helm install chaos litmuschaos/litmus --namespace=litmus \ + --set portal.frontend.service.type=NodePort \ + --set mongodb.image.registry= \ + --set mongodb.image.repository= \ + --set mongodb.image.tag= + ``` + +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** + +In this method the users need to install mongo first via helm and then apply the installation manifest. Follow the instructions [here](https://github.com/litmuschaos/litmus/tree/master/chaoscenter#installation-steps-for-litmus-300-beta9). + +### **Install mongo** + +```bash + helm repo add bitnami https://charts.bitnami.com/bitnami +``` + +Mongo Values + +```bash + auth: + enabled: true + rootPassword: "1234" + # -- existingSecret Existing secret with MongoDB(®) credentials (keys: `mongodb-passwords`, `mongodb-root-password`, `mongodb-metrics-password`, ` mongodb-replica-set-key`) + existingSecret: "" +architecture: replicaset +replicaCount: 3 +persistence: + enabled: true +volumePermissions: + enabled: true +metrics: + enabled: false + prometheusRule: + enabled: false + +# bitnami/mongodb is not yet supported on ARM. +# Using unofficial tools to build bitnami/mongodb (arm64 support) +# more info: https://github.com/ZCube/bitnami-compat +#image: +# registry: ghcr.io/zcube +# repository: bitnami-compat/mongodb +# tag: 6.0.5 +``` + +```bash +helm install my-release bitnami/mongodb --values mongo-values.yml -n --create-namespace +``` + +Litmus supports for HTTP and HTTPS mode of installation. + +### Advanced installation (HTTPS based and CORS rules apply) + +1. Generate TLS certificates: You can provide your own certificates or can generate using [this](https://github.com/litmuschaos/litmus/blob/master/chaoscenter/mtls-helper.sh) bash script. + +2. Create secret + + ```bash + kubectl create secret generic tls-secret --from-file=ca.crt=ca.crt --from-file=tls.crt=tls.crt --from-file=tls.key=tls.key -n + ``` + +3. Applying the manifest file will install all the required service account configuration and ChaosCenter in namespaced scope. + +```bash +kubectl apply -f https://raw.githubusercontent.com/litmuschaos/litmus/3.10.0/chaoscenter/manifests/litmus-installation.yaml -n +``` + +--- + +## **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 + litmusportal-frontend-55974fcf59-cxxrf 1/1 Running 0 58s + my-release-mongodb-0 1/1 Running 0 63s + my-release-mongodb-1 1/1 Running 0 63s + my-release-mongodb-2 1/1 Running 0 62s + my-release-mongodb-arbiter-0 1/1 Running 0 64s + + ``` + +- 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 + chaos-exporter ClusterIP 10.68.45.7 8080/TCP 23h + litmusportal-auth-server-service NodePort 10.68.34.91 9003:32368/TCP,3030:31051/TCP 23h + litmusportal-frontend-service NodePort 10.68.43.68 9091:30070/TCP 23h + litmusportal-server-service NodePort 10.68.33.242 9002:32455/TCP,8000:30722/TCP 23h + my-release-mongodb-arbiter-headless ClusterIP None 27017/TCP 23h + my-release-mongodb-headless ClusterIP None 27017/TCP 23h + workflow-controller-metrics ClusterIP 10.68.33.65 9090/TCP 23h + ``` + +--- + +## **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 `31846`. 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 +https://172.17.0.3:31846/ +``` + +> Where `172.17.0.3` is my NodeIP and `31846` 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) + +**NOTE:** With advanced installation CORS rules are applied, once manifest is applied frontend loadbalancer IP needs to be added in the `ALLOWED_ORIGINS` environment in both auth and graphql server deployment. + +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 + +- [Install ChaosCenter with HTTP](../getting-started/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-3.10.0/user-guides/chaoscenter-oauth-dex-installation.md b/website/versioned_docs/version-3.10.0/user-guides/chaoscenter-oauth-dex-installation.md new file mode 100644 index 00000000..88b8aea0 --- /dev/null +++ b/website/versioned_docs/version-3.10.0/user-guides/chaoscenter-oauth-dex-installation.md @@ -0,0 +1,168 @@ +--- +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/callback' #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 + +![litmus-oauth-image](https://user-images.githubusercontent.com/31009634/135559389-c8cdf53c-76cf-4f9d-acaa-99014540f9cf.png) + +## Resources + +- [Dex OIDC Provider configurations](https://dexidp.io/docs/) + +## Learn more + +- [Install ChaosCenter with HTTP](../getting-started/installation.md)) +- [Install ChaosCenter with HTTPS](chaoscenter-advanced-installation.md)) +- [Connect External Chaos Delegates to ChaosCenter](../user-guides/chaos-infrastructure-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-3.10.0/user-guides/comparative-analysis.md b/website/versioned_docs/version-3.10.0/user-guides/comparative-analysis.md new file mode 100644 index 00000000..79c383dd --- /dev/null +++ b/website/versioned_docs/version-3.10.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-3.10.0/user-guides/configure-datasource.md b/website/versioned_docs/version-3.10.0/user-guides/configure-datasource.md new file mode 100644 index 00000000..68539caa --- /dev/null +++ b/website/versioned_docs/version-3.10.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-3.10.0/user-guides/construct-experiment.md b/website/versioned_docs/version-3.10.0/user-guides/construct-experiment.md new file mode 100644 index 00000000..e6a14802 --- /dev/null +++ b/website/versioned_docs/version-3.10.0/user-guides/construct-experiment.md @@ -0,0 +1,274 @@ +--- +id: construct-experiment +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](../glossary.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: 3.0.0 + 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:3.0.0 + 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: 3.0.0 + 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) diff --git a/website/versioned_docs/version-3.10.0/user-guides/create-environment.md b/website/versioned_docs/version-3.10.0/user-guides/create-environment.md new file mode 100644 index 00000000..681efcf0 --- /dev/null +++ b/website/versioned_docs/version-3.10.0/user-guides/create-environment.md @@ -0,0 +1,25 @@ +--- +id: create-environment +title: Create an Environment +sidebar_label: Create an Environment +--- + +## Before you begin + +You can learn about the concept of chaos environments [here](../concepts/infrastructure.md). + +## 1. Go to the Environments section + +Navigate to the `/environments` page (Environments on the left nav), and click on the `New Environment` button + + + +## 2. Add Environment details + +Add the details of the environment to be created such as name, description, tags, as well as the type of environment, i.e. `Pre-Production` and `Production`, these are meant to help further categorize the environments you are working with. + + + +The new environment will appear in the list as shown: + + diff --git a/website/versioned_docs/version-3.10.0/user-guides/create-infrastructure.md b/website/versioned_docs/version-3.10.0/user-guides/create-infrastructure.md new file mode 100644 index 00000000..077348c2 --- /dev/null +++ b/website/versioned_docs/version-3.10.0/user-guides/create-infrastructure.md @@ -0,0 +1,70 @@ +--- +id: create-infrastructure +title: Create an Infrastructure +sidebar_label: Create an Infrastructure +--- + +## Before you begin + +- You can learn about the concept of chaos infrastructures & chaos environments [here](../concepts/infrastructure.md). + +- You will need to create an environment for your chaos infrastructure to reside within. Environments are an abstraction layer over infrastructures, and a detailed guide on the environment creation process can be found [here](./create-environment.md) + +## 1. Go to the Infrastructure section + +Navigate to the `/environments` page (Environments on the left nav), and click on the environment you wish to install the chaos infrastructure in: + + + +## 2. Enable Chaos + +Click on the `Enable Chaos` button: + + + +## 3. Add details of the Infrastructure + +Add the details of the infrastructure such as the name, description and tags, then click on the `Next` button: + + + +## 4. Tune the cluster level specifications + +Choose one of the following modes: + +- **Cluster Wide:** This mode of infrastructure installation allows targeting resources across the entire cluster, in all the namespaces, as part of an experiment. +- **Namespace Mode:** This mode of infrastructure installation allows targeting resources only in the namespace where the chaos infrastructure is deployed. + +By default the installation will take place in the `litmus` namespace and uses `litmus` service account, which can be configured under the K8s cluster details. + +Optionally, you can also specify the node selectors and Kubernetes tolerations for chaos infrastructure deployment in the advanced section + + + +## 5. Deploy your Chaos Infrastructure + +- For cluster-wide access: + +
      +
    1. Select Download, and then copy and run the kubectl command shown on your screen to install the chaos infrastructure.
    2. +
    + + + +- For namespace access: + +
      +
    1. Run the first kubectl command to create the target namespace.
    2. +
    3. Run the second kubectl command to apply the chaos CRDs.
    4. +
    5. Select Download, and then copy and run the third command to install the chaos infrastructure.
    6. +
    + + + +Click `Done` + +**NOTE:** For HTTPS mode of installation of Chaoscenter, you will need to set `SKIP_SSL_VERIFY` as `true` in the infrastructure deployment yaml. + +The newly created infrastructure will appear in the list of infrastructures: + + diff --git a/website/versioned_docs/version-3.10.0/user-guides/create-resilience-probe.md b/website/versioned_docs/version-3.10.0/user-guides/create-resilience-probe.md new file mode 100644 index 00000000..650e7007 --- /dev/null +++ b/website/versioned_docs/version-3.10.0/user-guides/create-resilience-probe.md @@ -0,0 +1,43 @@ +--- +id: create-resilience-probe +title: Create a Resilience Probe +sidebar_label: Create a Resilience Probe +--- + +## Before you begin + +You can learn about the concept of resilience probes [here](../concepts/probes.md) and chaos experiments [here](../concepts/chaos-workflow.md). For this user guide, we will use a HTTP probe. + +## 1. Go to the Resilience Probes section + +Navigate to the `/probes` page (Resilience Probes on the left nav), and click on the `New Probe` button + + + +## 2. Select the type of probe + +Select and click on the type of probe you would like to create, you can read about the available probe types [here](../concepts/probes.md) + + + +## 3. Enter the details of the probe to create + +Enter the details of the probe such as name, description (optional), tags (optional) + + + +## 4. Configure the probe properties + +Configure the properties for the probe you are creating, such as, Timeout, Interval, Retry, etc. + + + +## 5. Configure the probe details + +Configure the details for the probe you are creating, once completed, click the `Setup Probe` button + + + +The new probe will appear in the list as shown: + + diff --git a/website/versioned_docs/version-3.10.0/user-guides/create-user.md b/website/versioned_docs/version-3.10.0/user-guides/create-user.md new file mode 100644 index 00000000..3f8aa73d --- /dev/null +++ b/website/versioned_docs/version-3.10.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. Navigate to User Management + +Go to the `User Management` tab of the account settings page: + + + +## 2. Create a new user + +Click on the `New User` button to bring up the `Create New User` modal and enter the details of the new user to be created. + + + +## 3. Confirmation of creation + +After you have added the details of the new user to be created, click the `Confirm` button to create the new user. + + + +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-3.10.0/user-guides/deactivate-user.md b/website/versioned_docs/version-3.10.0/user-guides/deactivate-user.md new file mode 100644 index 00000000..ecec52b9 --- /dev/null +++ b/website/versioned_docs/version-3.10.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 deactivation + +On clicking on the `Disable User` option, a confirmation prompt will pop up, click on the `Confirm` button in order to disable the user. + + + +## 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-3.10.0/user-guides/delete-environment.md b/website/versioned_docs/version-3.10.0/user-guides/delete-environment.md new file mode 100644 index 00000000..0c4c92f2 --- /dev/null +++ b/website/versioned_docs/version-3.10.0/user-guides/delete-environment.md @@ -0,0 +1,21 @@ +--- +id: delete-environment +title: Delete an Environment +sidebar_label: Delete an Environment +--- + +## 1. Go to the Environments section + +Navigate to the `/environments` page (Environments on the left nav), click on the `options` icon to open the options menu and select `Delete` option: + + + +## 2. Confirm Environment deletion + +After opening the options menu and clicking on the `Delete` option, you'll see a prompt in order to confirm your action. Please ensure that you want to delete the selected environment and click the `Confirm` button: + + + +The deleted environment details will disappear from the list as shown: + + diff --git a/website/versioned_docs/version-3.10.0/user-guides/delete-experiment.md b/website/versioned_docs/version-3.10.0/user-guides/delete-experiment.md new file mode 100644 index 00000000..fce711f2 --- /dev/null +++ b/website/versioned_docs/version-3.10.0/user-guides/delete-experiment.md @@ -0,0 +1,41 @@ +--- +id: delete-experiment +title: Delete a Chaos experiment +sidebar_label: Delete Chaos experiment +--- + +--- + +If required, it is possible to delete a chaos experiment schedule that you no longer wish to run against your application. + +:::note +This also means that all the runs corresponding to that chaos experiment will also be deleted. +::: + +## Before you begin + +You can learn about the concept of chaos experiments [here](../concepts/chaos-workflow.md) and how to schedule your first chaos experiment [here](schedule-experiment.md). + +## 1. Go to the chaos experiments sections + +In the `Chaos experiment` page, go to the specific experiment you wish to delete: + + + +## 2. Click on the `Delete experiment` option + +After opening the options menu and clicking on the `Delete experiment` option, you'll see a prompt in order to confirm your action. Please ensure that you want to delete the selected chaos experiment and click the `Confirm` button: + + + +## 3. The Chaos experiment has been deleted + +You will observe that the chaos experiment no longer appears in the list of schedules and has been removed. + + + +As stated above, the runs have been removed as well. + +## Learn more + +- [schedule a chaos experiment](schedule-experiment.md) diff --git a/website/versioned_docs/version-3.10.0/user-guides/delete-infrastructure.md b/website/versioned_docs/version-3.10.0/user-guides/delete-infrastructure.md new file mode 100644 index 00000000..60075843 --- /dev/null +++ b/website/versioned_docs/version-3.10.0/user-guides/delete-infrastructure.md @@ -0,0 +1,25 @@ +--- +id: delete-infrastructure +title: Delete an Infrastructure +sidebar_label: Delete an Infrastructure +--- + +## 1. Go to the Infrastructure section + +Navigate to the infrastructure you want to delete, and click on the `options` icon to open the options menu and select `Disable` option: + + + +## 2. Confirm Infrastructure deletion + +After opening the options menu and clicking on the `Disable` option, you'll see a prompt in order to confirm your action. Please ensure that you want to delete the selected infrastructure and click the `Confirm` button: + +:::note +The disabling of the infrastructure from the UI will clean-up the subscriber pod from the cluster, but the remaining resources are left to the user to clean up, please follow the steps and the commands provided in the deletion confirmation modal to do so. +::: + + + +The deleted infrastructure will disappear from the list as shown: + + diff --git a/website/versioned_docs/version-3.10.0/user-guides/delete-resilience-probe.md b/website/versioned_docs/version-3.10.0/user-guides/delete-resilience-probe.md new file mode 100644 index 00000000..75bb90f9 --- /dev/null +++ b/website/versioned_docs/version-3.10.0/user-guides/delete-resilience-probe.md @@ -0,0 +1,27 @@ +--- +id: delete-resilience-probe +title: Delete a Resilience Probe +sidebar_label: Delete a Resilience Probe +--- + +:::note +Deleting a probe will delete all the associations with experiment runs from the chaos control plane. This will also misplace any analytics that had incurred for the previous runs for said probe. +::: + +## 1. Go to the probes sections + +In the `Resilience Probes` page, go to the specific probe you wish to delete: + + + +## 2. Click on the `Delete Probe` option + +After opening the options menu and clicking on the `Delete Probe` option, you'll see a prompt in order to confirm your action. Please ensure that you want to delete the selected resilience probe and click the `Confirm` button: + + + +## 3. The Resilience probe has been deleted + +You will observe that the resilience probe no longer appears in the list of probes and has been removed. + + diff --git a/website/versioned_docs/version-3.10.0/user-guides/download-experiment-manifest.md b/website/versioned_docs/version-3.10.0/user-guides/download-experiment-manifest.md new file mode 100644 index 00000000..a2229dd0 --- /dev/null +++ b/website/versioned_docs/version-3.10.0/user-guides/download-experiment-manifest.md @@ -0,0 +1,31 @@ +--- +id: download-experiment-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-experiment.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-experiment.md) +- [Re-run a chaos scenario](re-run-experiment.md) +- [Delete a chaos scenario](delete-experiment.md) diff --git a/website/versioned_docs/version-3.10.0/user-guides/edit-environment.md b/website/versioned_docs/version-3.10.0/user-guides/edit-environment.md new file mode 100644 index 00000000..4656dd31 --- /dev/null +++ b/website/versioned_docs/version-3.10.0/user-guides/edit-environment.md @@ -0,0 +1,21 @@ +--- +id: edit-environment +title: Edit an Environment +sidebar_label: Edit an Environment +--- + +## 1. Go to the Environments section + +Navigate to the `/environments` page (Environments on the left nav), click on the `options` icon to open the options menu and select `Edit Environment` option: + + + +## 2. Update Environment details + +Update the details of the environment as required and click the `Save` button. + + + +The updated environment details will appear in the list as shown: + + diff --git a/website/versioned_docs/version-3.10.0/user-guides/edit-invite.md b/website/versioned_docs/version-3.10.0/user-guides/edit-invite.md new file mode 100644 index 00000000..3328bbcb --- /dev/null +++ b/website/versioned_docs/version-3.10.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 `Remove` button. + + + +## Learn more + +- [Accept an invitation](accept-invite.md) diff --git a/website/versioned_docs/version-3.10.0/user-guides/edit-resilience-probe.md b/website/versioned_docs/version-3.10.0/user-guides/edit-resilience-probe.md new file mode 100644 index 00000000..4c8c96cb --- /dev/null +++ b/website/versioned_docs/version-3.10.0/user-guides/edit-resilience-probe.md @@ -0,0 +1,23 @@ +--- +id: edit-resilience-probe +title: Edit a Resilience Probe +sidebar_label: Edit a Resilience Probe +--- + +## 1. Go to the probes sections + +In the `Resilience Probes` page, go to the specific probe you wish to edit: + + + +## 2. Click on the `Edit Probe` option + +After opening the options menu and clicking on the `Edit Probe` option, you'll see a modal pop-up where you will be able to go through all the steps of probe setup and edit the details on each step (Note: name is unique and cannot be edited): + + + +## 3. The Resilience probe has been edited + +Once you've updated all the details of the probe, click on the `Setup Probe` button to commit the updated details of the probe. + + diff --git a/website/versioned_docs/version-3.10.0/user-guides/edit-schedule.md b/website/versioned_docs/version-3.10.0/user-guides/edit-schedule.md new file mode 100644 index 00000000..d30b8a32 --- /dev/null +++ b/website/versioned_docs/version-3.10.0/user-guides/edit-schedule.md @@ -0,0 +1,52 @@ +--- +id: edit-schedule +title: Edit Chaos Experiment Schedule +sidebar_label: Edit Chaos Experiment Schedule +--- + +--- + +## Before you begin + +You must schedule a chaos experiment. To know more about scheduling chaos experiments click [here](schedule-experiment.md) + +--- + +After you have scheduled a chaos experiment, you might have a need of changing the schedule of a recurring chaos experiment. To edit the schedule follow these steps: + +## 1. Select edit schedule from the menu + +In the `Chaos experiments` page you can click on the triple dots of the experiment to access more options for it. From the menu select the `Edit Experiment` option. + +
    +Selecting Edit Schedule from the Menu +Selecting Edit Schedule from the Menu +
    + +## 2. Click on edit button + +Now you'll be seeing the pipeline diagram of your chaos experiment and you can click on the `Schedule` tab to change the schedule. + +
    +Summary of the Chaos experiment with Edit button +Summary of the Chaos experiment with Edit button +
    + +## 3. Change the schedule + +Here you can change the schedule to the required interval and click on the `Set schedule` button. + +
    +Editing the Schedule +Editing the Schedule +
    + +## 4. Save the changes + +Click the `Save` button to save the changes to the experiment chaos experiment. + +## Learn more + +- [Observe Chaos Experiment](observe-experiment.md) +- [Save Chaos Experiments as a Template](save-as-template.md) +- [Re-run a Chaos Experiment](re-run-experiment.md) diff --git a/website/versioned_docs/version-3.10.0/user-guides/editing-queries-app-dashboard.md b/website/versioned_docs/version-3.10.0/user-guides/editing-queries-app-dashboard.md new file mode 100644 index 00000000..45cd1fa0 --- /dev/null +++ b/website/versioned_docs/version-3.10.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-3.10.0/user-guides/event-triggered-chaos.md b/website/versioned_docs/version-3.10.0/user-guides/event-triggered-chaos.md new file mode 100644 index 00000000..19be6710 --- /dev/null +++ b/website/versioned_docs/version-3.10.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-3.10.0/user-guides/gitops-configuration.md b/website/versioned_docs/version-3.10.0/user-guides/gitops-configuration.md new file mode 100644 index 00000000..911ba0ea --- /dev/null +++ b/website/versioned_docs/version-3.10.0/user-guides/gitops-configuration.md @@ -0,0 +1,109 @@ +--- +id: gitops-configuration +title: Configuring GitOps +sidebar_label: Configuring GitOps +--- + +:::note +With the latest release of LitmusChaos 3.0.0: +
  • The term Chaos Experiment has been changed to Chaos Fault.
  • +
  • The term Chaos Scenario/Workflow has been changed to Chaos Experiment.
  • +::: + + +## Introduction + +GitOps enables you to configure a single source of truth for your chaos experiment and faults, 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 Infrastructure](../concepts/infrastructure.md) +- [Chaos Experiment](../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 experiments 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` (Project Setup > GitOps on the left nav). +

    + +

    +- Select the `Git Repository` radio button. +- Copy the git URL of your git repository and paste it in the `Repository URL` text box. +- Enter the branch where you want to sync your chaos experiments. +

    + +

    +- You can allow access of your repository either through an access token or through an SSH key. +- In the case of the SSH key, click the button `Generate New SSH Key` and 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 `Save` button. A snackbar 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 experiment, 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 experiments that are created and pushed to the git repository directly, after configuring GitOps. In this case, if the chaos experiment is a single run chaos experiment, then it starts executing as soon as it is pushed to the repository. Alternatively, if the chaos experiment is a scheduled chaos experiment, then it executes as per the defined schedule. On the other hand, updating an existing chaos experiment present in the git repository will not execute the chaos experiment but only sync the chaos experiment resource definition with the ChaosCenter, if applicable. +::: + +## Steps to configure Event-Triggered Chaos Injection + +- Once the chaos experiment is pushed to your repository, you’ll notice every chaos experiment has a `experiment_id`. You can get this from the chaos experiment 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 experiment using this experiment_id and run it on your target application. You can use the following command: + +``` +kubectl annotate deploy/target-application litmuschaos.io/experimentId=${experiment_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 experiment 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 experiment 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 + +## Learn More + +- [Schedule a chaos experiment](../user-guides/schedule-experiment.md) +- [Observe a Chaos experiment](../user-guides/observe-experiment.md) diff --git a/website/versioned_docs/version-3.10.0/user-guides/image-registry.md b/website/versioned_docs/version-3.10.0/user-guides/image-registry.md new file mode 100644 index 00000000..32bdaaa7 --- /dev/null +++ b/website/versioned_docs/version-3.10.0/user-guides/image-registry.md @@ -0,0 +1,63 @@ +--- +id: image-registry +title: Using different Image Registries in a Chaos Experiments +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 experiments. Few images that are used in the Litmus chaos experiments are `litmuschaos:k8s`, `litmuschaos:litmus-checker` etc. +With ChaosCenter, you get the privilege to use your own/custom image registries for Chaos experiments. + +## Before you begin + +To understand the concept of Image Registry, make sure you are aware of [Chaos experiment](../concepts/chaos-workflow.md) and the different image registries that are used in it. + +## Steps to Update Chaos experiment Image Registry + +To updated the Chaos experiment Image Registry, you can go to Image Registry in ChaosCenter (Project Setup > Image Registry on the left nav). 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. Custom Image Registry (Registry Server) +2. Custom Repo (Registry Name) +3. Registry Type `Public/Private` + + +

    + +If the Registry Type is `Private`, make sure to provide the secret. + +Once the details are provided, click on the `Save` button and you can see the updated Image Registry changes. + + + +

    + +Now while scheduling a chaos experiment, the image registry changes will be visible. Here's the code snippet from a Chaos experiment 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 experiment](../concepts/chaos-workflow.md) +- [What is ChaosCenter](../getting-started/resources.md#chaoscenter) diff --git a/website/versioned_docs/version-3.10.0/user-guides/invite-team-member.md b/website/versioned_docs/version-3.10.0/user-guides/invite-team-member.md new file mode 100644 index 00000000..1afe8527 --- /dev/null +++ b/website/versioned_docs/version-3.10.0/user-guides/invite-team-member.md @@ -0,0 +1,30 @@ +--- +id: invite-team-member +title: Invite a Team Member +sidebar_label: Invite Team Member +--- + +--- + +> In the `/setup` route (Project Setup > Members on the sidebar) the `Active/Pending members` tabs 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 `Pending members` tab. + +## 1. Find the user you want to invite + +In the team tab, click the `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/Executor) and hit the same button. + + + +On successful acceptance of the invitation you will be able to collaborate over your project! + +## Learn more + +- [Edit an invitation](edit-invite.md) +- [Accept invite](accept-invite.md) diff --git a/website/versioned_docs/version-3.10.0/user-guides/leave-project.md b/website/versioned_docs/version-3.10.0/user-guides/leave-project.md new file mode 100644 index 00000000..293417fb --- /dev/null +++ b/website/versioned_docs/version-3.10.0/user-guides/leave-project.md @@ -0,0 +1,26 @@ +--- +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 `Projects Joined` section. 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 + +A confirmation dialog will pop up, click on the `Confirm` button to leave the project + + + +## 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-3.10.0/user-guides/manage-app-dashboard.md b/website/versioned_docs/version-3.10.0/user-guides/manage-app-dashboard.md new file mode 100644 index 00000000..4fae3ccb --- /dev/null +++ b/website/versioned_docs/version-3.10.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-3.10.0/user-guides/observability-set-up.md b/website/versioned_docs/version-3.10.0/user-guides/observability-set-up.md new file mode 100644 index 00000000..2c288152 --- /dev/null +++ b/website/versioned_docs/version-3.10.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-3.10.0/user-guides/observe-experiment.md b/website/versioned_docs/version-3.10.0/user-guides/observe-experiment.md new file mode 100644 index 00000000..9de1408e --- /dev/null +++ b/website/versioned_docs/version-3.10.0/user-guides/observe-experiment.md @@ -0,0 +1,42 @@ +--- +id: observe-experiment +title: Observe Chaos experiment +sidebar_label: Observe Chaos experiment +--- + +--- + +Visualization is an important aspect while doing chaos engineering. It allows the user to discover and inspect different changes that occur during a Chaos Experiment execution.
    +With ChaosCenter, the real-time data and status of the chaos experiments can be observed. Valuable information like pod logs, chaos experiment status, and chaos results can also be viewed. + +## Prerequisites + +The following should be required before creating a Chaos Experiment: + +- ChaosCenter +- [Chaos Experiments](../concepts/chaos-workflow.md) + +## Litmus Chaos Experiment + +If the user chooses to 'Save' and 'Run' the experiment, they will be redirected directly to the experiment execution page where the experiment can be visualised else they will be taken Chaos Experiment Page. + +## Observe a Litmus Chaos Experiment + +To observe a chaos experiment, user needs to select the highlighted experiment run box from the heatmap, it will redirect to experiment run execution page.
    + + +In the chaos experiment, a realtime graph of the chaos experiment is displayed. This graph contains valuable information regarding the status of individual steps of the chaos experiment.

    +

    +To view the details of each step, the user can click on the individual nodes and the right side pane will display the node details, results(once the execution is complete), and the logs related to it. +

    + + + +## Summary + +After scheduling a chaos experiment, a user can view the details of the running chaos experiment from the ChaosCenter. ChaosCenter provides a real-time graph that is used to visualize the chaos experiment and get the details of individual steps of the chaos experiment. Important details like the logs and target applications can be viewed from ChaosCenter. Once the chaos experiment execution is completed, the resiliency score is calculated and the ChaosResult for the ChaosEngine pods is available. + +## Learn More + +- [Explore Probes](../concepts/probes.md) +- [What is a Chaos Experiment](../concepts/chaos-workflow.md) diff --git a/website/versioned_docs/version-3.10.0/user-guides/overview.md b/website/versioned_docs/version-3.10.0/user-guides/overview.md new file mode 100644 index 00000000..7c253a23 --- /dev/null +++ b/website/versioned_docs/version-3.10.0/user-guides/overview.md @@ -0,0 +1,45 @@ +--- +id: overview +title: Overview +sidebar_label: Overview +--- + +--- + +The User Guides section details Processes, User-flows and How-tos detailing all sorts of experiments in various environments. Technical details and inner workings of the various components are explained in the [Concepts](../concepts/overview.md) section. + +### [Advanced Installation](chaoscenter-advanced-installation.md) + +Install ChaosCenter and Chaos Infrastructure in various environment configurations. + +### [Injecting Fault](schedule-experiment.md) + +Constructing, Scheduling, Editing and Observing chaos experiments. + +### [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 experiment 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 Experiment](image-registry.md) + +Using different Image Registries like Docker, Red Hat Quay, Google Container Registry in a Chaos Experiment. + +### [Uninstalling Litmus](uninstall-litmus.md) + +Disconnecting Chaos Infrastructure and uninstalling ChaosCenter. diff --git a/website/versioned_docs/version-3.10.0/user-guides/re-run-experiment.md b/website/versioned_docs/version-3.10.0/user-guides/re-run-experiment.md new file mode 100644 index 00000000..93caf784 --- /dev/null +++ b/website/versioned_docs/version-3.10.0/user-guides/re-run-experiment.md @@ -0,0 +1,30 @@ +--- +id: re-run-experiment +title: Re-run a chaos experiment +sidebar_label: Re-run chaos experiment +--- + +--- + +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 experiment [here](schedule-experiment.md). + +## 1. Go to the chaos experiments sections + +In the `Chaos experiment` page, and click on the play icon for the specific schedule you wish to re-run: + + + +## 2. Click on the `Run Experiment` option + +Having re-run a particular experiment, you will redirected to the chaos studio for the particular execution and see that it has started to run as per the experiment configurations: + + + +## Learn more + +- [Schedule a chaos experiment](schedule-experiment.md) +- [Delete a chaos experiment](delete-experiment.md) diff --git a/website/versioned_docs/version-3.10.0/user-guides/remove-team-member.md b/website/versioned_docs/version-3.10.0/user-guides/remove-team-member.md new file mode 100644 index 00000000..5fa2af38 --- /dev/null +++ b/website/versioned_docs/version-3.10.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 `Active members` tab in the Members page, 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 `Options` icon as shown and select the `Remove Member` option. + + + +### 2. Confirmation for removal + +On hitting the `Remove Member` option, you will be prompted to confirm the removal of the member, hit `Confirm` to confirm and remove the member from your project. + + diff --git a/website/versioned_docs/version-3.10.0/user-guides/reset-password.md b/website/versioned_docs/version-3.10.0/user-guides/reset-password.md new file mode 100644 index 00000000..45781ebb --- /dev/null +++ b/website/versioned_docs/version-3.10.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 `Reset Password` option + + + +## 2. Change the password + +In the `Reset Password` modal type in the new password in the `New Password` & `Re-enter new password` fields. Once done hit the `Confirm` button to update the password. + + + +## Learn more + +- [View users](view-user.md) diff --git a/website/versioned_docs/version-3.10.0/user-guides/save-as-template.md b/website/versioned_docs/version-3.10.0/user-guides/save-as-template.md new file mode 100644 index 00000000..4d0237ea --- /dev/null +++ b/website/versioned_docs/version-3.10.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-experiment.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-experiment.md) +- [Re-run a chaos scenario](re-run-experiment.md) +- [Delete a chaos scenario](delete-experiment.md) diff --git a/website/versioned_docs/version-3.10.0/user-guides/schedule-experiment.md b/website/versioned_docs/version-3.10.0/user-guides/schedule-experiment.md new file mode 100644 index 00000000..dd3444b2 --- /dev/null +++ b/website/versioned_docs/version-3.10.0/user-guides/schedule-experiment.md @@ -0,0 +1,160 @@ +--- +id: schedule-experiment +title: Schedule a Chaos Experiment +sidebar_label: Schedule Chaos Experiment +--- + +--- + +## Before you begin + +You must connect an Chaos Infrastructure before scheduling a chaos experiment. You can [connect an external Chaos Infrastructure](../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 **Chaos Studio** page where you can choose or design your own chaos scenario by doing the following steps: + +## 1. Provide the identifiers for the experiment to be created + +In the Experiment Overview, enter the experiment Name and optional Description and Tags. + +
    +Add Identifiers +
    + +## 2. Choose target chaos infrastructure + +In **Select a Chaos Infrastructure**, select the infrastructure where the target resources reside, and then click **Apply**. + +
    +Selecting an Chaos Infrastructure +
    + +After Selecting the chaos Infrastructure , you can continue by clicking on **Next** button. This takes you to the Experiment Builder tab, where you can choose how to start building your experiment. + +## 3. Choose you want to build your chaos experiment + +
    +Choosing a method +
    + +Select how you want to build the experiment. The options, explained later, are: + +- Blank Canvas - Lets you build the experiment from scratch, adding the specific faults you want. + +- Templates from Chaos Hubs - Lets you preview and select and experiment from pre-curated experiment templates available in Chaos Hubs. + +- Upload YAML - Lets you upload an experiment manifest YAML file. + +These options are explained below. + +**If you select Blank Canvas:** + +The Experiment Builder tab is displayed. + +
    +Add to blank canvas +
    + +a. Select **Add**, then select each fault you want to add to the experiment individually. + +
    +litmus-chaos-hub +
    + +For each fault you select, you'll tune the fault's properties next. + +
    +tune-fault +
    + +b. To tune each fault: + +- **Specify the target application (only for pod-level Kubernetes faults):** This lets the application's corresponding pods be targeted. + +- **Tune fault parameters:** Every fault has a set of common parameters, such as the chaos duration, ramp time, etc., and a set of unique parameters that may be customised as needed. + +- **Add chaos probes:** On the Probes tab, you can add chaos probes to automate the chaos hypothesis checks for a fault during the experiment execution. Probes are declarative checks that aid in the validation of certain criteria that are deemed necessary to declare an experiment as passed. + +- **Tune fault weightage:** Set the weight for the fault, which sets the importance of the fault relative to the other faults in the experiments. This is used to calculate the resilience score of the experiment. + +c. To add a fault that runs in parallel to another fault, point your mouse below an existing fault, and then select Add. + +
    +add-parallel-faults +
    + +In Experiment Builder, faults that are stacked vertically run in parallel, and faults or groups of parallel faults run in sequence from left to right. + +**If you select Templates from Chaos Hubs:** + +a. Select an experiment template from a chaos hub. + +Select Experiment Type to see available chaos hubs to select templates from. +Select a template to see a preview of the faults included. + +
    +select-template-from-chaos-hub +
    + +You can edit the template to add more faults or update the existing faults. + +**If you select Upload YAML:** + +a. Upload an experiment manifest YAML file to create the experiment. + +You can edit the experiment to update the existing faults or add more of them. + +## 4. Save the experiment. + +
    +chaos-experiment-save +
    + +Now, you can choose to either run the experiment right away by selecting the Run button on the top, or create a recurring schedule to run the experiment by selecting the Schedule tab. + +## Advanced experiment setup options + +You can select Advanced Options on the Experiment Builder tab to configure the advanced options (described below) while creating an experiment for a Kubernetes chaos infrastructure: + +
    +advanced-options-experiment-creation +
    + +## General options + +### Node Selector + +Specifies the node on which the experiment pods will be scheduled. Provide the node label as a key-value pair. + +- Can be used with node-level faults to avoid the scheduling of the experiment pod on the target node(s). + +- Can be used to limit the scheduling of the experiment pods on nodes that have an unsupported OS. + +
    +node-selectors +
    + +### Toleration + +Specifies the tolerations that must be satisfied by a tainted node to be able to schedule the experiment pods. For more information on taints and tolerations, go to the [Kubernetes documentation](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/). + +- Can be used with node-level faults to avoid the scheduling of the experiment pod on the target node(s). + +- Can be used to limit the scheduling of the experiment pods on nodes that have an unsupported OS. + +
    +tolerations +
    + +## Learn more + +- [Observe Chaos Scenario ](observe-experiment.md) +- [Edit Schedule](edit-schedule.md) +- [Save Chaos Scenarios as a Template](save-as-template.md) diff --git a/website/versioned_docs/version-3.10.0/user-guides/setup-datasource.md b/website/versioned_docs/version-3.10.0/user-guides/setup-datasource.md new file mode 100644 index 00000000..b40bc148 --- /dev/null +++ b/website/versioned_docs/version-3.10.0/user-guides/setup-datasource.md @@ -0,0 +1,467 @@ +--- +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. + +### 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-3.10.0/user-guides/setup-with-ingress.md b/website/versioned_docs/version-3.10.0/user-guides/setup-with-ingress.md new file mode 100644 index 00000000..29df17c0 --- /dev/null +++ b/website/versioned_docs/version-3.10.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 + +- [Install ChaosCenter with HTTP](../getting-started/installation.md)) +- [Install ChaosCenter with HTTPS](chaoscenter-advanced-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 with HTTP](../getting-started/installation.md)) +- [Install ChaosCenter with HTTPS](chaoscenter-advanced-installation.md) diff --git a/website/versioned_docs/version-3.10.0/user-guides/setup-without-ingress.md b/website/versioned_docs/version-3.10.0/user-guides/setup-without-ingress.md new file mode 100644 index 00000000..97f47338 --- /dev/null +++ b/website/versioned_docs/version-3.10.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 + +- [Install ChaosCenter with HTTP](../getting-started/installation.md)) +- [Install ChaosCenter with HTTPS](chaoscenter-advanced-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 with HTTP](../getting-started/installation.md)) +- [Install ChaosCenter with HTTPS](chaoscenter-advanced-installation.md) diff --git a/website/versioned_docs/version-3.10.0/user-guides/share-app-dashboard.md b/website/versioned_docs/version-3.10.0/user-guides/share-app-dashboard.md new file mode 100644 index 00000000..93bf92c6 --- /dev/null +++ b/website/versioned_docs/version-3.10.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. 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-3.10.0/user-guides/uninstall-litmus.md b/website/versioned_docs/version-3.10.0/user-guides/uninstall-litmus.md new file mode 100644 index 00000000..207ce2d3 --- /dev/null +++ b/website/versioned_docs/version-3.10.0/user-guides/uninstall-litmus.md @@ -0,0 +1,95 @@ +--- +id: uninstall-litmus +title: Uninstalling Litmus +sidebar_label: Uninstall Litmus +--- + +--- + +## Chaos Infrastructure + +To disconnect the [Chaos Infrastructure](../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 Infrastructure + + ```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 Infrastructures Page. +3. Click on the three dot menu and select `Disable` of the respective Chaos Infrastructure you want to disconnect. +4. On the Modal that appears, confirm your selection by clicking `Yes` and the selected Chaos Infrastructure would be disconnected from the ChaosCenter. + :::note + The above disconnect would remove the subscriber component from Chaos Infrastructure and thus removing the connectivity between the Chaos Infrastructure and the ChaosCenter. + + If the Chaos Infrastructure 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 Infrastructures 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 + +```bash +kubectl delete sa rolebindings role --all -n +``` + +--- + +## Remove the Litmus CRDs + +To remove all the CRDs Litmus uses, use the following command: + +```bash +kubectl delete -f https://raw.githubusercontent.com/litmuschaos/litmus/3.10.0/chaoscenter/manifests/litmus-portal-crds.yml +``` + +--- + +## ChaosCenter + +> To remove the Chaos Infrastructure Resources you need to follow the above Chaos Infrastructure Uninstall process + +To uninstall the ChaosCenter from the system, follow these steps - + +### Using Kubectl + +```bash +kubectl delete -f ${LITMUS_PORTAL_NAMESPACE}-ns-scoped-litmus-portal-manifest.yml -n ${LITMUS_PORTAL_NAMESPACE} +``` + +### Using Helm + +```bash +helm uninstall litmuschaos --namespace +kubectl delete ns +``` diff --git a/website/versioned_docs/version-3.10.0/user-guides/upgrade.md b/website/versioned_docs/version-3.10.0/user-guides/upgrade.md new file mode 100644 index 00000000..1dcf3597 --- /dev/null +++ b/website/versioned_docs/version-3.10.0/user-guides/upgrade.md @@ -0,0 +1,36 @@ +--- +id: upgrade +title: Upgrade Litmus ChaosCenter to Latest Version +sidebar_label: Upgrade +--- + +--- + +## Upgrade ChaosCenter + +To upgrade Litmus ChaosCenter from 3.9.0 to 3.10.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/3.10.0/litmus-getting-started.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-3.10.0/user-guides/view-chaos-impact.md b/website/versioned_docs/version-3.10.0/user-guides/view-chaos-impact.md new file mode 100644 index 00000000..425cb3b3 --- /dev/null +++ b/website/versioned_docs/version-3.10.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-3.10.0/user-guides/view-probe-details.md b/website/versioned_docs/version-3.10.0/user-guides/view-probe-details.md new file mode 100644 index 00000000..e47b3258 --- /dev/null +++ b/website/versioned_docs/version-3.10.0/user-guides/view-probe-details.md @@ -0,0 +1,24 @@ +--- +id: view-resilience-probe +title: View Resilience Probe Details +sidebar_label: View Resilience Probe Details +--- + + +## 1. Go to the probes sections + +In the `Resilience Probes` page, go to the specific probe you wish to view the details of: + + + +## 2. View Execution history + +Click on the specific probe you would like to see the details of, this will redirect you to the `Execution History` tab: + + + +## 3. View Probe configurations + +On the same page you can click on the `Probe Configuration` tab to see the configuration of the said probe: + + diff --git a/website/versioned_docs/version-3.10.0/user-guides/view-user.md b/website/versioned_docs/version-3.10.0/user-guides/view-user.md new file mode 100644 index 00000000..49d25e3d --- /dev/null +++ b/website/versioned_docs/version-3.10.0/user-guides/view-user.md @@ -0,0 +1,21 @@ +--- +id: view-user +title: View all users +sidebar_label: View users +--- + +--- + +> In the `settings` page 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_docs/version-3.9.2/architecture/architecture-summary.md b/website/versioned_docs/version-3.9.2/architecture/architecture-summary.md new file mode 100644 index 00000000..76db8e86 --- /dev/null +++ b/website/versioned_docs/version-3.9.2/architecture/architecture-summary.md @@ -0,0 +1,28 @@ +--- +id: architecture-summary +title: Architecture summary +sidebar_label: Architecture summary +--- + +--- + +Architecture Overview + +The Litmus architecture can be segregated into two parts: + +1. **Control plane:** Contains the components required for the functioning of ChaosCenter, the website-based portal for Litmus. + +2. **Execution plane:** Contains the components required for the injection of chaos in the target resources. + +- Control plane can be used for creating and scheduling chaos experiments, which is a set of chaos faults defined in a definitive sequence to achieve desired chaos impact on the target resources upon execution. Users can log in to the ChaosCenter using the web UI or the APIs to define a chaos experiment and assess the resilience of target workloads. + +- Once the user creates a chaos experiment using the ChaosCenter, it is passed on to the execution plane. The Execution plane can be present either in the same cluster as the ChaosCenter if the self chaos infrastructure is being used, or in a remote cluster if an external chaos infrastructure is being used. The Execution plane interprets the chaos experiment as a list of actions that will inject chaos into the target workloads. It ensures efficient orchestration of chaos in various cloud-native environments using Kubernetes custom resources. + +- Once the chaos experiment is executed, Execution plane sends the chaos result to the control plane for their post-processing using either the built-in monitoring dashboard of Litmus or using external observability tools such as Prometheus DB and Grafana dashboard. Litmus also achieves automated chaos experiment runs to execute chaos as part of the CI/CD pipeline based on a set of defined conditions using GitOps. + +:::note +With the latest release of LitmusChaos 3.0.0: +- The term **Chaos Delegate/Agent** has been changed to **Chaos Infrastructure**. +- The term **Chaos Experiment** has been changed to **Chaos Fault**. +- The term **Chaos Scenario/Workflow** has been changed to **Chaos Experiment**. +::: diff --git a/website/versioned_docs/version-3.9.2/architecture/chaos-control-plane.md b/website/versioned_docs/version-3.9.2/architecture/chaos-control-plane.md new file mode 100644 index 00000000..0b61bde8 --- /dev/null +++ b/website/versioned_docs/version-3.9.2/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 + +Chaos control plane consists of micro-services responsible for the functioning of the ChaosCenter, the website-based portal that can be used for interacting with Litmus, apart from the CLI. Chaos Plane facilitates the creation and scheduling of chaos experiments, system observability during the event of chaos, and post-processing and analysis of fault results. + +## Chaos control plane components + +- **Authentication Server:** A Golang micro-service that is responsible for authorizing, authenticating the requests received from ChaosCenter and managing users along with their projects. It primarily serves the cause of user creation, user login, resetting the password, updating user information, creating project, managing project related operations. + +- **Backend Server:** A GraphQL based Golang micro-service that serves the requests received from ChaosCenter, 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 experiments, saved chaos experiment templates, user projects, ChaosHubs, and GitOps details, among the other information. + +- **ChaosCenter:** Refers to the interfaces used by Litmus for creation and scheduling of chaos experiments, 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 experiments using role-based user accounts. + + - **Litmusctl:** A command-line tool that allows management of Litmus Chaos Infrastructure components. It can be used to create chaos infrastructures, 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 experiments. 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 experiment, the user needs to have an Owner role assigned in the project. +2. The user uploads a Chaos Experiment 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 Infrastructure. +4. Chaos Infrastructure uses the Chaos Experiment manifest to inject chaos into the target resources. The steps of the Chaos Experiment execution can be visualized using the ChaosCenter. +5. Chaos Infrastructure returns the results of the chaos faults that were a part of the chaos experiment back to the Backend Server, along with the fault logs. +6. Backend Server then sends the chaos fault results and logs to the ChaosCenter. It also stores the results into the Database for generating post-chaos experiment statistics and information. diff --git a/website/versioned_docs/version-3.9.2/architecture/chaos-execution-plane.md b/website/versioned_docs/version-3.9.2/architecture/chaos-execution-plane.md new file mode 100644 index 00000000..217a2975 --- /dev/null +++ b/website/versioned_docs/version-3.9.2/architecture/chaos-execution-plane.md @@ -0,0 +1,71 @@ +--- +id: chaos-execution-plane +title: Chaos execution plane +sidebar_label: Chaos execution plane +--- + +--- + +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 infrastructure is being used or in the host cluster containing the control plane if a self chaos infrastructure is being used. It can be further segregated into Litmus Chaos Infrastructure components and Litmus Backend Execution Infrastructure components. + +## Litmus Execution Plane Components + +Litmus Chaos 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 Experiments using the Chaos Experiment 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 Experiment CR from a Chaos Experiment template, watching for Chaos Experiment events during its execution, and sending the chaos experiment result to the Control Plane. + +3. **Event Tracker:** An optional component that is capable of triggering automated chaos experiment 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 experiment 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 Experiment in target resources. These components include: + +1. **Chaos Experiment CR:** Refers to the Argo Workflow CR which describes the steps that are executed as a part of the chaos experiment. 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 fault as well as to store the various fault tunables. + +3. **ChaosEngine CR:** Used to hold information about how the chaos faults are executed. It connects an application instance with one or more chaos faults 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 +
    + +5. **ChaosResult CR:** Holds the results of a chaos fault, such as ChaosEngine reference, Fault State, Verdict of the fault (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 Faults. It is a lifecycle manager for the chaos faults that creates Fault Jobs for the execution of fault business logic and monitors the fault pods (jobs) until completion. + +
    + Chaos Runner +
    + +7. **Fault Jobs:** Refers to the pods that execute the fault logic. One fault pod is created per chaos fault in the chaos experiment. + +## Standard Chaos Execution Plane Flow + +1. Subscriber receives the Chaos Experiment manifest from the Control Plane and applies the manifest to create a Chaos Experiment CR. +2. Chaos Experiment CRs are tracked by the Argo Workflow Controller. When the Workflow Controller finds a new Chaos Experiment CR, it creates the ChaosExperiment(Chaos Fault) CRs and the ChaosEngine CRs for the chaos faults that are a part of the chaos experiment. +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(Chaos fault) CR and overrides them with values from the ChaosEngine CR. It then constructs the Fault Jobs and monitors them until their completion. +6. Fault Jobs execute the fault business logic and undertake chaos injection on target resources. Once done, the ChaosResult is updated with the fault 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 Experiment is executed. + +:::note +With the latest release of LitmusChaos 3.0.0: +- The term **Chaos Delegate/Agent** has been changed to **Chaos Infrastructure**. +- The term **Chaos Experiment** has been changed to **Chaos Fault**. +- The term **Chaos Scenario/Workflow** has been changed to **Chaos Experiment**. +::: diff --git a/website/versioned_docs/version-3.9.2/architecture/chaos-experiment-flow.md b/website/versioned_docs/version-3.9.2/architecture/chaos-experiment-flow.md new file mode 100644 index 00000000..62437069 --- /dev/null +++ b/website/versioned_docs/version-3.9.2/architecture/chaos-experiment-flow.md @@ -0,0 +1,37 @@ +--- +id: chaos-fault-flow +title: Chaos fault flow +sidebar_label: Chaos fault flow +--- + +--- + +Chaos Fault Flow + +The fault 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 Fault Jobs that execute the fault business logic. Typically, these ChaosEngines are embedded within the 'steps' of a Litmus Chaos Experiment. However, one may also create and apply the Chaos Engines manually, and then the chaos-operator reconciles this resource and triggers the fault execution. Chaos faults are classified as: + +- Kubernetes Faults + - Pod-Level Chaos + - Node-Level Chaos +- Application Chaos +- Cloud Infrastructure + +## Chaos Fault Flow Steps + +1. Chaos fault execution gets triggered by the Fault Job. +2. Fault tunables and low-level execution details are fetched. +3. ChaosResult gets initialized and its verdict is updated as "Awaited" to indicate that the fault is currently running. +4. Steady-state condition for the respective fault is validated. If the condition is found to be invalid, the fault execution is stopped and the ChaosResult is updated as "Fail". +5. Once the steady-state condition is validated, fault 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. Fault execution ends. + +:::note +With the latest release of LitmusChaos 3.0.0: +- The term **Chaos Delegate/Agent** has been changed to **Chaos Infrastructure**. +- The term **Chaos Experiment** has been changed to **Chaos Fault**. +- The term **Chaos Scenario/Workflow** has been changed to **Chaos Experiment**. +::: diff --git a/website/versioned_docs/version-3.9.2/architecture/overview.md b/website/versioned_docs/version-3.9.2/architecture/overview.md new file mode 100644 index 00000000..71d9a6cf --- /dev/null +++ b/website/versioned_docs/version-3.9.2/architecture/overview.md @@ -0,0 +1,25 @@ +--- +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 Fault 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. diff --git a/website/versioned_docs/version-3.9.2/assets/architecture-summary.png b/website/versioned_docs/version-3.9.2/assets/architecture-summary.png new file mode 100644 index 00000000..50934882 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/architecture-summary.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/architecture.png b/website/versioned_docs/version-3.9.2/assets/architecture.png new file mode 100644 index 00000000..736a2b0f Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/architecture.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/argo-chaos-workflow.png b/website/versioned_docs/version-3.9.2/assets/argo-chaos-workflow.png new file mode 100644 index 00000000..cdb412b2 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/argo-chaos-workflow.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/argo-graph.png b/website/versioned_docs/version-3.9.2/assets/argo-graph.png new file mode 100644 index 00000000..58bb2991 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/argo-graph.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/arrow.png b/website/versioned_docs/version-3.9.2/assets/arrow.png new file mode 100644 index 00000000..89f1b061 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/arrow.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/chaos-center-analytics.pdf b/website/versioned_docs/version-3.9.2/assets/chaos-center-analytics.pdf new file mode 100644 index 00000000..999b477c Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/chaos-center-analytics.pdf differ diff --git a/website/versioned_docs/version-3.9.2/assets/chaos-control-plane.png b/website/versioned_docs/version-3.9.2/assets/chaos-control-plane.png new file mode 100644 index 00000000..7b6c2dc2 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/chaos-control-plane.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/chaos-execution-plane-chaos-operator.png b/website/versioned_docs/version-3.9.2/assets/chaos-execution-plane-chaos-operator.png new file mode 100644 index 00000000..ae39b735 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/chaos-execution-plane-chaos-operator.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/chaos-execution-plane-chaos-runner.png b/website/versioned_docs/version-3.9.2/assets/chaos-execution-plane-chaos-runner.png new file mode 100644 index 00000000..a628c8cf Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/chaos-execution-plane-chaos-runner.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/chaos-execution-plane.png b/website/versioned_docs/version-3.9.2/assets/chaos-execution-plane.png new file mode 100644 index 00000000..422f7587 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/chaos-execution-plane.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/chaos-hub.png b/website/versioned_docs/version-3.9.2/assets/chaos-hub.png new file mode 100644 index 00000000..d945f3d3 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/chaos-hub.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/chaos-observability-flow-analytics.png b/website/versioned_docs/version-3.9.2/assets/chaos-observability-flow-analytics.png new file mode 100644 index 00000000..cef7e61e Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/chaos-observability-flow-analytics.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/chaos-observability-flow-events.png b/website/versioned_docs/version-3.9.2/assets/chaos-observability-flow-events.png new file mode 100644 index 00000000..379a2f4f Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/chaos-observability-flow-events.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/chaos-observability-flow-logging.png b/website/versioned_docs/version-3.9.2/assets/chaos-observability-flow-logging.png new file mode 100644 index 00000000..cc89f30a Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/chaos-observability-flow-logging.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/chaos-observability-flow-metrics.png b/website/versioned_docs/version-3.9.2/assets/chaos-observability-flow-metrics.png new file mode 100644 index 00000000..ff0a685d Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/chaos-observability-flow-metrics.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/chaos-observability-flow-summarisation.png b/website/versioned_docs/version-3.9.2/assets/chaos-observability-flow-summarisation.png new file mode 100644 index 00000000..6098b954 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/chaos-observability-flow-summarisation.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/concepts/authentication/architecture.png b/website/versioned_docs/version-3.9.2/assets/concepts/authentication/architecture.png new file mode 100644 index 00000000..9a7ed95f Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/concepts/authentication/architecture.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/concepts/chaoshub/chaoshub-add-private.png b/website/versioned_docs/version-3.9.2/assets/concepts/chaoshub/chaoshub-add-private.png new file mode 100644 index 00000000..7032fc29 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/concepts/chaoshub/chaoshub-add-private.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/concepts/chaoshub/chaoshub-add-public.png b/website/versioned_docs/version-3.9.2/assets/concepts/chaoshub/chaoshub-add-public.png new file mode 100644 index 00000000..92dbd089 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/concepts/chaoshub/chaoshub-add-public.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/concepts/chaoshub/chaoshub-after-add.png b/website/versioned_docs/version-3.9.2/assets/concepts/chaoshub/chaoshub-after-add.png new file mode 100644 index 00000000..7df0b8d4 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/concepts/chaoshub/chaoshub-after-add.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/concepts/chaoshub/chaoshub-chaos-charts.png b/website/versioned_docs/version-3.9.2/assets/concepts/chaoshub/chaoshub-chaos-charts.png new file mode 100644 index 00000000..4a2cc116 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/concepts/chaoshub/chaoshub-chaos-charts.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/concepts/chaoshub/chaoshub-default.png b/website/versioned_docs/version-3.9.2/assets/concepts/chaoshub/chaoshub-default.png new file mode 100644 index 00000000..9ed1fbaa Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/concepts/chaoshub/chaoshub-default.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/concepts/chaoshub/chaoshub-exp-details.png b/website/versioned_docs/version-3.9.2/assets/concepts/chaoshub/chaoshub-exp-details.png new file mode 100644 index 00000000..74b42fd6 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/concepts/chaoshub/chaoshub-exp-details.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/concepts/chaoshub/chaoshub-predefined-experiments.png b/website/versioned_docs/version-3.9.2/assets/concepts/chaoshub/chaoshub-predefined-experiments.png new file mode 100644 index 00000000..ba0ebd2f Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/concepts/chaoshub/chaoshub-predefined-experiments.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/concepts/gitops/architecture.png b/website/versioned_docs/version-3.9.2/assets/concepts/gitops/architecture.png new file mode 100644 index 00000000..69ed4b3e Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/concepts/gitops/architecture.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/concepts/gitops/litmus-components.png b/website/versioned_docs/version-3.9.2/assets/concepts/gitops/litmus-components.png new file mode 100644 index 00000000..780d52f7 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/concepts/gitops/litmus-components.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/concepts/observability/app-infra-monitoring/app-infra-monitoring-dataflow.png b/website/versioned_docs/version-3.9.2/assets/concepts/observability/app-infra-monitoring/app-infra-monitoring-dataflow.png new file mode 100644 index 00000000..6a489177 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/concepts/observability/app-infra-monitoring/app-infra-monitoring-dataflow.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/concepts/observability/app-infra-monitoring/dashboard-schema.png b/website/versioned_docs/version-3.9.2/assets/concepts/observability/app-infra-monitoring/dashboard-schema.png new file mode 100644 index 00000000..147c216a Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/concepts/observability/app-infra-monitoring/dashboard-schema.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/concepts/observability/data-source/data-source.png b/website/versioned_docs/version-3.9.2/assets/concepts/observability/data-source/data-source.png new file mode 100644 index 00000000..51b5b5a5 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/concepts/observability/data-source/data-source.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/concepts/observability/workflow-statistics/workflow-statistics-dataflow.png b/website/versioned_docs/version-3.9.2/assets/concepts/observability/workflow-statistics/workflow-statistics-dataflow.png new file mode 100644 index 00000000..d0b70ccd Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/concepts/observability/workflow-statistics/workflow-statistics-dataflow.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/concepts/projects/flow-chart.png b/website/versioned_docs/version-3.9.2/assets/concepts/projects/flow-chart.png new file mode 100644 index 00000000..f7ce35d4 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/concepts/projects/flow-chart.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/disconnect-image.png b/website/versioned_docs/version-3.9.2/assets/disconnect-image.png new file mode 100644 index 00000000..b4286ba5 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/disconnect-image.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/experiment-flow.png b/website/versioned_docs/version-3.9.2/assets/experiment-flow.png new file mode 100644 index 00000000..6e79ad7f Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/experiment-flow.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/favicon.ico b/website/versioned_docs/version-3.9.2/assets/favicon.ico new file mode 100644 index 00000000..42db2693 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/favicon.ico differ diff --git a/website/versioned_docs/version-3.9.2/assets/getstarted.svg b/website/versioned_docs/version-3.9.2/assets/getstarted.svg new file mode 100644 index 00000000..cefa5547 --- /dev/null +++ b/website/versioned_docs/version-3.9.2/assets/getstarted.svg @@ -0,0 +1,429 @@ + + + + + + + + + + + + + + +chaos:~$#BuildandapplyChaosEngineCRtounleashChaosEvery1.0s:kubectlgetpoFriOct419:32:352019 + + +chaos:~$ + + +chaos:~$vichaosengine.yamlNAMEREADYSTATUSRESTARTSAGE + + +chaos:~$hello-deploy-dd59b8956-hxcjv1/1Running019m + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +HelloWorldisonlineHTTP/2200OK + + +HelloWorldisonlineHTTP/2200OK + + +HelloWorldisonlineHTTP/2200OK + + +HelloWorldisonlineHTTP/2200OK + + +HelloWorldisonlineHTTP/2200OK + + +HelloWorldisonlineHTTP/2200OK + + +HelloWorldisonlineHTTP/2200OK + + +HelloWorldisonlineHTTP/2200OK + + +HelloWorldisonlineHTTP/2200OK + + +HelloWorldisonlineHTTP/2200OK + + +HelloWorldisonlineHTTP/2200OK + + +HelloWorldisonlineHTTP/2200OK + + +HelloWorldisonlineHTTP/2200OK + + +HelloWorldisonlineHTTP/2200OK + + +HelloWorldisonlineHTTP/2200OK + + +HelloWorldisonlineHTTP/2200OK + + +HelloWorldisonlineHTTP/2200OK + + +HelloWorldisonlineHTTP/2200OK + + +HelloWorldisonlineHTTP/2200OK + + + + + +[demo]0:ssh*"rahul-ThinkPad-E490"01:0205-Oct-19 + + + + + + + + + + + + + + + + + + + diff --git a/website/versioned_docs/version-3.9.2/assets/getting-started/run-your-first-workflow/adjust-weights-for-podtato-head.png b/website/versioned_docs/version-3.9.2/assets/getting-started/run-your-first-workflow/adjust-weights-for-podtato-head.png new file mode 100644 index 00000000..88b1c0c1 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/getting-started/run-your-first-workflow/adjust-weights-for-podtato-head.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/getting-started/run-your-first-workflow/chaos-result-of-podtato-head.png b/website/versioned_docs/version-3.9.2/assets/getting-started/run-your-first-workflow/chaos-result-of-podtato-head.png new file mode 100644 index 00000000..b804f511 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/getting-started/run-your-first-workflow/chaos-result-of-podtato-head.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/getting-started/run-your-first-workflow/choose-schedule.png b/website/versioned_docs/version-3.9.2/assets/getting-started/run-your-first-workflow/choose-schedule.png new file mode 100644 index 00000000..f2991039 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/getting-started/run-your-first-workflow/choose-schedule.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/getting-started/run-your-first-workflow/podtato-head-tune-workflow.png b/website/versioned_docs/version-3.9.2/assets/getting-started/run-your-first-workflow/podtato-head-tune-workflow.png new file mode 100644 index 00000000..c1a5fc8d Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/getting-started/run-your-first-workflow/podtato-head-tune-workflow.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/getting-started/run-your-first-workflow/podtato-head-workflow-in-action.png b/website/versioned_docs/version-3.9.2/assets/getting-started/run-your-first-workflow/podtato-head-workflow-in-action.png new file mode 100644 index 00000000..a5a6ef5b Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/getting-started/run-your-first-workflow/podtato-head-workflow-in-action.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/getting-started/run-your-first-workflow/podtato-head-workflow-running.png b/website/versioned_docs/version-3.9.2/assets/getting-started/run-your-first-workflow/podtato-head-workflow-running.png new file mode 100644 index 00000000..a8e24150 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/getting-started/run-your-first-workflow/podtato-head-workflow-running.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/getting-started/run-your-first-workflow/schedule-workflow-from-homepage.png b/website/versioned_docs/version-3.9.2/assets/getting-started/run-your-first-workflow/schedule-workflow-from-homepage.png new file mode 100644 index 00000000..89742980 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/getting-started/run-your-first-workflow/schedule-workflow-from-homepage.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/getting-started/run-your-first-workflow/schedule-workflow-from-litmus-workflows.png b/website/versioned_docs/version-3.9.2/assets/getting-started/run-your-first-workflow/schedule-workflow-from-litmus-workflows.png new file mode 100644 index 00000000..c6a6df21 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/getting-started/run-your-first-workflow/schedule-workflow-from-litmus-workflows.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/getting-started/run-your-first-workflow/scheduled-successfully.png b/website/versioned_docs/version-3.9.2/assets/getting-started/run-your-first-workflow/scheduled-successfully.png new file mode 100644 index 00000000..e8d08123 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/getting-started/run-your-first-workflow/scheduled-successfully.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/getting-started/run-your-first-workflow/select-podtato-head.png b/website/versioned_docs/version-3.9.2/assets/getting-started/run-your-first-workflow/select-podtato-head.png new file mode 100644 index 00000000..497af12d Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/getting-started/run-your-first-workflow/select-podtato-head.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/getting-started/run-your-first-workflow/selecting-self-agent.png b/website/versioned_docs/version-3.9.2/assets/getting-started/run-your-first-workflow/selecting-self-agent.png new file mode 100644 index 00000000..cbda36fc Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/getting-started/run-your-first-workflow/selecting-self-agent.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/getting-started/run-your-first-workflow/verify-and-commit-podtato-head.png b/website/versioned_docs/version-3.9.2/assets/getting-started/run-your-first-workflow/verify-and-commit-podtato-head.png new file mode 100644 index 00000000..6deb7cc9 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/getting-started/run-your-first-workflow/verify-and-commit-podtato-head.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/getting-started/run-your-first-workflow/workflow-settings-podtato-head.png b/website/versioned_docs/version-3.9.2/assets/getting-started/run-your-first-workflow/workflow-settings-podtato-head.png new file mode 100644 index 00000000..91470da6 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/getting-started/run-your-first-workflow/workflow-settings-podtato-head.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/integrations/grafana/annotation-events.png b/website/versioned_docs/version-3.9.2/assets/integrations/grafana/annotation-events.png new file mode 100644 index 00000000..3be4fac9 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/integrations/grafana/annotation-events.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/integrations/grafana/annotation-metrics.png b/website/versioned_docs/version-3.9.2/assets/integrations/grafana/annotation-metrics.png new file mode 100644 index 00000000..958ba3be Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/integrations/grafana/annotation-metrics.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/integrations/grafana/experiment-verdict-failure-alert-config.png b/website/versioned_docs/version-3.9.2/assets/integrations/grafana/experiment-verdict-failure-alert-config.png new file mode 100644 index 00000000..b7baad05 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/integrations/grafana/experiment-verdict-failure-alert-config.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/integrations/grafana/experiment-verdict-failure-alert-query.png b/website/versioned_docs/version-3.9.2/assets/integrations/grafana/experiment-verdict-failure-alert-query.png new file mode 100644 index 00000000..a66239ac Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/integrations/grafana/experiment-verdict-failure-alert-query.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/integrations/grafana/gauges.png b/website/versioned_docs/version-3.9.2/assets/integrations/grafana/gauges.png new file mode 100644 index 00000000..c825d233 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/integrations/grafana/gauges.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/integrations/grafana/probe-failure-alert-config.png b/website/versioned_docs/version-3.9.2/assets/integrations/grafana/probe-failure-alert-config.png new file mode 100644 index 00000000..2304a2f1 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/integrations/grafana/probe-failure-alert-config.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/integrations/grafana/probe-failure-alert-query.png b/website/versioned_docs/version-3.9.2/assets/integrations/grafana/probe-failure-alert-query.png new file mode 100644 index 00000000..e9724469 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/integrations/grafana/probe-failure-alert-query.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/integrations/grafana/variable-engine-context.png b/website/versioned_docs/version-3.9.2/assets/integrations/grafana/variable-engine-context.png new file mode 100644 index 00000000..bf228c23 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/integrations/grafana/variable-engine-context.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/integrations/grafana/variable-result-name.png b/website/versioned_docs/version-3.9.2/assets/integrations/grafana/variable-result-name.png new file mode 100644 index 00000000..24d0f3d4 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/integrations/grafana/variable-result-name.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/introduction/community/CNCF.webp b/website/versioned_docs/version-3.9.2/assets/introduction/community/CNCF.webp new file mode 100644 index 00000000..2d5f0cd1 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/introduction/community/CNCF.webp differ diff --git a/website/versioned_docs/version-3.9.2/assets/introduction/community/CommunitySyncUp.webp b/website/versioned_docs/version-3.9.2/assets/introduction/community/CommunitySyncUp.webp new file mode 100644 index 00000000..0560582e Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/introduction/community/CommunitySyncUp.webp differ diff --git a/website/versioned_docs/version-3.9.2/assets/introduction/core-principles/litmus-principles.png b/website/versioned_docs/version-3.9.2/assets/introduction/core-principles/litmus-principles.png new file mode 100644 index 00000000..8ed58e85 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/introduction/core-principles/litmus-principles.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/introduction/litmus/importance-of-resilience.png b/website/versioned_docs/version-3.9.2/assets/introduction/litmus/importance-of-resilience.png new file mode 100644 index 00000000..140b0b2f Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/introduction/litmus/importance-of-resilience.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/introduction/uses-of-litmus/chaos-test-devops.png b/website/versioned_docs/version-3.9.2/assets/introduction/uses-of-litmus/chaos-test-devops.png new file mode 100644 index 00000000..a129c82f Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/introduction/uses-of-litmus/chaos-test-devops.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/introduction/uses-of-litmus/overall-resilience.png b/website/versioned_docs/version-3.9.2/assets/introduction/uses-of-litmus/overall-resilience.png new file mode 100644 index 00000000..eb7de22f Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/introduction/uses-of-litmus/overall-resilience.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/join-community.png b/website/versioned_docs/version-3.9.2/assets/join-community.png new file mode 100644 index 00000000..d3720865 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/join-community.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/landing-page.png b/website/versioned_docs/version-3.9.2/assets/landing-page.png new file mode 100644 index 00000000..277a1730 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/landing-page.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/litmus-logo.png b/website/versioned_docs/version-3.9.2/assets/litmus-logo.png new file mode 100644 index 00000000..432ead63 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/litmus-logo.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/litmus-overview.png b/website/versioned_docs/version-3.9.2/assets/litmus-overview.png new file mode 100644 index 00000000..88e9f05f Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/litmus-overview.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/litmus-schematic.png b/website/versioned_docs/version-3.9.2/assets/litmus-schematic.png new file mode 100644 index 00000000..42c3e9a7 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/litmus-schematic.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/login.png b/website/versioned_docs/version-3.9.2/assets/login.png new file mode 100644 index 00000000..b105e7d6 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/login.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/node-details.png b/website/versioned_docs/version-3.9.2/assets/node-details.png new file mode 100644 index 00000000..9010fcfb Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/node-details.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/portal-arch.jpg b/website/versioned_docs/version-3.9.2/assets/portal-arch.jpg new file mode 100644 index 00000000..96014444 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/portal-arch.jpg differ diff --git a/website/versioned_docs/version-3.9.2/assets/red-blue-cluster.png b/website/versioned_docs/version-3.9.2/assets/red-blue-cluster.png new file mode 100644 index 00000000..df49e9fa Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/red-blue-cluster.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/tutorials.png b/website/versioned_docs/version-3.9.2/assets/tutorials.png new file mode 100644 index 00000000..bceb2dcf Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/tutorials.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/environment/create-environment/step-1.png b/website/versioned_docs/version-3.9.2/assets/user-guides/environment/create-environment/step-1.png new file mode 100644 index 00000000..7034c807 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/environment/create-environment/step-1.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/environment/create-environment/step-2.png b/website/versioned_docs/version-3.9.2/assets/user-guides/environment/create-environment/step-2.png new file mode 100644 index 00000000..d82ba9dc Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/environment/create-environment/step-2.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/environment/create-environment/step-3.png b/website/versioned_docs/version-3.9.2/assets/user-guides/environment/create-environment/step-3.png new file mode 100644 index 00000000..d5541a8b Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/environment/create-environment/step-3.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/environment/delete-environment/step-1.png b/website/versioned_docs/version-3.9.2/assets/user-guides/environment/delete-environment/step-1.png new file mode 100644 index 00000000..b60588d9 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/environment/delete-environment/step-1.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/environment/delete-environment/step-2.png b/website/versioned_docs/version-3.9.2/assets/user-guides/environment/delete-environment/step-2.png new file mode 100644 index 00000000..78805a11 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/environment/delete-environment/step-2.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/environment/delete-environment/step-3.png b/website/versioned_docs/version-3.9.2/assets/user-guides/environment/delete-environment/step-3.png new file mode 100644 index 00000000..c9f96118 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/environment/delete-environment/step-3.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/environment/edit-environment/step-1.png b/website/versioned_docs/version-3.9.2/assets/user-guides/environment/edit-environment/step-1.png new file mode 100644 index 00000000..ccffc89c Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/environment/edit-environment/step-1.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/environment/edit-environment/step-2.png b/website/versioned_docs/version-3.9.2/assets/user-guides/environment/edit-environment/step-2.png new file mode 100644 index 00000000..51c8ddeb Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/environment/edit-environment/step-2.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/environment/edit-environment/step-3.png b/website/versioned_docs/version-3.9.2/assets/user-guides/environment/edit-environment/step-3.png new file mode 100644 index 00000000..c7754323 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/environment/edit-environment/step-3.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/gitops/gitops-config.png b/website/versioned_docs/version-3.9.2/assets/user-guides/gitops/gitops-config.png new file mode 100644 index 00000000..b270e7a4 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/gitops/gitops-config.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/gitops/gitops.png b/website/versioned_docs/version-3.9.2/assets/user-guides/gitops/gitops.png new file mode 100644 index 00000000..a70b076c Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/gitops/gitops.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/image-registry/img-registry-changes.png b/website/versioned_docs/version-3.9.2/assets/user-guides/image-registry/img-registry-changes.png new file mode 100644 index 00000000..fb8c8db9 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/image-registry/img-registry-changes.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/image-registry/img-registry-tab.png b/website/versioned_docs/version-3.9.2/assets/user-guides/image-registry/img-registry-tab.png new file mode 100644 index 00000000..b5ecc8c6 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/image-registry/img-registry-tab.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/image-registry/img-registry-update.png b/website/versioned_docs/version-3.9.2/assets/user-guides/image-registry/img-registry-update.png new file mode 100644 index 00000000..15c7955d Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/image-registry/img-registry-update.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/image-registry/img-registry-updated.png b/website/versioned_docs/version-3.9.2/assets/user-guides/image-registry/img-registry-updated.png new file mode 100644 index 00000000..86a1a53f Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/image-registry/img-registry-updated.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/infrastructure/create-infrastructure/step-1.png b/website/versioned_docs/version-3.9.2/assets/user-guides/infrastructure/create-infrastructure/step-1.png new file mode 100644 index 00000000..fb456aea Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/infrastructure/create-infrastructure/step-1.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/infrastructure/create-infrastructure/step-2.png b/website/versioned_docs/version-3.9.2/assets/user-guides/infrastructure/create-infrastructure/step-2.png new file mode 100644 index 00000000..41ee3a04 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/infrastructure/create-infrastructure/step-2.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/infrastructure/create-infrastructure/step-3.png b/website/versioned_docs/version-3.9.2/assets/user-guides/infrastructure/create-infrastructure/step-3.png new file mode 100644 index 00000000..7764c397 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/infrastructure/create-infrastructure/step-3.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/infrastructure/create-infrastructure/step-4.png b/website/versioned_docs/version-3.9.2/assets/user-guides/infrastructure/create-infrastructure/step-4.png new file mode 100644 index 00000000..8a6a6826 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/infrastructure/create-infrastructure/step-4.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/infrastructure/create-infrastructure/step-5.png b/website/versioned_docs/version-3.9.2/assets/user-guides/infrastructure/create-infrastructure/step-5.png new file mode 100644 index 00000000..58907576 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/infrastructure/create-infrastructure/step-5.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/infrastructure/create-infrastructure/step-6.png b/website/versioned_docs/version-3.9.2/assets/user-guides/infrastructure/create-infrastructure/step-6.png new file mode 100644 index 00000000..6a997861 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/infrastructure/create-infrastructure/step-6.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/infrastructure/create-infrastructure/step-7.png b/website/versioned_docs/version-3.9.2/assets/user-guides/infrastructure/create-infrastructure/step-7.png new file mode 100644 index 00000000..121addc9 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/infrastructure/create-infrastructure/step-7.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/infrastructure/delete-infrastructure/step-1.png b/website/versioned_docs/version-3.9.2/assets/user-guides/infrastructure/delete-infrastructure/step-1.png new file mode 100644 index 00000000..1ec9271d Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/infrastructure/delete-infrastructure/step-1.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/infrastructure/delete-infrastructure/step-2.png b/website/versioned_docs/version-3.9.2/assets/user-guides/infrastructure/delete-infrastructure/step-2.png new file mode 100644 index 00000000..83a5b175 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/infrastructure/delete-infrastructure/step-2.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/infrastructure/delete-infrastructure/step-3.png b/website/versioned_docs/version-3.9.2/assets/user-guides/infrastructure/delete-infrastructure/step-3.png new file mode 100644 index 00000000..bf3624ef Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/infrastructure/delete-infrastructure/step-3.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/delete-workflow/step-1.png b/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/delete-workflow/step-1.png new file mode 100644 index 00000000..c2fefdc0 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/delete-workflow/step-1.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/delete-workflow/step-2.png b/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/delete-workflow/step-2.png new file mode 100644 index 00000000..73559664 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/delete-workflow/step-2.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/delete-workflow/step-3.png b/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/delete-workflow/step-3.png new file mode 100644 index 00000000..22ede174 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/delete-workflow/step-3.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/download-workflow-manifest/step-1.png b/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/download-workflow-manifest/step-1.png new file mode 100644 index 00000000..55fa7d9b Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/download-workflow-manifest/step-1.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/download-workflow-manifest/step-2.png b/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/download-workflow-manifest/step-2.png new file mode 100644 index 00000000..81dd4e8e Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/download-workflow-manifest/step-2.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/edit-schedule/edit-schedule-page.png b/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/edit-schedule/edit-schedule-page.png new file mode 100644 index 00000000..eaad8174 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/edit-schedule/edit-schedule-page.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/edit-schedule/edit-schedule.png b/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/edit-schedule/edit-schedule.png new file mode 100644 index 00000000..d7498869 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/edit-schedule/edit-schedule.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/edit-schedule/schedule-menu.png b/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/edit-schedule/schedule-menu.png new file mode 100644 index 00000000..00d6621c Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/edit-schedule/schedule-menu.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/observe-workflow/completed-workflow-with-chaos-results.png b/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/observe-workflow/completed-workflow-with-chaos-results.png new file mode 100644 index 00000000..72a4fc17 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/observe-workflow/completed-workflow-with-chaos-results.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/observe-workflow/experiment-table.png b/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/observe-workflow/experiment-table.png new file mode 100644 index 00000000..c381aa8f Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/observe-workflow/experiment-table.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/observe-workflow/running-workflow-with-logs.png b/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/observe-workflow/running-workflow-with-logs.png new file mode 100644 index 00000000..2cee4a09 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/observe-workflow/running-workflow-with-logs.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/observe-workflow/running-workflow.png b/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/observe-workflow/running-workflow.png new file mode 100644 index 00000000..5103edc7 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/observe-workflow/running-workflow.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/observe-workflow/runs-table.png b/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/observe-workflow/runs-table.png new file mode 100644 index 00000000..8c6e9f13 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/observe-workflow/runs-table.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/re-run-workflow/step-1.png b/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/re-run-workflow/step-1.png new file mode 100644 index 00000000..dd6aaf60 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/re-run-workflow/step-1.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/re-run-workflow/step-2.png b/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/re-run-workflow/step-2.png new file mode 100644 index 00000000..fbf72596 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/re-run-workflow/step-2.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/save-workflow-as-template/step-1.png b/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/save-workflow-as-template/step-1.png new file mode 100644 index 00000000..03607f72 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/save-workflow-as-template/step-1.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/save-workflow-as-template/step-2.png b/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/save-workflow-as-template/step-2.png new file mode 100644 index 00000000..2ddee2a3 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/save-workflow-as-template/step-2.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/save-workflow-as-template/step-3.png b/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/save-workflow-as-template/step-3.png new file mode 100644 index 00000000..2758641a Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/save-workflow-as-template/step-3.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/save-workflow-as-template/step-4.png b/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/save-workflow-as-template/step-4.png new file mode 100644 index 00000000..b10a06ee Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/save-workflow-as-template/step-4.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/schedule-workflow/add-parallel-faults.png b/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/schedule-workflow/add-parallel-faults.png new file mode 100644 index 00000000..922ab7e3 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/schedule-workflow/add-parallel-faults.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/schedule-workflow/advanced-options-experiment-creation.png b/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/schedule-workflow/advanced-options-experiment-creation.png new file mode 100644 index 00000000..5a172ca9 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/schedule-workflow/advanced-options-experiment-creation.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/schedule-workflow/chaos-experiment-save.png b/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/schedule-workflow/chaos-experiment-save.png new file mode 100644 index 00000000..6d10b6bc Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/schedule-workflow/chaos-experiment-save.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/schedule-workflow/litmus-chaos-hub.png b/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/schedule-workflow/litmus-chaos-hub.png new file mode 100644 index 00000000..86ac661b Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/schedule-workflow/litmus-chaos-hub.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/schedule-workflow/new-experiment-blank-canvas.png b/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/schedule-workflow/new-experiment-blank-canvas.png new file mode 100644 index 00000000..ad91e4bd Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/schedule-workflow/new-experiment-blank-canvas.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/schedule-workflow/new-experiment-choose-method.png b/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/schedule-workflow/new-experiment-choose-method.png new file mode 100644 index 00000000..298ef721 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/schedule-workflow/new-experiment-choose-method.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/schedule-workflow/new-experiment-identifiers.png b/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/schedule-workflow/new-experiment-identifiers.png new file mode 100644 index 00000000..9c3e4bc2 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/schedule-workflow/new-experiment-identifiers.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/schedule-workflow/new-experiment-infra-select.png b/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/schedule-workflow/new-experiment-infra-select.png new file mode 100644 index 00000000..f8029f07 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/schedule-workflow/new-experiment-infra-select.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/schedule-workflow/new-experiment-overview-home.png b/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/schedule-workflow/new-experiment-overview-home.png new file mode 100644 index 00000000..6c16bc88 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/schedule-workflow/new-experiment-overview-home.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/schedule-workflow/node-selectors.png b/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/schedule-workflow/node-selectors.png new file mode 100644 index 00000000..42fc903f Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/schedule-workflow/node-selectors.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/schedule-workflow/select-template-from-chaos-hub.png b/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/schedule-workflow/select-template-from-chaos-hub.png new file mode 100644 index 00000000..7a1339e6 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/schedule-workflow/select-template-from-chaos-hub.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/schedule-workflow/tolerations.png b/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/schedule-workflow/tolerations.png new file mode 100644 index 00000000..5d915a37 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/schedule-workflow/tolerations.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/schedule-workflow/tune-fault.png b/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/schedule-workflow/tune-fault.png new file mode 100644 index 00000000..1d6a9c65 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/injecting-fault/schedule-workflow/tune-fault.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/managing-projects/change-project-name/step-1.png b/website/versioned_docs/version-3.9.2/assets/user-guides/managing-projects/change-project-name/step-1.png new file mode 100644 index 00000000..817a90ef Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/managing-projects/change-project-name/step-1.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/managing-projects/change-project-name/step-2.png b/website/versioned_docs/version-3.9.2/assets/user-guides/managing-projects/change-project-name/step-2.png new file mode 100644 index 00000000..50f6f7df Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/managing-projects/change-project-name/step-2.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/managing-projects/change-project-name/step-3.png b/website/versioned_docs/version-3.9.2/assets/user-guides/managing-projects/change-project-name/step-3.png new file mode 100644 index 00000000..c383dafd Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/managing-projects/change-project-name/step-3.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/managing-projects/leave-project/step-1.png b/website/versioned_docs/version-3.9.2/assets/user-guides/managing-projects/leave-project/step-1.png new file mode 100644 index 00000000..44c570f0 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/managing-projects/leave-project/step-1.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/managing-projects/leave-project/step-2.png b/website/versioned_docs/version-3.9.2/assets/user-guides/managing-projects/leave-project/step-2.png new file mode 100644 index 00000000..821cbf67 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/managing-projects/leave-project/step-2.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/my-account/step-1.png b/website/versioned_docs/version-3.9.2/assets/user-guides/my-account/step-1.png new file mode 100644 index 00000000..e0a55bb9 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/my-account/step-1.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/my-account/step-2.png b/website/versioned_docs/version-3.9.2/assets/user-guides/my-account/step-2.png new file mode 100644 index 00000000..b5f5a0e4 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/my-account/step-2.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/my-account/step-3.png b/website/versioned_docs/version-3.9.2/assets/user-guides/my-account/step-3.png new file mode 100644 index 00000000..ca1b7f59 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/my-account/step-3.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/my-account/step-4.png b/website/versioned_docs/version-3.9.2/assets/user-guides/my-account/step-4.png new file mode 100644 index 00000000..04d93133 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/my-account/step-4.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/my-account/step-5.png b/website/versioned_docs/version-3.9.2/assets/user-guides/my-account/step-5.png new file mode 100644 index 00000000..f59da1cd Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/my-account/step-5.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/observability/data-source/configure.png b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/data-source/configure.png new file mode 100644 index 00000000..81855acc Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/data-source/configure.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/observability/data-source/connection-form-page-1.png b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/data-source/connection-form-page-1.png new file mode 100644 index 00000000..a9a8113a Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/data-source/connection-form-page-1.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/observability/data-source/connection-form-page-2.png b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/data-source/connection-form-page-2.png new file mode 100644 index 00000000..f875a98a Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/data-source/connection-form-page-2.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/observability/data-source/deletion-confirmation.png b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/data-source/deletion-confirmation.png new file mode 100644 index 00000000..f3c92c60 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/data-source/deletion-confirmation.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/observability/data-source/force-delete.png b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/data-source/force-delete.png new file mode 100644 index 00000000..a038dec1 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/data-source/force-delete.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/observability/data-source/multiple-agents-multiple-prometheus.png b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/data-source/multiple-agents-multiple-prometheus.png new file mode 100644 index 00000000..eedd7031 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/data-source/multiple-agents-multiple-prometheus.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/observability/data-source/multiple-agents-single-prometheus.png b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/data-source/multiple-agents-single-prometheus.png new file mode 100644 index 00000000..679750a4 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/data-source/multiple-agents-single-prometheus.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/observability/data-source/self-agent-prometheus.png b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/data-source/self-agent-prometheus.png new file mode 100644 index 00000000..76e42978 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/data-source/self-agent-prometheus.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/observability/data-source/tab.png b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/data-source/tab.png new file mode 100644 index 00000000..a31c50e7 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/data-source/tab.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/observability/setup/create-dashboard-add-panel.png b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/setup/create-dashboard-add-panel.png new file mode 100644 index 00000000..f3ea95a9 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/setup/create-dashboard-add-panel.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/observability/setup/create-dashboard-edit-query.png b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/setup/create-dashboard-edit-query.png new file mode 100644 index 00000000..f2700305 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/setup/create-dashboard-edit-query.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/observability/setup/create-dashboard-tune-queries.png b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/setup/create-dashboard-tune-queries.png new file mode 100644 index 00000000..0983032a Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/setup/create-dashboard-tune-queries.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/observability/setup/create-dashboard-visualization-options.png b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/setup/create-dashboard-visualization-options.png new file mode 100644 index 00000000..39e91237 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/setup/create-dashboard-visualization-options.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/observability/setup/manage-application-dashboard-applications-selection.png b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/setup/manage-application-dashboard-applications-selection.png new file mode 100644 index 00000000..4a531071 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/setup/manage-application-dashboard-applications-selection.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/observability/setup/manage-application-dashboard-create-dashboard.png b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/setup/manage-application-dashboard-create-dashboard.png new file mode 100644 index 00000000..6eb2729b Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/setup/manage-application-dashboard-create-dashboard.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/observability/setup/manage-application-dashboard-dashboard-type.png b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/setup/manage-application-dashboard-dashboard-type.png new file mode 100644 index 00000000..d23b34e3 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/setup/manage-application-dashboard-dashboard-type.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/observability/setup/manage-application-dashboard-metadata.png b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/setup/manage-application-dashboard-metadata.png new file mode 100644 index 00000000..0b8d57fb Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/setup/manage-application-dashboard-metadata.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/observability/setup/manage-application-dashboard-no-data-source-dashboard.png b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/setup/manage-application-dashboard-no-data-source-dashboard.png new file mode 100644 index 00000000..d8476fed Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/setup/manage-application-dashboard-no-data-source-dashboard.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/observability/setup/manage-application-dashboard-select-metrics.png b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/setup/manage-application-dashboard-select-metrics.png new file mode 100644 index 00000000..80ff010d Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/setup/manage-application-dashboard-select-metrics.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/observability/setup/manage-application-dashboard-table.png b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/setup/manage-application-dashboard-table.png new file mode 100644 index 00000000..31caedf9 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/setup/manage-application-dashboard-table.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/observability/setup/overview-first-look.png b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/setup/overview-first-look.png new file mode 100644 index 00000000..bde0b874 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/setup/overview-first-look.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/observability/setup/overview-with-dashboards.png b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/setup/overview-with-dashboards.png new file mode 100644 index 00000000..8da1f692 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/setup/overview-with-dashboards.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/observability/setup/overview-with-datasource.png b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/setup/overview-with-datasource.png new file mode 100644 index 00000000..2b638be4 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/setup/overview-with-datasource.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/observability/setup/recently-updated-workflow-dashboards.png b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/setup/recently-updated-workflow-dashboards.png new file mode 100644 index 00000000..247d1bea Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/setup/recently-updated-workflow-dashboards.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/observability/setup/view-chaos-impact-copy-dashboard.png b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/setup/view-chaos-impact-copy-dashboard.png new file mode 100644 index 00000000..c2d0770b Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/setup/view-chaos-impact-copy-dashboard.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/observability/setup/view-chaos-impact-edit-chaos-queries.png b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/setup/view-chaos-impact-edit-chaos-queries.png new file mode 100644 index 00000000..124e4ae8 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/setup/view-chaos-impact-edit-chaos-queries.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/observability/setup/view-chaos-impact-first-look.png b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/setup/view-chaos-impact-first-look.png new file mode 100644 index 00000000..02237416 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/setup/view-chaos-impact-first-look.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/observability/setup/view-chaos-impact-info.png b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/setup/view-chaos-impact-info.png new file mode 100644 index 00000000..97241981 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/setup/view-chaos-impact-info.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/observability/setup/view-chaos-impact-more-options.png b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/setup/view-chaos-impact-more-options.png new file mode 100644 index 00000000..5a7a28be Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/setup/view-chaos-impact-more-options.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/observability/setup/view-chaos-impact-popout.png b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/setup/view-chaos-impact-popout.png new file mode 100644 index 00000000..be994b8c Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/setup/view-chaos-impact-popout.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/observability/setup/view-chaos-impact-refresh-rate.png b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/setup/view-chaos-impact-refresh-rate.png new file mode 100644 index 00000000..be80064b Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/setup/view-chaos-impact-refresh-rate.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/observability/setup/view-chaos-impact-show-chaos-during-this-interval.png b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/setup/view-chaos-impact-show-chaos-during-this-interval.png new file mode 100644 index 00000000..b5c6ff1b Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/setup/view-chaos-impact-show-chaos-during-this-interval.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/observability/workflow-analysis/experiments-table.png b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/workflow-analysis/experiments-table.png new file mode 100644 index 00000000..ca6b7726 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/workflow-analysis/experiments-table.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/observability/workflow-analysis/workflow-activity.png b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/workflow-analysis/workflow-activity.png new file mode 100644 index 00000000..8670dec1 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/workflow-analysis/workflow-activity.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/observability/workflow-analysis/workflow-details.png b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/workflow-analysis/workflow-details.png new file mode 100644 index 00000000..3220f72a Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/workflow-analysis/workflow-details.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/observability/workflow-analysis/workflow-heatmap.png b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/workflow-analysis/workflow-heatmap.png new file mode 100644 index 00000000..c25e6fc6 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/workflow-analysis/workflow-heatmap.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/observability/workflow-analysis/workflow-multi-run.png b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/workflow-analysis/workflow-multi-run.png new file mode 100644 index 00000000..f05e388e Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/workflow-analysis/workflow-multi-run.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/observability/workflow-analysis/workflow-single-run.png b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/workflow-analysis/workflow-single-run.png new file mode 100644 index 00000000..ed73caae Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/workflow-analysis/workflow-single-run.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/observability/workflow-dashboard/comparison-graph-hover.png b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/workflow-dashboard/comparison-graph-hover.png new file mode 100644 index 00000000..7a01aeb3 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/workflow-dashboard/comparison-graph-hover.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/observability/workflow-dashboard/comparison-graph-with-dropdown.png b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/workflow-dashboard/comparison-graph-with-dropdown.png new file mode 100644 index 00000000..48edb1dc Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/workflow-dashboard/comparison-graph-with-dropdown.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/observability/workflow-dashboard/comparison-graph.png b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/workflow-dashboard/comparison-graph.png new file mode 100644 index 00000000..fdc88805 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/workflow-dashboard/comparison-graph.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/observability/workflow-dashboard/export-button.png b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/workflow-dashboard/export-button.png new file mode 100644 index 00000000..19935b1b Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/workflow-dashboard/export-button.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/observability/workflow-dashboard/schedules-stats-dropdown.png b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/workflow-dashboard/schedules-stats-dropdown.png new file mode 100644 index 00000000..94a21f19 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/workflow-dashboard/schedules-stats-dropdown.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/observability/workflow-dashboard/schedules-stats.png b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/workflow-dashboard/schedules-stats.png new file mode 100644 index 00000000..731c4a69 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/workflow-dashboard/schedules-stats.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/observability/workflow-dashboard/workflow-runs-stats-dropdown.png b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/workflow-dashboard/workflow-runs-stats-dropdown.png new file mode 100644 index 00000000..62882ba7 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/workflow-dashboard/workflow-runs-stats-dropdown.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/observability/workflow-dashboard/workflow-runs-stats.png b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/workflow-dashboard/workflow-runs-stats.png new file mode 100644 index 00000000..102148db Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/workflow-dashboard/workflow-runs-stats.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/observability/workflow-dashboard/workflows-comparison-table-1.png b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/workflow-dashboard/workflows-comparison-table-1.png new file mode 100644 index 00000000..a9a9c2e5 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/workflow-dashboard/workflows-comparison-table-1.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/observability/workflow-dashboard/workflows-comparison-table-2.png b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/workflow-dashboard/workflows-comparison-table-2.png new file mode 100644 index 00000000..ffacde1b Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/workflow-dashboard/workflows-comparison-table-2.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/observability/workflow-dashboard/workflows-radial-chart.png b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/workflow-dashboard/workflows-radial-chart.png new file mode 100644 index 00000000..7ab093a0 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/observability/workflow-dashboard/workflows-radial-chart.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/resilience-probes/create-probe/step-1.png b/website/versioned_docs/version-3.9.2/assets/user-guides/resilience-probes/create-probe/step-1.png new file mode 100644 index 00000000..53277c1c Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/resilience-probes/create-probe/step-1.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/resilience-probes/create-probe/step-2.png b/website/versioned_docs/version-3.9.2/assets/user-guides/resilience-probes/create-probe/step-2.png new file mode 100644 index 00000000..c11a10e8 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/resilience-probes/create-probe/step-2.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/resilience-probes/create-probe/step-3.png b/website/versioned_docs/version-3.9.2/assets/user-guides/resilience-probes/create-probe/step-3.png new file mode 100644 index 00000000..3738ae82 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/resilience-probes/create-probe/step-3.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/resilience-probes/create-probe/step-4.png b/website/versioned_docs/version-3.9.2/assets/user-guides/resilience-probes/create-probe/step-4.png new file mode 100644 index 00000000..5c5d95e4 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/resilience-probes/create-probe/step-4.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/resilience-probes/create-probe/step-5.png b/website/versioned_docs/version-3.9.2/assets/user-guides/resilience-probes/create-probe/step-5.png new file mode 100644 index 00000000..330f9543 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/resilience-probes/create-probe/step-5.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/resilience-probes/create-probe/step-6.png b/website/versioned_docs/version-3.9.2/assets/user-guides/resilience-probes/create-probe/step-6.png new file mode 100644 index 00000000..acb5ece4 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/resilience-probes/create-probe/step-6.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/resilience-probes/delete-probe/step-1.png b/website/versioned_docs/version-3.9.2/assets/user-guides/resilience-probes/delete-probe/step-1.png new file mode 100644 index 00000000..26eb2f09 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/resilience-probes/delete-probe/step-1.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/resilience-probes/delete-probe/step-2.png b/website/versioned_docs/version-3.9.2/assets/user-guides/resilience-probes/delete-probe/step-2.png new file mode 100644 index 00000000..d6714c1c Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/resilience-probes/delete-probe/step-2.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/resilience-probes/delete-probe/step-3.png b/website/versioned_docs/version-3.9.2/assets/user-guides/resilience-probes/delete-probe/step-3.png new file mode 100644 index 00000000..c1d60b56 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/resilience-probes/delete-probe/step-3.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/resilience-probes/edit-probe/step-1.png b/website/versioned_docs/version-3.9.2/assets/user-guides/resilience-probes/edit-probe/step-1.png new file mode 100644 index 00000000..d9657006 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/resilience-probes/edit-probe/step-1.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/resilience-probes/edit-probe/step-2.png b/website/versioned_docs/version-3.9.2/assets/user-guides/resilience-probes/edit-probe/step-2.png new file mode 100644 index 00000000..574e2c9b Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/resilience-probes/edit-probe/step-2.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/resilience-probes/edit-probe/step-3.png b/website/versioned_docs/version-3.9.2/assets/user-guides/resilience-probes/edit-probe/step-3.png new file mode 100644 index 00000000..573c18cb Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/resilience-probes/edit-probe/step-3.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/resilience-probes/view-probe/step-1.png b/website/versioned_docs/version-3.9.2/assets/user-guides/resilience-probes/view-probe/step-1.png new file mode 100644 index 00000000..a0767f90 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/resilience-probes/view-probe/step-1.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/resilience-probes/view-probe/step-2.png b/website/versioned_docs/version-3.9.2/assets/user-guides/resilience-probes/view-probe/step-2.png new file mode 100644 index 00000000..209ff6ae Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/resilience-probes/view-probe/step-2.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/resilience-probes/view-probe/step-3.png b/website/versioned_docs/version-3.9.2/assets/user-guides/resilience-probes/view-probe/step-3.png new file mode 100644 index 00000000..b1d73599 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/resilience-probes/view-probe/step-3.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/teaming/accept-invite/step-1.png b/website/versioned_docs/version-3.9.2/assets/user-guides/teaming/accept-invite/step-1.png new file mode 100644 index 00000000..bc0f1a02 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/teaming/accept-invite/step-1.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/teaming/accept-invite/step-2.png b/website/versioned_docs/version-3.9.2/assets/user-guides/teaming/accept-invite/step-2.png new file mode 100644 index 00000000..5dbf0ec4 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/teaming/accept-invite/step-2.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/teaming/edit-invite/step-1.png b/website/versioned_docs/version-3.9.2/assets/user-guides/teaming/edit-invite/step-1.png new file mode 100644 index 00000000..7be1d24e Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/teaming/edit-invite/step-1.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/teaming/invite-team-member/step-1.png b/website/versioned_docs/version-3.9.2/assets/user-guides/teaming/invite-team-member/step-1.png new file mode 100644 index 00000000..619578d7 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/teaming/invite-team-member/step-1.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/teaming/invite-team-member/step-2.png b/website/versioned_docs/version-3.9.2/assets/user-guides/teaming/invite-team-member/step-2.png new file mode 100644 index 00000000..63bd8398 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/teaming/invite-team-member/step-2.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/teaming/remove-team-member/step-1.png b/website/versioned_docs/version-3.9.2/assets/user-guides/teaming/remove-team-member/step-1.png new file mode 100644 index 00000000..2abdae92 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/teaming/remove-team-member/step-1.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/teaming/remove-team-member/step-2.png b/website/versioned_docs/version-3.9.2/assets/user-guides/teaming/remove-team-member/step-2.png new file mode 100644 index 00000000..763a923f Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/teaming/remove-team-member/step-2.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/uninstall-litmus/disconnect-icon.png b/website/versioned_docs/version-3.9.2/assets/user-guides/uninstall-litmus/disconnect-icon.png new file mode 100644 index 00000000..e01cd45e Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/uninstall-litmus/disconnect-icon.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/upgrade/upgrade-agent.png b/website/versioned_docs/version-3.9.2/assets/user-guides/upgrade/upgrade-agent.png new file mode 100644 index 00000000..1b803d5a Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/upgrade/upgrade-agent.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/user-management/create-user/step-1.png b/website/versioned_docs/version-3.9.2/assets/user-guides/user-management/create-user/step-1.png new file mode 100644 index 00000000..bf97a3f7 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/user-management/create-user/step-1.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/user-management/create-user/step-2.png b/website/versioned_docs/version-3.9.2/assets/user-guides/user-management/create-user/step-2.png new file mode 100644 index 00000000..e40b11be Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/user-management/create-user/step-2.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/user-management/create-user/step-3.png b/website/versioned_docs/version-3.9.2/assets/user-guides/user-management/create-user/step-3.png new file mode 100644 index 00000000..eac68c99 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/user-management/create-user/step-3.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/user-management/deactivate-user/step-1.png b/website/versioned_docs/version-3.9.2/assets/user-guides/user-management/deactivate-user/step-1.png new file mode 100644 index 00000000..413ac2d9 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/user-management/deactivate-user/step-1.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/user-management/deactivate-user/step-2.png b/website/versioned_docs/version-3.9.2/assets/user-guides/user-management/deactivate-user/step-2.png new file mode 100644 index 00000000..8f83055a Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/user-management/deactivate-user/step-2.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/user-management/deactivate-user/step-3.png b/website/versioned_docs/version-3.9.2/assets/user-guides/user-management/deactivate-user/step-3.png new file mode 100644 index 00000000..df0d1f13 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/user-management/deactivate-user/step-3.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/user-management/reset-password/step-1.png b/website/versioned_docs/version-3.9.2/assets/user-guides/user-management/reset-password/step-1.png new file mode 100644 index 00000000..1d0474f4 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/user-management/reset-password/step-1.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/user-management/reset-password/step-2.png b/website/versioned_docs/version-3.9.2/assets/user-guides/user-management/reset-password/step-2.png new file mode 100644 index 00000000..c1b98676 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/user-management/reset-password/step-2.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/user-guides/user-management/view-user/step-1.png b/website/versioned_docs/version-3.9.2/assets/user-guides/user-management/view-user/step-1.png new file mode 100644 index 00000000..19fc30e9 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/user-guides/user-management/view-user/step-1.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/workflow-observe-completed.png b/website/versioned_docs/version-3.9.2/assets/workflow-observe-completed.png new file mode 100644 index 00000000..cb29658e Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/workflow-observe-completed.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/workflow-observe-log.png b/website/versioned_docs/version-3.9.2/assets/workflow-observe-log.png new file mode 100644 index 00000000..c2fd5c71 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/workflow-observe-log.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/workflow-observe-running.png b/website/versioned_docs/version-3.9.2/assets/workflow-observe-running.png new file mode 100644 index 00000000..f4a93b10 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/workflow-observe-running.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/workflow-observe-select.png b/website/versioned_docs/version-3.9.2/assets/workflow-observe-select.png new file mode 100644 index 00000000..7b6d4374 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/workflow-observe-select.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/workflow-observe-table-logs.png b/website/versioned_docs/version-3.9.2/assets/workflow-observe-table-logs.png new file mode 100644 index 00000000..37c41ca0 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/workflow-observe-table-logs.png differ diff --git a/website/versioned_docs/version-3.9.2/assets/workflow-observe-table.png b/website/versioned_docs/version-3.9.2/assets/workflow-observe-table.png new file mode 100644 index 00000000..f3b655d6 Binary files /dev/null and b/website/versioned_docs/version-3.9.2/assets/workflow-observe-table.png differ diff --git a/website/versioned_docs/version-3.9.2/best-practices.md b/website/versioned_docs/version-3.9.2/best-practices.md new file mode 100644 index 00000000..ff53dda5 --- /dev/null +++ b/website/versioned_docs/version-3.9.2/best-practices.md @@ -0,0 +1,27 @@ +--- +id: best-practices +title: Best Practices +sidebar_label: Best Practices +--- + +--- + +## Probes + +#### Restrict execution scope + +- In the case where a malicious, privileged user (who doesn't have cluster access) tries to extract the SA token from the probe pod and leverages it for destructive action, the recommended way to prevent it would be to have a reduced scope within the service account itself i.e. create an RBAC without loopholes. + + The RBAC for the agent itself can be subject to scrutiny before deployment, it can be restricted to a namespace with verbs against restricted resources, etc. The agent setup can be performed using Helm too, with changes to templates undergoing review. + + The intent of the command probe pod is to allow the users to perform custom checks which allow them to either (a) validate the impact of chaos, either within or outside the cluster (b) manually trigger remediation or (c) perform tasks that complement the chaos itself (such as load etc.,). + + Having a restrictive scope for this feature would depend on what kind of tasks are allowed by the cluster/devops admins within the purview of (a), (b), (c) - rather than being imposed from within the product by default. If some of the validations involve performing kube-api calls, we would need to support that / binding the admin's decision. + +- Only users with **Executor** roles can carry out executing probes. Project **Owners**, however, wield the authority to create, edit, and execute probes, shaping them to suit project needs and objectives. This division ensures efficient probe management, with the Executors handling execution and the project Owners overseeing customization and design. + +#### Future Roadmap + +- Resilience probes addition and execution are to be supported via ChaosHub and is also expected to have preset templates. The change entails probes being introduced as first class citizens/resources within the platform that can be reused across experiments via Hub. In this context, the ability to create and modify experiments/probes can be provided to a owner persona, with the probes being maintained in a Git repository (with its introduction in ChaosHub), which is also expected to have the right number of approvals for use. These are then executed as is by the executor persona on the platform. + +- Adding a command scanner to restrict malicious linux commands/attacks used against cmdProbes via enhanced checks. Integrate the command scanner into the CREATE and UPDATE APIs of cmdProbes ensures that all commands passed through these interfaces are subjected to thorough scrutiny. This involves modifying the API endpoints to include the command scanning functionality and implementing appropriate validation logic. diff --git a/website/versioned_docs/version-3.9.2/concepts/chaos-workflow.md b/website/versioned_docs/version-3.9.2/concepts/chaos-workflow.md new file mode 100644 index 00000000..824590e6 --- /dev/null +++ b/website/versioned_docs/version-3.9.2/concepts/chaos-workflow.md @@ -0,0 +1,428 @@ +--- +id: chaos-workflow +title: Chaos experiment +sidebar_label: Chaos experiment +--- + +--- + +Chaos experiments gives you the flexibility to create complex, real-life failure scenarios that are used to validate your target workloads. At the same time, chaos experiments are declarative and can be constructed using the ChaosCenter UI without any programmatic intervention. + +A chaos experiment is composed of chaos faults that are arranged in a specific order to create a failure scenario. The chaos faults target various aspects of an application, including the constituent microservices and underlying infrastructure. You can tune the parameters associated with these faults to impart the desired chaos behavior. + +- It is useful in automating a series of pre-conditioning steps or action which is necessary to be performed before triggering the chaos injection. + +- A Chaos Experiment can also be used to perform different operations parallelly to achieve a desired chaos impact. + +:::note +With the latest release of LitmusChaos 3.0.0: +The term **Chaos Experiment** has been changed to **Chaos Fault**. +The term **Chaos Scenario/Workflow** has been changed to **Chaos Experiment**. +::: + +## Prerequisites + +The following should be required before creating a Chaos Experiment: + +- [ChaosCenter](../getting-started/resources.md#chaoscenter) +- [Chaos Infrastructure](../getting-started/resources.md#chaosagents) +- [Probes](probes.md) + +## Defining and executing a chaos experiment + +LitmusChaos leverages the popular GitOps tool **Argo** to achieve this goal. Argo enables the creation of different chaos experiments together in form of chaos experiments which are extremely simple and efficient to use. + +With the help of **ChaosCenter**, chaos experiments with different types of faults can be created. In a Chaos Experiment, the faults can be set to execute in parallel to each other and the user can tune the chaos experiment by adding additional steps to simulate a desired fault that might occur in the production stage. + +### Chaos experiment life cycle + +Here is a sample pod-delete chaos experiment 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: 3.0.0 + 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:3.0.0 + 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: 3.0.0 + 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 experiment is similar to that of a Kubernetes Object. It consists of mandatory fields like `apiVersion`, `kind`, `metadata`, `spec`. + +The **spec** in a Chaos Experiment is where the different steps are mentioned and the overall life cycle of the chaos experiment is described. +We can see different `templates` are present in the spec of a chaos experiment. + +``` +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 faults, executing the chaos engine of the faults, and at the end we have the revert chaos step which deletes/removes the resources that were created as part of the chaos experiment. + +Some additional checks can be added with the faults in the form of probes. These probes are defined in the ChaosEngines of the faults and are updated when the fault execution takes place. +The overall chaos experiment result can be viewed with the ChaosResult CRD which contains the `verdict` and the `probeSuccessPercentage` (a ratio of successful checks v/s total probes). + +## Chaos experiment run + +A chaos experiment run can be defined as a single/one-time execution of the chaos experiment. There can be multiple runs of a single chaos experiment. If the chaos experiment consists of a cron syntax, it will run periodically according to the cron provided in the chaos experiment. + +## Resilience Score + +**Resiliency score** is an overall measure of the resiliency of a system for a given chaos experiment, which is obtained upon executing the constituent experiment faults on that system. + +While creating a chaos experiment, certain weights are assigned to all the faults present in the chaos experiment. These weights signify the priority/importance of the fault. The higher the weight, the more significant the fault is. + +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 fault, we look for the Probe Success Percentage for that fault itself (Post Chaos) and calculate the total resilience result for that fault as a multiplication of the weight given and the probe success percentage returned after the Chaos Run. + +``` +Total Resilience for one single fault = (Weight Given to that fault * Probe Success Percentage) +Overall Resilience Score = Total Test Result / Sum of the assigned weights of the faults +``` + +## Cron chaos experiment + +Cron Chaos Experiment is a type of chaos experiment that runs on a pre-defined schedule. It consists of a mandatory field `spec.schedule`. A cron syntax is provided in this field at which the chaos experiment execution takes +place. + +Here's a sample Cron Chaos Experiment 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 experiment, we can see the cron syntax at `spec.schedule` is + +``` +spec: + schedule: 10 0-23 * * * +``` + +This means the chaos experiment will be executed at the 10th minute of every hour. + +A chaos experiment can be changed into Cron Chaos Experiment from the ChaosCenter. +While scheduling a chaos experiment, in the `Schedule` step, there are few options as part of Recurring Schedules. These include: + +- Every hour +- Every Day +- Every Week +- Every Month + +## Summary + +A chaos experiment is a combination of different steps combined together to perform a specific chaos use-case on a Kubernetes system. These steps can include installing fault steps, ChaosEngine CR for target selection, revert-chaos steps, etc. Chaos Experiments can be scheduled for a later time with the help of Cron Chaos Experiments. +These chaos experiments consist of a cron syntax that is used for scheduling a chaos experiment. Once the chaos experiment execution is completed, the resiliency of the targeted application is calculated. Several weights are assigned to different faults in the chaos experiment. These weights are used along with the ProbeSuccessPercentage to find out the resiliency score. + +## Learn More + +- [Explore Probes](probes.md) +- [Visualize a Chaos Experiment](visualize-experiment.md) diff --git a/website/versioned_docs/version-3.9.2/concepts/chaoshub.md b/website/versioned_docs/version-3.9.2/concepts/chaoshub.md new file mode 100644 index 00000000..15ccac93 --- /dev/null +++ b/website/versioned_docs/version-3.9.2/concepts/chaoshub.md @@ -0,0 +1,105 @@ +--- +id: chaoshub +title: ChaosHub +sidebar_label: ChaosHub +--- + +--- + +A ChaosHub is a collection of experiment templates and faults that you can use to create and launch chaos experiments. Both experiments and faults are stored as manifests in an appropriate directory structure. This way, new experiment templates and faults can be added directly to the repository as files. In addition, the experiment templates can be derived from the existing experiments to be saved in ChaosHub from the web UI. + +- ChaosHub is accessed using a Git service provider such as GitHub, where ChaosHub exists as a repository. This allows native version control and management of the faults and experiment artifacts. + +- Chaos experiments can be created from the public [ChaosHub](http://hub.litmuschaos.io/) which is already connected to your ChaosCenter, or a custom ChaosHub which is a [fork](https://github.com/litmuschaos/chaos-charts) of the public ChaosHub where custom faults can be stored. + +## Prerequisites + +The following are the prerequisites for creating a Chaos Experiment: + +- 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 to a Git repository using ChaosHub + +With ChaosHub, you can construct chaos experiments by selecting, tuning and sequencing different faults together from their connected ChaosHubs. + +You can make changes in your forked repositories and sync it with the Portal to get the latest changes from the fork. + +By default, a public ChaosHub is provided when the ChaosCenter is installed for the first time. + + + +### 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 ChaosHub, you need provide the hub name, Git URL of the forked repository and the branch name similar to that of public hub and the repository can be connected in two ways: + + + +#### a. Access token + +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 experiments and experiments in a ChaosHub + +### 1. View the PreDefined Chaos Experiments + +After connecting a ChaosHub, you can view the different pre-defined chaos experiments present in the ChaosHub. + + + +### 2. View the Chaos Faults + +Similarly, you can view the different charts and the fault. These charts are sorted according to different categories like generic, AWS, Azure, Kube-Components etc. + + + +### 3. View the fault details + +You can select one of the chaos faults and can examine the fault details. The fault page consists of all the important details like the description of the fault, a tutorial video, the maintainer of the fault, etc. + +You can also find the Experiment manifest URL, RBAC URL, and the ChaosEngine URLs of the fault. +These URLs are required for the creation of custom chaos experiments. + + + +## Disconnect a ChaosHub + +To remove a ChaosHub from a project, you can select the **Disconnect Hub** option from the ChaosHub card. + +## Summary + +You can select one of the chaos faults and can examine the fault details.The fault page consists of all the important details like the description of the fault, a tutorial video, the maintainer of the fault, etc. +You can also find the Experiment URL URL, RBAC URL, and the ChaosEngine yaml URL of the fault. +These yaml URLs are required for the creation of Custom Chaos Experiments. + +## Learn More + +- [What is a Chaos Experiment](chaos-workflow.md) diff --git a/website/versioned_docs/version-3.9.2/concepts/gitops.md b/website/versioned_docs/version-3.9.2/concepts/gitops.md new file mode 100644 index 00000000..05c725ab --- /dev/null +++ b/website/versioned_docs/version-3.9.2/concepts/gitops.md @@ -0,0 +1,49 @@ +--- +id: gitops +title: Litmus with GitOps +sidebar_label: GitOps +--- + +--- + +## Prerequisites + +- Chaos Infrastructure +- [Chaos Experiment](chaos-workflow.md) + +The GitOps feature in Litmus enables you to configure a single source of truth for your chaos experiments and faults, 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 experiments directly from git enabling a vast scope of automation in CI/CD pipelines. + +:::note +With the latest release of LitmusChaos 3.0.0: + +
  • The term Chaos Experiment has been changed to Chaos Fault.
  • +
  • The term Chaos Scenario/Workflow has been changed to Chaos Experiment.
  • +::: + +## 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 experiments 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 experiments 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 infrastructure and can be more than one, other is the self chaos infrastructure where the Litmus(red cluster) is installed. After a chaos infrastructure 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: The 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 experiment using `workflow_id` from the git repository. Once it gets the required chaos experiment, it will send it to the subscriber which is responsible for applying the chaos experiment to the target cluster. After the chaos experiment 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 experiment identity which will be subscribed by the target application deployment and it is present in the chaos experiment 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. + +## Learn More + +- [Configuring GitOps](../user-guides/gitops-configuration.md) +- [Schedule a Chaos Experiment](../user-guides/schedule-experiment.md) +- [Observe a Chaos Experiment](../user-guides/observe-experiment.md) diff --git a/website/versioned_docs/version-3.9.2/concepts/infrastructure.md b/website/versioned_docs/version-3.9.2/concepts/infrastructure.md new file mode 100644 index 00000000..32f743d1 --- /dev/null +++ b/website/versioned_docs/version-3.9.2/concepts/infrastructure.md @@ -0,0 +1,31 @@ +--- +id: chaos-infrastructure +title: Chaos infrastructure +sidebar_label: Chaos infrastructure +--- + +Chaos infrastructure is a service that runs in your target environment and aids the Litmus control plane in accessing and injecting chaos at a cloud-native scale. All the chaos infrastructure services adhere to the principle of least privilege, where the services execute with the minimum number of required permissions. A chaos infrastructure can be created under a Chaos Environment. + +:::note +With the latest release of LitmusChaos 3.0.0 the term **Chaos Delegate/Agent** has been changed to **Chaos Infrastructure**. +::: + +## Chaos environment + +An environment represents where you are installing your chaos infrastructure and acts as an additional level of abstraction for the same. You categorize each environment as prod or non-prod. + +### Access types + +Chaos infrastructure can be created in two modes: + +- **Cluster Wide:** This mode of infrastructure installation allows targeting resources across the entire cluster, in all the namespaces, as part of an experiment. +- **Namespace Mode:** This mode of infrastructure installation allows targeting resources only in the namespace where the chaos infrastructure is deployed. + +:::note +- There can only be one cluster-wide chaos infrastructure per cluster. +- There may be multiple namespace-scoped chaos infrastructures per cluster. +::: + +## Learn more + +- [How to connect a Chaos Infrastructure](../user-guides/chaos-infrastructure-installation.md) diff --git a/website/versioned_docs/version-3.9.2/concepts/oauth-dex-concept.md b/website/versioned_docs/version-3.9.2/concepts/oauth-dex-concept.md new file mode 100644 index 00000000..0ac2cd33 --- /dev/null +++ b/website/versioned_docs/version-3.9.2/concepts/oauth-dex-concept.md @@ -0,0 +1,44 @@ +--- +id: oauth-dex-concept +title: Authentication in ChaosCenter +sidebar_label: Authentication in ChaosCenter +--- + +--- + +## 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 **litmusctl** and **litmusportal-frontend** make use of this server. + +In order to provide enhanced and seamless login features, we wanted to integrate OAuth and other authentication mechanisms such as OpenID connect. To have flexibility, litmus-portal makes use of an additional component, [Dex OIDC server](https://dexidp.io/). + +Dex is a highly extensible cloud-native OIDC provider that is able to take care of various authentication mechanisms. With Dex being deployed, the authentication-server can communicate with the dex-server which enables the 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-3.9.2/concepts/overview.md b/website/versioned_docs/version-3.9.2/concepts/overview.md new file mode 100644 index 00000000..5f2e2134 --- /dev/null +++ b/website/versioned_docs/version-3.9.2/concepts/overview.md @@ -0,0 +1,41 @@ +--- +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. + +### [Probes](probes.md) + +Probes are pluggable checks that can be defined within the ChaosEngine for any Chaos Fault. + +### [ChaosHub](chaoshub.md) + +ChaosHub allows you to orchestrate chaos experiments from the Public **[ChaosHub](http://hub.litmuschaos.io/)** or an alternate source for the Faults. + +### [Chaos Experiment](chaos-workflow.md) + +Chaos Experiment is a set of different operations coupled together to achieve desired chaos impact on a Kubernetes Cluster. + +### [Chaos Infrastructure](infrastructure.md) + +Chaos infrastructure is a service that runs in your target environment and aids Litmus control plane in accessing and injecting chaos. + +### [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 experiment with multiple different projects across different chaos infrastructures. + +### [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 experiments and faults. diff --git a/website/versioned_docs/version-3.9.2/concepts/probes.md b/website/versioned_docs/version-3.9.2/concepts/probes.md new file mode 100644 index 00000000..4547c756 --- /dev/null +++ b/website/versioned_docs/version-3.9.2/concepts/probes.md @@ -0,0 +1,1137 @@ +--- +id: probes +title: Resilience Probes +sidebar_label: Resilience Probes +--- + +--- + +Resilience Probes are pluggable checks that can be defined within the ChaosEngine for any Chaos Experiment. The fault pods execute these checks based on the mode they are defined in & factor their success as necessary conditions in determining the verdict of the fault (along with the standard `in-built` checks). + +## Prerequisites + +To understand the concepts of Probes better make sure you are aware of the [ChaosEngine](glossary.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. +- **initialDelay**: Represents the initial waiting time interval for the probes. +- **stopOnFailure**: It can be set to true/false to stop or continue the fault execution after probe fails. + +:::note +If probe needs any additional RBAC permissions other than the fault'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 fault uses to gauge health/service availability (or other custom conditions) as part of the entry/exit criteria. The received status code is mapped against an expected status. It supports HTTP `Get` and `Post` methods. + +In HTTP `Get` method, it sends an HTTP `GET` request to the provided URL and matches the response code based on the given criteria (`==`, `!=`, `oneOf`). + +In HTTP `Post` method, it sends an HTTP `POST` request to the provided URL. The http body can be provided in the `body` field. In the case of a complex POST request in which the body spans multiple lines, the `bodyPath` attribute can be used to provide the path to a file consisting of the same. This file can be made available to the fault pod via a ConfigMap resource, with the ConfigMap name being defined in the [ChaosEngine](glossary.md) OR the ChaosExperiment CR. +It can be defined at `.spec.experiments[].spec.probe` inside ChaosEngine. + +> `body` and `bodyPath` are mutually exclusive + +```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: 5s + interval: 5s + retry: 1 + probePollingInterval: 2s +``` + +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 fault 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: 5s + interval: 5s + retry: 1 + initialDelay: 5s +``` + +> `source.hostNetwork` can be set to `true` to allow access to the node network namespace for the pod executing the probe + +For insights into efficient chaos probe practices and our roadmap for the future, check out the [best practices](../best-practices.md#probes). + +### 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 fault 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: 5s + interval: 5s + 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 fault 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 fault 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: 5s + interval: 5s + retry: 1 +``` + +
    + +--- + +## Probe Status & Deriving Inferences + +The litmus chaos faults 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 fault 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 a fault 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 fault 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 fault 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: 5s + interval: 5s + 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: 5s + interval: 5s + 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
    DescriptionFlag to hold the name of the probe
    TypeMandatory
    Rangen/a type: string
    NotesThe .name holds the name of the probe. It can be set based on the usecase
    + + + + + + + + + + + + + + + + + + + + + + +
    Field.type
    DescriptionFlag to hold the type of the probe
    TypeMandatory
    Range httpProbe, k8sProbe, cmdProbe, promProbe
    NotesThe .type supports four type of probes. It can one of the httpProbe, k8sProbe, cmdProbe, promProbe
    + + + + + + + + + + + + + + + + + + + + + + +
    Field.mode
    DescriptionFlag to hold the mode of the probe
    TypeMandatory
    Range SOT, EOT, Edge, Continuous, OnChaos
    NotesThe .mode supports five modes of probes. It can one of the SOT, EOT, Edge, Continuous, OnChaos
    + + + + + + + + + + + + + + + + + + + + + + +
    Field.data
    DescriptionFlag to hold the data for the create operation of the k8sProbe
    TypeOptional
    Rangen/a type: string
    NotesThe .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
    DescriptionFlag to hold the group of the kubernetes resource for the k8sProbe
    TypeMandatory
    Range n/a type: string
    NotesThe .k8sProbe/inputs.group contains group of the kubernetes resource on which k8sProbe performs the specified operation
    + + + + + + + + + + + + + + + + + + + + + + +
    Field.k8sProbe/inputs.version
    DescriptionFlag to hold the apiVersion of the kubernetes resource for the k8sProbe
    TypeMandatory
    Range n/a type: string
    NotesThe .k8sProbe/inputs.version contains apiVersion of the kubernetes resource on which k8sProbe performs the specified operation
    + + + + + + + + + + + + + + + + + + + + + + +
    Field.k8sProbe/inputs.resource
    DescriptionFlag to hold the kubernetes resource name for the k8sProbe
    TypeMandatory
    Range n/a type: string
    NotesThe .k8sProbe/inputs.resource contains the kubernetes resource name on which k8sProbe performs the specified operation
    + + + + + + + + + + + + + + + + + + + + + + +
    Field.k8sProbe/inputs.namespace
    DescriptionFlag to hold the namespace of the kubernetes resource for the k8sProbe
    TypeMandatory
    Range n/a type: string
    NotesThe .k8sProbe/inputs.namespace contains namespace of the kubernetes resource on which k8sProbe performs the specified operation
    + + + + + + + + + + + + + + + + + + + + + + +
    Field.k8sProbe/inputs.fieldSelector
    DescriptionFlag to hold the fieldSelectors of the kubernetes resource for the k8sProbe
    TypeOptional
    Range n/a type: string
    NotesThe .k8sProbe/inputs.fieldSelector contains fieldSelector to derived the kubernetes resource on which k8sProbe performs the specified operation
    + + + + + + + + + + + + + + + + + + + + + + +
    Field.k8sProbe/inputs.labelSelector
    DescriptionFlag to hold the labelSelectors of the kubernetes resource for the k8sProbe
    TypeOptional
    Range n/a type: string
    NotesThe .k8sProbe/inputs.labelSelector contains labelSelector to derived the kubernetes resource on which k8sProbe performs the specified operation
    + + + + + + + + + + + + + + + + + + + + + + +
    Field.k8sProbe/inputs.operation
    DescriptionFlag to hold the operation type for the k8sProbe
    TypeMandatory
    Rangecreate, delete, present, absent
    NotesThe .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
    DescriptionFlag to hold the command for the cmdProbe
    TypeMandatory
    Rangen/a type: string
    NotesThe .cmdProbe/inputs.command contains the shell command, which should be run as part of cmdProbe
    + + + + + + + + + + + + + + + + + + + + + + +
    Field.cmdProbe/inputs.source.image
    DescriptionFlag to hold the image for the cmdProbe
    TypeOptional
    Rangeany source docker image
    NotesThe .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
    DescriptionFlag to allow or deny the .cmdProbe/inputs.source.image access to the node network namespace
    TypeOptional
    Rangetrue, false
    NotesThe .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
    DescriptionFlag to hold the URL for the httpProbe
    TypeMandatory
    Range n/a type: string
    NotesThe .httpProbe/inputs.url contains the URL which the fault uses to gauge health/service availability (or other custom conditions) as part of the entry/exit criteria.
    + + + + + + + + + + + + + + + + + + + + + + +
    Field.httpProbe/inputs.insecureSkipVerify
    DescriptionFlag to hold the flag to skip certificate checks for the httpProbe
    TypeOptional
    Range true, false
    NotesThe .httpProbe/inputs.insecureSkipVerify contains flag to skip certificate checks.
    + + + + + + + + + + + + + + + + + + + + + + +
    Field.httpProbe/inputs.responseTimeout
    DescriptionFlag to hold the flag to response timeout for the httpProbe
    TypeOptional
    Range n/a type: integer
    NotesThe .httpProbe/inputs.responseTimeout contains flag to provide the response timeout for the http Get/Post request.
    + + + + + + + + + + + + + + + + + + + + + + +
    Field.httpProbe/inputs.method.get.criteria
    DescriptionFlag to hold the criteria for the http get request
    TypeMandatory
    Range ==, !=, oneOf
    NotesThe .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
    DescriptionFlag to hold the expected response code for the get request
    TypeMandatory
    Range HTTP_RESPONSE_CODE
    NotesThe .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
    DescriptionFlag to hold the content type of the post request
    TypeMandatory
    Range n/a type: string
    NotesThe .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
    DescriptionFlag to hold the body of the http post request
    TypeMandatory
    Range n/a type: string
    NotesThe .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
    DescriptionFlag to hold the path of the http body, required for the http post request
    TypeOptional
    Range n/a type: string
    NotesThe .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 fault pod via a ConfigMap resource, with the ConfigMap name being defined in the ChaosEngine OR the ChaosExperiment CR.
    + + + + + + + + + + + + + + + + + + + + + + +
    Field.httpProbe/inputs.method.post.criteria
    DescriptionFlag to hold the criteria for the http post request
    TypeMandatory
    Range ==, !=, oneOf
    NotesThe .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
    DescriptionFlag to hold the expected response code for the post request
    TypeMandatory
    Range HTTP_RESPONSE_CODE
    NotesThe .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
    DescriptionFlag to hold the prometheus endpoints for the promProbe
    TypeMandatory
    Range n/a type: string
    NotesThe .promProbe/inputs.endpoint contains the prometheus endpoints
    + + + + + + + + + + + + + + + + + + + + + + +
    Field.promProbe/inputs.query
    DescriptionFlag to hold the promql query for the promProbe
    TypeMandatory
    Range n/a type: string
    NotesThe .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
    DescriptionFlag to hold the path of the promql query for the promProbe
    TypeOptional
    Range n/a type: string
    NotesThe .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 fault pod via a ConfigMap resource, with the ConfigMap name being defined in the ChaosEngine OR the ChaosExperiment CR.
    + +### Runproperties + + + + + + + + + + + + + + + + + + + + + + +
    Field.runProperties.probeTimeout
    DescriptionFlag to hold the timeout for the probes
    TypeMandatory
    Rangen/a type: string
    NotesThe .runProperties.probeTimeout represents the time limit for the probe to execute the specified check and return the expected data
    + + + + + + + + + + + + + + + + + + + + + + +
    Field.runProperties.retry
    DescriptionFlag to hold the retry count for the probes
    TypeMandatory
    Rangen/a type: integer
    NotesThe .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
    DescriptionFlag to hold the interval for the probes
    TypeMandatory
    Rangen/a type: string
    NotesThe .runProperties.interval contains the interval for which probes waits between subsequent retries
    + + + + + + + + + + + + + + + + + + + + + + +
    Field.runProperties.probePollingInterval
    DescriptionFlag to hold the polling interval for the probes(applicable for Continuous mode only)
    TypeOptional
    Rangen/a type: string
    NotesThe .runProperties.probePollingInterval contains the time interval for which continuous probe should be sleep after each iteration
    + + + + + + + + + + + + + + + + + + + + + + +
    Field.runProperties.initialDelay
    DescriptionFlag to hold the initial delay interval for the probes
    TypeOptional
    Rangen/a type: string
    NotesThe .runProperties.initialDelaySeconds represents the initial waiting time interval for the probes.
    + + + + + + + + + + + + + + + + + + + + + + +
    Field.runProperties.stopOnFailure
    Description Flags to hold the stop or continue the fault on probe failure
    TypeOptional
    Rangefalse type: boolean
    NotesThe .runProperties.stopOnFailure can be set to true/false to stop or continue the fault execution after probe fails
    + +### Comparator + + + + + + + + + + + + + + + + + + + + + + +
    Fieldtype
    DescriptionFlag to hold type of the data used for comparision
    TypeMandatory
    Range string, int, float
    NotesThe type contains type of data, which should be compare as part of comparision operation
    + + + + + + + + + + + + + + + + + + + + + + +
    Fieldcriteria
    DescriptionFlag to hold criteria for the comparision
    TypeMandatory
    Range it supports {`>=, <=, ==, >, <, !=, oneOf, between`} for int & float type. And equal, notEqual, contains, matches, notMatches, oneOf for string type.
    NotesThe criteria contains criteria of the comparision, which should be fulfill as part of comparision operation.
    + + + + + + + + + + + + + + + + + + + + + + +
    Fieldvalue
    DescriptionFlag to hold value for the comparision
    TypeMandatory
    Range n/a type: string
    NotesThe value contains value of the comparision, which should follow the given criteria as part of comparision operation.
    + +## 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 fault 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 faults 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 fault depends purely on the order in which they are defined in the ChaosEngine. + +:::note +With the latest release of LitmusChaos 3.0.0: + +
  • The term Chaos Experiment has been changed to Chaos Fault.
  • +
  • The term Chaos Scenario/Workflow has been changed to Chaos Experiment.
  • +::: + +## Learn more + +- [Explore the Custom Resources](glossary.md) diff --git a/website/versioned_docs/version-3.9.2/concepts/projects.md b/website/versioned_docs/version-3.9.2/concepts/projects.md new file mode 100644 index 00000000..548cb9b7 --- /dev/null +++ b/website/versioned_docs/version-3.9.2/concepts/projects.md @@ -0,0 +1,35 @@ +--- +id: projects +title: Projects +sidebar_label: Projects +--- + +--- + +The ChaosCenter comes with a project management system that can be used for working on chaos experiments with multiple different projects across different chaos infrastructures. + +## Prerequisites + +Before learning about the concept of projects, it is important to note that a project signifies a separation between Chaos infrastructures, Schedules, [Visualization](visualize-experiment.md), and Teams (discussed in the next section) configurations, and prior knowledge of these will prove fruitful in understanding the concept of projects in-depth. + +## 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-3.9.2/concepts/teaming.md b/website/versioned_docs/version-3.9.2/concepts/teaming.md new file mode 100644 index 00000000..9515905f --- /dev/null +++ b/website/versioned_docs/version-3.9.2/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 + +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 `Executor`, 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 create resources such as infrastructures, probes, hubs, experiments, etc, schedule chaos experiments, update and delete chaos experiments.They have both create and execute perimissions. +- **Executor:** Members invited with the executor role only have execute and view permissions which allow them to run/stop experiments, use probes etc, they don't have any create/delete permissions. +- **Viewer:** Members having a viewer role can only view the analytics related to the chaos experiments and the chaos experiments themselves, but are not given permission to schedule chaos experiments 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 + - Executor +- 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 Executor 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-3.9.2/concepts/user-management.md b/website/versioned_docs/version-3.9.2/concepts/user-management.md new file mode 100644 index 00000000..f339c178 --- /dev/null +++ b/website/versioned_docs/version-3.9.2/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 + +ChaosCenter supports two portal level roles for defining the privilege levels of a certain user: + +**Admin:** The admin user is created by default upon setup and can be used for logging in to the ChaosCenter using the credentials once the server pod (auth container) is up. + +**Non-admin users:** The admin of the ChaosCenter can exclusively create any number of non-admin users. + +## Role privileges + +**Admin:** It is the highest privilege role offered in the ChaosCenter which provides complete access to all the features. + +**Non-admin users:** Non-admin users get all the same privileges as an admin-level user, with the exception of the user management feature which is an admin-exclusive feature to facilitate an admin to manage their teams on the ChaosCenter. For example, in an organization there can be different teams who'd utilize different chaos infrastructures that have no layover between each other. + +## Learn more + +- [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-3.9.2/concepts/visualize-experiment.md b/website/versioned_docs/version-3.9.2/concepts/visualize-experiment.md new file mode 100644 index 00000000..be2c02fe --- /dev/null +++ b/website/versioned_docs/version-3.9.2/concepts/visualize-experiment.md @@ -0,0 +1,41 @@ +--- +id: visualize-experiment +title: Visualize chaos experiment +sidebar_label: Visualize chaos experiment +--- + +--- + +Visualization is an important aspect while doing chaos engineering. It allows the user to discover and inspect different changes that occur during a Chaos Experiment execution. With ChaosCenter, the real-time data and status of the chaos experiments can be observed. Valuable information like pod logs, chaos experiment status, and chaos results can also be viewed. + +## Prerequisites + +The following is required before visualizing a chaos experiment: + +- ChaosCenter +- [Chaos Experiments](chaos-workflow.md) + +## Create chaos experiment + +If the user chooses to **Save** and **Run** the experiment, they will be directed to the experiment execution page, where the experiment can be visualized. Otherwise, they will be taken to the chaos experiment page. + +## Visualize chaos experiment + +To observe a chaos experiment, user needs to select the highlighted experiment run box from the heatmap, it will redirect to experiment run execution page. + + +In the chaos experiment, a realtime graph of the chaos experiment is displayed. This graph contains valuable information regarding the status of individual steps of the chaos experiment. + +To view the details of each step, the user can click on the individual nodes and the right side pane will display the node details, results(once the execution is complete), and the logs related to it. +

    + + + +## Summary + +After scheduling a chaos experiment, a user can view the details of the running chaos experiment from the ChaosCenter. ChaosCenter provides a real-time graph that is used to visualize the chaos experiment and get the details of individual steps of the chaos experiment. Important details like the logs and target applications can be viewed from ChaosCenter. Once the chaos experiment execution is completed, the resiliency score is calculated and the ChaosResult for the ChaosEngine pods is available. + +## Learn More + +- [Explore Probes](probes.md) +- [What is a Chaos Experiment](chaos-workflow.md) diff --git a/website/versioned_docs/version-3.9.2/faq.md b/website/versioned_docs/version-3.9.2/faq.md new file mode 100644 index 00000000..3586151c --- /dev/null +++ b/website/versioned_docs/version-3.9.2/faq.md @@ -0,0 +1,99 @@ +--- +id: faq +title: FAQ +sidebar_label: FAQ +--- + +--- + +## Installation + +### 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 Chaoscenter-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. + +### What is the minimum system requirement to run Chaoscenter and chaos infrastructure together? + +To run Chaoscenter you need to have a minimum of 1 GiB memory and 1 core of CPU free. + +### 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. + +### Does Litmus 3.0 support backward compatibility with Litmus 2.0? + +No, LitmusChaos 3.0.0 is not backward compatible with LitmusChaos 2.0.0. + +### Can I run LitmusChaos Outside of my Kubernetes clusters? + +Yes, you can run the ansible faults 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. + +## Chaos Experiment + +### What does failed status of chaos experiment means in LitmusPortal? + +Failed status indicates that either there is some misconfiguration in the chaos experiment or the default hypothesis of fault was disproved and some of the faults in the chaos experiment failed, In such case the resiliency score will be less than 100. + +### How is resilience score calculated? + +The Resilience score is calculated on the basis of the weightage and the Probe Success Percentage of the fault. Resilience for one single fault is the multiplication of the weight given to that fault and the Probe Success Percentage. Then we get the total test result by adding the resilience score of all the faults. The Final Resilience Score is calculated by dividing the total test result by the sum of the weights of all the faults combined in the single chaos experiment. For more detail refer to [this blog](https://dev.to/litmus-chaos/how-the-resilience-score-algorithm-works-in-litmus-1d22). + +## Chaoshub + +### How can I setup chaoshub of my own gitlab repo in Chaoscenter? + +In the Chaoscenter 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 Chaoscenter and provide the GitLab URL and branch name along with the access token. After submitting, your own chaos hub is connected to the Chaoscenter. +For the SSH key, click on the SSH and it will generate a public key. You shall use this public key and put it in your GitLab account. Just go to the settings of GitLab, and 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 Chaoscenter along with the branch. After submitting, your own ChaosHub is connected to the Chaoscenter. + +## Gitops + +### How can users integrate Litmuschaos in their environment with Gitops? + +Gitops feature in Litmus enables users to sync chaos experiments from a configured git repo, any chaos experiment inserts/updates made to the repo will be monitored and picked up by ChaosCenter and will be executed on the target cluster. ChaosCenter 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 experiments can be triggered automatically. This integrates with other gitops tools like flux/argo cd and enables users to automatically run chaos experiments 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 experiments created will be stored in the configured repo in the path `litmus//.yaml`. + +## Litmusctl + +### Does Litmusctl support actions that are currently performed from the portal dashboard? + +Yes, Chaos Infrastructure connection, creation and chaos experiment execution are now being supported in Litmusctl. [documentation of litmusctl](https://github.com/litmuschaos/litmusctl/blob/master/Usage_0.23.0.md). + +### 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. + +## Usage + +### Can I use Litmus in Production? + +Yes, you can use Litmuschaos in production. Litmus has a wide variety of faults 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 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. diff --git a/website/versioned_docs/version-3.9.2/getting-started/installation.md b/website/versioned_docs/version-3.9.2/getting-started/installation.md new file mode 100644 index 00000000..123a1842 --- /dev/null +++ b/website/versioned_docs/version-3.9.2/getting-started/installation.md @@ -0,0 +1,261 @@ +--- +id: installation +title: ChaosCenter installation +sidebar_label: Installation +--- + +--- + +## Prerequisites + +- 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://app.harness.io/auth/#/signin). 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: +
  • Helm3 chart
  • +
  • Kubectl yaml spec file
  • +
    + 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 Experiments 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 infrastructure. +

    + To get started with Harness Chaos Engineering SaaS, visit Harness Chaos Engineering SaaS and register for free. You can skip the below installation steps. +
    +
    + +:::note +With 3.9.0 release, Cluster scope installation is deprecated. Now Namespaced mode is the only supported and standard installation mode. +::: + +### 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`. + +- Litmus helm chart depends on `bitnami/mongodb` [helm chart](https://github.com/bitnami/charts/tree/main/bitnami/mongodb), which uses a mongodb image not supported on ARM. If you want to install Litmus on an ARM-based server, please replace the default one with your custom mongodb arm image as shown below. + + ```bash + helm install chaos litmuschaos/litmus --namespace=litmus \ + --set portal.frontend.service.type=NodePort \ + --set mongodb.image.registry= \ + --set mongodb.image.repository= \ + --set mongodb.image.tag= + ``` + +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** + +In this method the users need to install mongo first via helm and then apply the installation manifest. Follow the instructions [here](https://github.com/litmuschaos/litmus/tree/master/chaoscenter#installation-steps-for-litmus-300-beta9). + +### **Install mongo** + +```bash + helm repo add bitnami https://charts.bitnami.com/bitnami +``` + +Mongo Values + +```bash +auth: + enabled: true + rootPassword: "1234" + # -- existingSecret Existing secret with MongoDB(®) credentials (keys: `mongodb-passwords`, `mongodb-root-password`, `mongodb-metrics-password`, ` mongodb-replica-set-key`) + existingSecret: "" +architecture: replicaset +replicaCount: 3 +persistence: + enabled: true +volumePermissions: + enabled: true +metrics: + enabled: false + prometheusRule: + enabled: false + +# bitnami/mongodb is not yet supported on ARM. +# Using unofficial tools to build bitnami/mongodb (arm64 support) +# more info: https://github.com/ZCube/bitnami-compat +#image: +# registry: ghcr.io/zcube +# repository: bitnami-compat/mongodb +# tag: 6.0.5 +``` + +```bash +helm install my-release bitnami/mongodb --values mongo-values.yml -n --create-namespace +``` + +Litmus supports for HTTP and HTTPS mode of installation. + +### Basic installation (HTTP based and allows all origins) + +Applying the manifest file will install all the required service account configuration and ChaosCenter in namespaced scope. + +```bash + kubectl apply -f https://raw.githubusercontent.com/litmuschaos/litmus/3.9.2/chaoscenter/manifests/litmus-getting-started.yaml -n +``` + +### Advanced installation (HTTPS based and CORS rules apply) + +For advanced installation visit [here](../user-guides/chaoscenter-advanced-installation.md) + +--- + +## **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 + litmusportal-frontend-55974fcf59-cxxrf 1/1 Running 0 58s + my-release-mongodb-0 1/1 Running 0 63s + my-release-mongodb-1 1/1 Running 0 63s + my-release-mongodb-2 1/1 Running 0 62s + my-release-mongodb-arbiter-0 1/1 Running 0 64s + + ``` + +- 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 + chaos-exporter ClusterIP 10.68.45.7 8080/TCP 23h + litmusportal-auth-server-service NodePort 10.68.34.91 9003:32368/TCP,3030:31051/TCP 23h + litmusportal-frontend-service NodePort 10.68.43.68 9091:30070/TCP 23h + litmusportal-server-service NodePort 10.68.33.242 9002:32455/TCP,8000:30722/TCP 23h + my-release-mongodb-arbiter-headless ClusterIP None 27017/TCP 23h + my-release-mongodb-headless ClusterIP None 27017/TCP 23h + workflow-controller-metrics ClusterIP 10.68.33.65 9090/TCP 23h + ``` + +--- + +## **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 `31846`. 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:31846/ +``` + +> Where `172.17.0.3` is my NodeIP and `31846` 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) + +**NOTE:** With advanced installation CORS rules are applied, once manifest is applied frontend loadbalancer IP needs to be added in the `ALLOWED_ORIGINS` environment in both auth and graphql server deployment. + +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 + +- [Install ChaosCenter with HTTPS](../user-guides/chaoscenter-advanced-installation.md) +- [Connect External Chaos Infrastructures to ChaosCenter](../user-guides/chaos-infrastructure-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-3.9.2/getting-started/resources.md b/website/versioned_docs/version-3.9.2/getting-started/resources.md new file mode 100644 index 00000000..4a686853 --- /dev/null +++ b/website/versioned_docs/version-3.9.2/getting-started/resources.md @@ -0,0 +1,39 @@ +--- +id: resources +title: Resources +sidebar_label: Resources +--- + +--- + +## ChaosCenter +ChaosCenter is a unified pane that controls all the functions provided by Litmus. It can be used for managing the entire lifecycle of the chaos experiments, including all the components within. + +ChaosCenter comes pre-packaged as a part of LitmusChaos installation and can be easily accessed via [Ingress](../user-guides/setup-with-ingress.md), [NodePort](../user-guides/setup-without-ingress.md#with-nodeport) or [LoadBalancer](../user-guides/setup-without-ingress.md#with-loadbalancer). Since Litmus has Cross-Cloud support, you get seamless access to the ChaosCenter irrespectively of where you deploy it. + +ChaosCenter gives you access to a plethora of features, the major ones include: + +- **Chaos experiment creation** + - From templates, custom experiments from scratch (using ChaosHubs), from pre-created YAMLs + - Experiments sequence control (parallel as well as sequential steps creation) + - Creation of either singular or cron experiments as schedules + - Attaching priority to experiments based on your use cases +- **Users and teams** + - Creation of users with Role Based Access Control + - Creating a team of multiple users + - Authenticating users +- **Chaos experiment management** + - Rolling out automated changes using GitOps + - Allowing image addition from custom image server (both public and private) + - Measure and analyze the Resilience Score of each chaos scenario + +## Chaos Infrastructures +Chaos infrastructure is a service that runs in your target environment and aids Litmus in accessing and injecting chaos to your target environment. There should always be at least one or more than one chaos infrastructure connected to the ChaosCenter to execute an experiment. + +## Types of Chaos Infrastructures + +In Litmus, chaos infrastructures can be classified into two types: + +- **Self Chaos Infrastructures:** A Chaos Infrastructure that is connected to the same cluster and namespace where the ChaosCenter is deployed. It can be used to target the workloads executing on that cluster only. + +- **External Chaos Infrastructures:** A Chaos Infrastructure that is connected to a remote Kubernetes cluster. ChaosCenter can be operated in a cross-cloud manner, which allows connecting multiple External Chaos Infrastructure to the same ChaosCenter with the help of the [litmusctl](../litmusctl/installation.md) CLI. Once connected you can manage, monitor, observe and induce chaos from the ChaosCenter to the respective External Chaos Infrastructures. diff --git a/website/versioned_docs/version-3.9.2/glossary.md b/website/versioned_docs/version-3.9.2/glossary.md new file mode 100644 index 00000000..2f99bc29 --- /dev/null +++ b/website/versioned_docs/version-3.9.2/glossary.md @@ -0,0 +1,59 @@ +--- +id: glossary +title: Glossary +sidebar_label: Glossary +--- + +:::note +Please note that Litmus 3.0 is not backward compatible and will require a fresh installation for users looking to migrate from previous versions +::: + +## Chaos Resources + +At the heart of the Litmus Platform are the chaos custom resources. This section consists of the specification (details of each field within the .spec & .status of the resources) as well as standard examples for tuning the supported parameters. + + + + + + + + + + + + + + + + + + + + + + +
    Chaos Resource NameDescriptionUser Guides
    ChaosEngineContains the ChaosEngine specifications user-guideChaosEngine
    ChaosExperimentContains the ChaosExperiment specifications user-guideChaosExperiment
    ChaosResultContains the ChaosResult specifications user-guideChaosResult
    + +## Terminology Changes + +With the latest release of LitmusChaos 3.0.0 the following terminologies have been changed: + + + + + + + + + + + + + + + + + + +
    Old terminologyUpdated terminology
    Chaos ExperimentChaos Fault
    Chaos Scenario/WorkflowChaos Experiment
    Chaos Delegate/AgentChaos Infrastructure
    diff --git a/website/versioned_docs/version-3.9.2/integrations/backstage.md b/website/versioned_docs/version-3.9.2/integrations/backstage.md new file mode 100644 index 00000000..92bbf335 --- /dev/null +++ b/website/versioned_docs/version-3.9.2/integrations/backstage.md @@ -0,0 +1,115 @@ +--- +id: backstage +title: Manage all components of Litmus in one place +sidebar_label: Backstage +--- + +--- + +[Backstage](https://backstage.io) is an open platform for building developer portals and is one of the most popular CNCF projects. It allows developers to manage cloud-native applications' numerous services and codes from a single point. Chaos engineering can verify an application's resilience. It gives you the opportunity to identify various vulnerabilities in your application. Therefore, having information about Litmus chaos experiments alongside other application elements, such as application code, and CI/CD pipeline information, is highly beneficial to developers. + +## Features + +### EntityLitmusCard + +- See the number and status of your experiments in a graph. +- See representative information about Litmus (number of Chaos Hubs, GitOps status, etc.). +- Provide a direct link to Litmus. + +![EntityLitmusCard](https://raw.githubusercontent.com/litmuschaos/backstage-plugin/master/docs/EntityLitmusCard.png) + +### EntityLitmusContent + +- The `Dev Info` section provides a number of useful links related to Litmus. +- The `Chaos Hubs` section provides information about the Chaos Hubs registered with Litmus. + - Clicking on each item will redirect you to that item's detailed page. +- The `Environments` section provides information about the environments and infrastructures registered with Litmus. + - Clicking on each item will redirect you to that item's detailed page. +- The `Experiments` section offers details on the Chaos Experiments that were created within the platform. + - If you hover over 'RECENT EXPERIMENT RUNS', you can view detailed information about the experiments including resiliency score and status. + - We can directly launch chaos experiments by clicking the play button. + +![EntityLitmusContent](https://raw.githubusercontent.com/litmuschaos/backstage-plugin/master/docs/EntityLitmusContent.png) + +## Before you begin + +- Compatible only with Litmus version [3.0.0](https://github.com/litmuschaos/litmus/releases/tag/3.0.0) or later. + +## Getting started + +1. In the `./packages/app` project add the plugin. + + ```yaml + yarn add backstage-plugin-litmus + ``` + +2. Get Litmus API Token through the Litmus UI + + 1. Click "SETTINGS" in the sidebar. + 2. Click "+ New Token" Button in the 'API Tokens' section. + ![settings_tab](https://raw.githubusercontent.com/litmuschaos/backstage-plugin/master/docs/settings_tab.png) + 3. Enter your information and click "Confirm". + ![create_dialog](https://raw.githubusercontent.com/litmuschaos/backstage-plugin/master/docs/create_dialog.png) + 4. Get the token in the "VALUE" column. + +3. In the `app-config.yaml` file root directory, add litmus proxy and info like below + ```yaml + proxy: + '/litmus': + target: 'your-own-litmus-ui-url' + changeOrigin: true + headers: + Authorization: 'Bearer ${LITMUS_AUTH_TOKEN}' + litmus: + baseUrl: 'your-own-litmus-ui-url' + apiToken: ${LITMUS_AUTH_TOKEN} + ``` +4. Add your auth key to the environmental variables + ```shell + export LITMUS_AUTH_TOKEN="your-own-token" + ``` +5. Adding annotations and values to your component file. + ```yaml + apiVersion: backstage.io/v1alpha1 + kind: Component + metadata: + name: component-name + description: 'description' + annotations: + litmuschaos.io/project-id: 'your-own-project-id' + ``` +6. Enabling frontend + + ```ts + // packages/app/src/components/catalog/EntityPage.tsx + import { isLitmusAvailable, EntityLitmusCard, EntityLitmusContent } from 'backstage-plugin-litmus' + // ... + const overviewContent = ( + + // ... + + + + + + + + // ... + + ) + // ... + const serviceEntityPage = ( + + // ... + + + + // ... + + ) + ``` + +## Resources + +- [GitHub](https://github.com/litmuschaos/backstage-plugin) +- [npm](https://www.npmjs.com/package/backstage-plugin-litmus) diff --git a/website/versioned_docs/version-3.9.2/integrations/grafana.md b/website/versioned_docs/version-3.9.2/integrations/grafana.md new file mode 100644 index 00000000..af717f1a --- /dev/null +++ b/website/versioned_docs/version-3.9.2/integrations/grafana.md @@ -0,0 +1,271 @@ +--- +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: + +- [Prometheus TSDB](https://prometheus.io/) +- [Prometheus Integration](prometheus.md) + +## Grafana setup with provisioned data source and 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: + +![image](https://github.com/litmuschaos/litmus/blob/master/monitoring/screenshots/sock-shop/chaos-result-selector.png?raw=true) + +#### Chaos Engine Context (Target application's NAMESPACE_LABEL) selector dropdown: + +![image](https://github.com/litmuschaos/litmus/blob/master/monitoring/screenshots/sock-shop/chaos-engine-context-selector.png?raw=true) + +#### Chaos Engines with Experiments as Chaos Results: + +![image](https://github.com/litmuschaos/litmus/blob/master/monitoring/screenshots/sock-shop/chaos-experiments.png?raw=true) + +#### Chaos event annotations: + +![image](https://github.com/litmuschaos/litmus/blob/master/monitoring/screenshots/sock-shop/chaos-event-annotation.png?raw=true) + +#### Chaos Result verdict annotations: + +![image](https://github.com/litmuschaos/litmus/blob/master/monitoring/screenshots/sock-shop/chaos-result-verdict-annotation.png?raw=true) + +#### Interleaved Chaos events: + +![image](https://github.com/litmuschaos/litmus/blob/master/monitoring/screenshots/sock-shop/interleaved-events.png?raw=true) + +#### Interleaved Chaos Result verdicts: + +![image](https://github.com/litmuschaos/litmus/blob/master/monitoring/screenshots/sock-shop/interleaved-results.png?raw=true) + +#### Chaos Result verdict failure alerts: + +![image](https://github.com/litmuschaos/litmus/blob/master/monitoring/screenshots/sock-shop/verdict-failure-alert.png?raw=true) + +#### Chaos Result probe failure alerts: + +![image](https://github.com/litmuschaos/litmus/blob/master/monitoring/screenshots/sock-shop/probe-failure-alert.png?raw=true) + +#### Systems healthy / in steady state OR no alerts to be issued: + +![image](https://github.com/litmuschaos/litmus/blob/master/monitoring/screenshots/sock-shop/no-alerts-issued.png?raw=true) + +#### Systems un-healthy / failed to regain steady state after chaos / meet SLO OR alerts are issued: + +![image](https://github.com/litmuschaos/litmus/blob/master/monitoring/screenshots/sock-shop/alerts-active.png?raw=true) + +#### Alerts issued: + +![image](https://github.com/litmuschaos/litmus/blob/master/monitoring/screenshots/sock-shop/alerts-sent.png?raw=true) + +## 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 + +- [Observability Setup](../user-guides/observability-set-up.md) diff --git a/website/versioned_docs/version-3.9.2/integrations/prometheus.md b/website/versioned_docs/version-3.9.2/integrations/prometheus.md new file mode 100644 index 00000000..c0d370d5 --- /dev/null +++ b/website/versioned_docs/version-3.9.2/integrations/prometheus.md @@ -0,0 +1,203 @@ +--- +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: + +- [Prometheus TSDB](https://prometheus.io/) +- [Probes](../concepts/probes.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 + +- [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-3.9.2/introduction/community.md b/website/versioned_docs/version-3.9.2/introduction/community.md new file mode 100644 index 00000000..2eaa655e --- /dev/null +++ b/website/versioned_docs/version-3.9.2/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. + + + + + + +
    + + +
    +
    + Community Sync Up +
    +
    + Meet and learn from the maintainers, contributors and developers of Litmus, everything about Chaos Engineering +
    +
    +
    + + +
    +
    + Kubernetes Chaos Engineering Meetup +
    +
    + Discussion about the best practices and tutorials for practicing Chaos Engineering +
    +
    +
    + +## 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-3.9.2/introduction/core-principles.md b/website/versioned_docs/version-3.9.2/introduction/core-principles.md new file mode 100644 index 00000000..ca27a9d5 --- /dev/null +++ b/website/versioned_docs/version-3.9.2/introduction/core-principles.md @@ -0,0 +1,35 @@ +--- +id: core-principles +title: Core principles of Litmus +sidebar_label: Core principles +--- + +--- + +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-3.9.2/introduction/features.md b/website/versioned_docs/version-3.9.2/introduction/features.md new file mode 100644 index 00000000..55caa812 --- /dev/null +++ b/website/versioned_docs/version-3.9.2/introduction/features.md @@ -0,0 +1,77 @@ +--- +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). + +LitmusChaos 3.0 brings a significant overhaul to its user experience, adopting a more streamlined UI for a simplified and user-friendly experience. It introduces Environments enabling users to efficiently organize their chaos infrastructures. The new Chaos Studio simplifies the process of fine-tuning chaos experiments, enhancing user capabilities. Additionally, it includes support for Resilience Probes for simplifying the management of Litmus probes. Finally, it extends compatibility to Mongo Replicas, which can be easily installed via Helm with Bitnami Mongo. + +## Advantages of Litmus 3.0 + +Here's a summary of the major highlights of LitmusChaos 3.0: +- **Redefined User Experience** + - Complete transformation of the user interface (UI) for a sleek and intuitive experience. + - Leveraging the Harness UIcore library to provide an even smoother user journey. + +- **Introduction to Environments** + - Empowers users to efficiently manage their Chaos Infrastructures. + - Helps categorize and compartmentalize chaos experiments for better organization and collaboration. + +- **Chaos Studio** + - Simplifies the adjustment of chaos parameters and configurations. + - Eliminates complex setup procedures, making chaos engineering more accessible to all users. + - Streamlines the process of fine-tuning chaos experiments. + +- **Resilience Probes** + - Resilience probes now support a plug-and-play architecture. + - Users can create probes once and utilize them repeatedly across various experiments. + - Comprehensive support for steady-state validation enhances system resilience. + - Helps users assess the robustness of their applications more effectively. + +- **MongoDB High Availability Support** + - Users can now install MongoDB Replicas via Helm using Bitnami Mongo. + - Seamless integration of chaos engineering into MongoDB infrastructure. + - Uncover weaknesses and improve the overall reliability of MongoDB setups. + +- **Terminology Changes** + - A refinement of terminology for improved clarity and consistency. + - **Chaos Agents/Delegates** are now referred to as **Chaos Infrastructures**. + - **Chaos Scenarios/Workflows** have been simplified to **Chaos Experiments**. + - **Chaos Experiments** are now called **Chaos Faults**. + +- **API Refactoring and Enhanced Code Architecture** + - Under-the-hood refactors and improvements in code architecture. + - Addition of backend unit tests to enhance code reliability. + - These technical enhancements make it easier for developers to contribute to the LitmusChaos ecosystem. + - Improved code quality and maintainability for the project. + +Litmus itself is composed of microservices. And we made sure that by adding the above features for 3.0, seamlessly integrates the additional microservices in conjunction with the existing one. Litmus 3.0 is completely backwards compatible. No features are deprecated. + +The migration path is about constructing new artifacts such as Chaos Experiments that include the current chaos experiments in use by the users. + +## Feature revision across Litmus 1.x, 2.x and 3.0 + +Litmus 3.0 culminates as well as enhances the features rolled-out through Litmus 1.x and 2.x. Below is a bird's eye view of all the enhancements made through the three major releases: + +| Litmus 1.x | Litmus 2.x | Litmus 3.0 | +| -------------------- | ------------------------------------- | -------------------------- | +| Experiments | Chaos Experiments | Revamped and simplified UX | +| Per user | Teams (Multi Tenant) | Environments | +| Per cluster | Per organisation (Cross Cloud) | Chaos Studio | +| Only Public ChaosHub | Public and Private ChaosHubs | Resilience probes | +| CLI only | CLI and GUI | Mongo DB Replicas | +| | GitOps | Refactored APIs | +| | Scalability | | +| | Integrated and Interleaved monitoring | | + +## Learn more +- [Install Litmus](../getting-started/installation.md) +- [Visualize Chaos Experiments](../concepts/visualize-experiment.md) +- Chaos Schedule +- [View the different User Guides](../user-guides/overview.md) diff --git a/website/versioned_docs/version-3.9.2/introduction/other-links.md b/website/versioned_docs/version-3.9.2/introduction/other-links.md new file mode 100644 index 00000000..060b5636 --- /dev/null +++ b/website/versioned_docs/version-3.9.2/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-3.9.2/introduction/usage.md b/website/versioned_docs/version-3.9.2/introduction/usage.md new file mode 100644 index 00000000..96117562 --- /dev/null +++ b/website/versioned_docs/version-3.9.2/introduction/usage.md @@ -0,0 +1,32 @@ +--- +id: usage +title: Uses of Litmus +sidebar_label: Uses of Litmus +--- + +--- + +Chaos experiments 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. + +Chaos Testing in DevOps Cycle + +## 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 + +Chaos Engineering is a culture-oriented practice. 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-3.9.2/introduction/what-is-litmus.md b/website/versioned_docs/version-3.9.2/introduction/what-is-litmus.md new file mode 100644 index 00000000..360a9241 --- /dev/null +++ b/website/versioned_docs/version-3.9.2/introduction/what-is-litmus.md @@ -0,0 +1,38 @@ +--- +id: what-is-litmus +title: What is Litmus? +sidebar_label: Litmus +--- + +--- + +Litmus Logo + +LitmusChaos is a Cloud-Native Chaos Engineering Framework with cross-cloud support. It is a CNCF Incubating 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 Kubernetes custom resources (CRs). + +## Importance of Resilience + +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-3.9.2/litmusctl/installation.md b/website/versioned_docs/version-3.9.2/litmusctl/installation.md new file mode 100644 index 00000000..2cebf580 --- /dev/null +++ b/website/versioned_docs/version-3.9.2/litmusctl/installation.md @@ -0,0 +1,180 @@ +--- +id: installation +title: Litmusctl +sidebar_label: Installation +--- + +--- + +The LitmusChaos command-line tool, litmusctl, allows you to manage litmuschaos's infrastructure plane. You can use litmusctl to connect and disconnect chaos infrastructures, create chaos experiments, 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 infrastructures. 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 0.23.0 or latest: Click here + +## Installation + +To install the latest version of litmusctl follow the below steps: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Platforms1.8.01.7.01.6.01.5.01.4.01.3.01.2.01.1.0master(Unreleased)
    litmusctl-darwin-amd64 (MacOS)Click hereClick hereClick hereClick hereClick hereClick hereClick hereClick hereClick here
    litmusctl-linux-386Click hereClick hereClick hereClick hereClick hereClick hereClick hereClick hereClick here
    litmusctl-linux-amd64Click hereClick hereClick hereClick hereClick hereClick hereClick hereClick hereClick here
    litmusctl-linux-armClick hereClick hereClick hereClick hereClick hereClick hereClick hereClick hereClick here
    litmusctl-linux-arm64Click hereClick hereClick hereClick hereClick hereClick hereClick hereClick hereClick here
    litmusctl-windows-386Click hereClick hereClick hereClick hereClick hereClick hereClick hereClick hereClick here
    litmusctl-windows-amd64Click hereClick hereClick hereClick hereClick hereClick hereClick hereClick hereClick here
    litmusctl-windows-armClick hereClick hereClick hereClick hereClick hereClick hereClick hereClick hereClick here
    + +### 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-3.9.2/litmusctl/litmusctl-usage.md b/website/versioned_docs/version-3.9.2/litmusctl/litmusctl-usage.md new file mode 100644 index 00000000..251328f2 --- /dev/null +++ b/website/versioned_docs/version-3.9.2/litmusctl/litmusctl-usage.md @@ -0,0 +1,26 @@ +--- +id: litmusctl-usage +title: Litmusctl Usage +sidebar_label: Litmusctl Usage +--- + +--- + + + + + + + + + + + + + + + + + + +
    TopicUser Guides
    Connect Chaos InfrastructureClick Here
    Create Chaos ExperimentClick Here
    Additional CommandsClick Here
    diff --git a/website/versioned_docs/version-3.9.2/troubleshooting.md b/website/versioned_docs/version-3.9.2/troubleshooting.md new file mode 100644 index 00000000..c87a0530 --- /dev/null +++ b/website/versioned_docs/version-3.9.2/troubleshooting.md @@ -0,0 +1,114 @@ +--- +id: troubleshooting +title: Troubleshooting +sidebar_label: Troubleshooting +--- + +--- + +## Installation + +### Not able to connect to the LitmusChaos 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. + +### While uninstalling Chaoscenter using helm, some components like subscriber, exporter, event, chaos scenarios, etc are not removed. + +These are chaos infrastructure components, which are launched by the control plane server, so first disconnect the chaos infrastructure from the portal then uninstall the portal using helm. + +### Unable to Install Chaoscenter 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. + +## Chaos Infrastructure + +### 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 infrastructure, 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 infrastructure. + +## Chaos Experiment + +### 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 faults part of the tune chaos experiment page. + +### The probe only accepts values in `ns, us, ms, m, s, or h`. But Why do experiments fail with `must be of type integer`? + +In the logs of the Helper pod, you may face these error logs below. + +```shell +{"mainLogs":"W1003 08:59:55.273647 1 client_config.go:552] Neither --kubeconfig nor --master was specified. Using the inClusterConfig. This might not work.\n2023/10/03 08:59:55 Error Creating Resource : ChaosEngine.litmuschaos.io 'pod-network-loss-h6srhrls' is invalid: [spec.experiments[0].spec.probe[0].runProperties.interval: Invalid value: 'string': spec.experiments[0].spec.probe[0].runProperties.interval in body must be of type integer: 'string', spec.experiments[0].spec.probe[0].runProperties.probeTimeout: Invalid value: 'string': spec.experiments[0].spec.probe[0].runProperties.probeTimeout in body must be of type integer: 'string']\n"} +``` + +It's because your cluster using old CRD manifest files. So you need to delete all Litmus' CRDs and reinstall them. The definition for CRDs can be found in the Chaos Infrastructure YAML file or at this [link](https://github.com/litmuschaos/litmus/blob/master/mkdocs/docs//litmus-portal-crds-.yml). + +## Chaoshub + +### 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 faults 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 faults directory is copied, refresh the ChaosHub page in ChaosCenter. + +## Litmusctl + +### 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-3.9.2/user-guides/accept-invite.md b/website/versioned_docs/version-3.9.2/user-guides/accept-invite.md new file mode 100644 index 00000000..6f2991db --- /dev/null +++ b/website/versioned_docs/version-3.9.2/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 invitation project name, and decide whether to accept or decline the invitation on the settings page. + + + +Once accepted, you can switch to the project using the side nav as shown below: + + diff --git a/website/versioned_docs/version-3.9.2/user-guides/account-settings.md b/website/versioned_docs/version-3.9.2/user-guides/account-settings.md new file mode 100644 index 00000000..a7c1bbee --- /dev/null +++ b/website/versioned_docs/version-3.9.2/user-guides/account-settings.md @@ -0,0 +1,54 @@ +--- +id: account-settings +title: Account Settings +sidebar_label: Account Settings +--- + +--- + +Under the account settings, you can change your personal details such as the email, name, and password. + +> Note: The username can’t be changed as it is unique. + +To navigate to the accounts page, click on the user avatar on the bottom left of the nav-bar: + +
    +avatar nav +
    + +## Edit Personal Details + +Click the edit icon to open the edit modal: + +
    +edit icon +
    + +Enter your name and your email address in the following text fields and click on the `Confirm` button to save the new details. + +
    +edit information +
    + +## Change Password + +On the same page, you can change your password by clicking on the `Change Password` button. + +
    +edit information +
    + +To update your password enter your current password as well as the new password you wish to set and click **Confirm** + +
    +edit information +
    + +> Note: If you have forgotten your password, please contact your admin to reset your password + +On successful completion, you will be logged out and asked to re-login with you new password. + +## Learn more + +- [Create a new user](create-user.md) +- [View users and their details](view-user.md) diff --git a/website/versioned_docs/version-3.9.2/user-guides/air-gapped.md b/website/versioned_docs/version-3.9.2/user-guides/air-gapped.md new file mode 100644 index 00000000..b7ec55c6 --- /dev/null +++ b/website/versioned_docs/version-3.9.2/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-3.9.2/user-guides/analyze-workflow.md b/website/versioned_docs/version-3.9.2/user-guides/analyze-workflow.md new file mode 100644 index 00000000..d2b24d6a --- /dev/null +++ b/website/versioned_docs/version-3.9.2/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-3.9.2/user-guides/change-project-name.md b/website/versioned_docs/version-3.9.2/user-guides/change-project-name.md new file mode 100644 index 00000000..4e117af6 --- /dev/null +++ b/website/versioned_docs/version-3.9.2/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 `Account setting` + +Go to the `Overview` section of settings and scroll to the `Your Projects` section: + + + +### 2. Enter edit mode + +Click options icon to open the options menu and click on the edit option (demonstrated in this example as `admin-project`) 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 on the `Confirm` button. + + + +## 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-3.9.2/user-guides/chaos-infrastructure-installation.md b/website/versioned_docs/version-3.9.2/user-guides/chaos-infrastructure-installation.md new file mode 100644 index 00000000..f80768db --- /dev/null +++ b/website/versioned_docs/version-3.9.2/user-guides/chaos-infrastructure-installation.md @@ -0,0 +1,70 @@ +--- +id: chaos-infrastructure-installation +title: Chaos Infrastructure Installation +sidebar_label: Chaos Infrastructure Installation +--- + +--- + +## Prerequisites + +- Before connecting a Chaos Infrastructure to the [ChaosCenter](../getting-started/resources.md#chaoscenter), learn about what is a [Chaos Infrastructure](../getting-started/resources.md#chaosagents) in Litmus. +- Make sure [litmusctl](../litmusctl/installation.md) is installed. + +## Connecting Chaos Infrastructure + +- Learn to [connect Chaos Infrastructure with non interactive mode using litmuctl](../litmusctl/litmusctl-usage.md) + +## Resource Requiremenets for Chaos Infrastructure 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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    PodContainerCPU(Requested)Memory(Requested)
    chaos-operator-cechaos-operator-ce25m300M
    chaos-exporterchaos-exporter25m300M
    event-trackerlitmus-event-tracker25m300M
    subscribersubscriber25m300M
    workflow-controllerworkflow-controller25m300M
    + +## 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-3.9.2/user-guides/chaoscenter-advanced-installation.md b/website/versioned_docs/version-3.9.2/user-guides/chaoscenter-advanced-installation.md new file mode 100644 index 00000000..aa95d8c3 --- /dev/null +++ b/website/versioned_docs/version-3.9.2/user-guides/chaoscenter-advanced-installation.md @@ -0,0 +1,264 @@ +--- +id: chaoscenter-advanced-installation +title: ChaosCenter Advanced Installation +sidebar_label: Setup with HTTPS +--- + +--- + +## Prerequisites + +- 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://app.harness.io/auth/#/signin). 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: +
  • Helm3 chart
  • +
  • Kubectl yaml spec file
  • +
    + 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 Experiments 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 infrastructure. +

    + To get started with Harness Chaos Engineering SaaS, visit Harness Chaos Engineering SaaS and register for free. You can skip the below installation steps. +
    +
    + +:::note +With 3.9.0 release, Cluster scope installation is deprecated. Now Namespaced mode is the only supported and standard installation mode. +::: + +### 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`. + +- Litmus helm chart depends on `bitnami/mongodb` [helm chart](https://github.com/bitnami/charts/tree/main/bitnami/mongodb), which uses a mongodb image not supported on ARM. If you want to install Litmus on an ARM-based server, please replace the default one with your custom mongodb arm image as shown below. + + ```bash + helm install chaos litmuschaos/litmus --namespace=litmus \ + --set portal.frontend.service.type=NodePort \ + --set mongodb.image.registry= \ + --set mongodb.image.repository= \ + --set mongodb.image.tag= + ``` + +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** + +In this method the users need to install mongo first via helm and then apply the installation manifest. Follow the instructions [here](https://github.com/litmuschaos/litmus/tree/master/chaoscenter#installation-steps-for-litmus-300-beta9). + +### **Install mongo** + +```bash + helm repo add bitnami https://charts.bitnami.com/bitnami +``` + +Mongo Values + +```bash + auth: + enabled: true + rootPassword: "1234" + # -- existingSecret Existing secret with MongoDB(®) credentials (keys: `mongodb-passwords`, `mongodb-root-password`, `mongodb-metrics-password`, ` mongodb-replica-set-key`) + existingSecret: "" +architecture: replicaset +replicaCount: 3 +persistence: + enabled: true +volumePermissions: + enabled: true +metrics: + enabled: false + prometheusRule: + enabled: false + +# bitnami/mongodb is not yet supported on ARM. +# Using unofficial tools to build bitnami/mongodb (arm64 support) +# more info: https://github.com/ZCube/bitnami-compat +#image: +# registry: ghcr.io/zcube +# repository: bitnami-compat/mongodb +# tag: 6.0.5 +``` + +```bash +helm install my-release bitnami/mongodb --values mongo-values.yml -n --create-namespace +``` + +Litmus supports for HTTP and HTTPS mode of installation. + +### Advanced installation (HTTPS based and CORS rules apply) + +1. Generate TLS certificates: You can provide your own certificates or can generate using [this](https://github.com/litmuschaos/litmus/blob/master/chaoscenter/mtls-helper.sh) bash script. + +2. Create secret + + ```bash + kubectl create secret generic tls-secret --from-file=ca.crt=ca.crt --from-file=tls.crt=tls.crt --from-file=tls.key=tls.key -n + ``` + +3. Applying the manifest file will install all the required service account configuration and ChaosCenter in namespaced scope. + +```bash +kubectl apply -f https://raw.githubusercontent.com/litmuschaos/litmus/3.9.2/chaoscenter/manifests/litmus-installation.yaml -n +``` + +--- + +## **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 + litmusportal-frontend-55974fcf59-cxxrf 1/1 Running 0 58s + my-release-mongodb-0 1/1 Running 0 63s + my-release-mongodb-1 1/1 Running 0 63s + my-release-mongodb-2 1/1 Running 0 62s + my-release-mongodb-arbiter-0 1/1 Running 0 64s + + ``` + +- 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 + chaos-exporter ClusterIP 10.68.45.7 8080/TCP 23h + litmusportal-auth-server-service NodePort 10.68.34.91 9003:32368/TCP,3030:31051/TCP 23h + litmusportal-frontend-service NodePort 10.68.43.68 9091:30070/TCP 23h + litmusportal-server-service NodePort 10.68.33.242 9002:32455/TCP,8000:30722/TCP 23h + my-release-mongodb-arbiter-headless ClusterIP None 27017/TCP 23h + my-release-mongodb-headless ClusterIP None 27017/TCP 23h + workflow-controller-metrics ClusterIP 10.68.33.65 9090/TCP 23h + ``` + +--- + +## **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 `31846`. 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 +https://172.17.0.3:31846/ +``` + +> Where `172.17.0.3` is my NodeIP and `31846` 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) + +**NOTE:** With advanced installation CORS rules are applied, once manifest is applied frontend loadbalancer IP needs to be added in the `ALLOWED_ORIGINS` environment in both auth and graphql server deployment. + +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 + +- [Install ChaosCenter with HTTP](../getting-started/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-3.9.2/user-guides/chaoscenter-oauth-dex-installation.md b/website/versioned_docs/version-3.9.2/user-guides/chaoscenter-oauth-dex-installation.md new file mode 100644 index 00000000..88b8aea0 --- /dev/null +++ b/website/versioned_docs/version-3.9.2/user-guides/chaoscenter-oauth-dex-installation.md @@ -0,0 +1,168 @@ +--- +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/callback' #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 + +![litmus-oauth-image](https://user-images.githubusercontent.com/31009634/135559389-c8cdf53c-76cf-4f9d-acaa-99014540f9cf.png) + +## Resources + +- [Dex OIDC Provider configurations](https://dexidp.io/docs/) + +## Learn more + +- [Install ChaosCenter with HTTP](../getting-started/installation.md)) +- [Install ChaosCenter with HTTPS](chaoscenter-advanced-installation.md)) +- [Connect External Chaos Delegates to ChaosCenter](../user-guides/chaos-infrastructure-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-3.9.2/user-guides/comparative-analysis.md b/website/versioned_docs/version-3.9.2/user-guides/comparative-analysis.md new file mode 100644 index 00000000..79c383dd --- /dev/null +++ b/website/versioned_docs/version-3.9.2/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-3.9.2/user-guides/configure-datasource.md b/website/versioned_docs/version-3.9.2/user-guides/configure-datasource.md new file mode 100644 index 00000000..68539caa --- /dev/null +++ b/website/versioned_docs/version-3.9.2/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-3.9.2/user-guides/construct-experiment.md b/website/versioned_docs/version-3.9.2/user-guides/construct-experiment.md new file mode 100644 index 00000000..e6a14802 --- /dev/null +++ b/website/versioned_docs/version-3.9.2/user-guides/construct-experiment.md @@ -0,0 +1,274 @@ +--- +id: construct-experiment +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](../glossary.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: 3.0.0 + 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:3.0.0 + 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: 3.0.0 + 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) diff --git a/website/versioned_docs/version-3.9.2/user-guides/create-environment.md b/website/versioned_docs/version-3.9.2/user-guides/create-environment.md new file mode 100644 index 00000000..681efcf0 --- /dev/null +++ b/website/versioned_docs/version-3.9.2/user-guides/create-environment.md @@ -0,0 +1,25 @@ +--- +id: create-environment +title: Create an Environment +sidebar_label: Create an Environment +--- + +## Before you begin + +You can learn about the concept of chaos environments [here](../concepts/infrastructure.md). + +## 1. Go to the Environments section + +Navigate to the `/environments` page (Environments on the left nav), and click on the `New Environment` button + + + +## 2. Add Environment details + +Add the details of the environment to be created such as name, description, tags, as well as the type of environment, i.e. `Pre-Production` and `Production`, these are meant to help further categorize the environments you are working with. + + + +The new environment will appear in the list as shown: + + diff --git a/website/versioned_docs/version-3.9.2/user-guides/create-infrastructure.md b/website/versioned_docs/version-3.9.2/user-guides/create-infrastructure.md new file mode 100644 index 00000000..077348c2 --- /dev/null +++ b/website/versioned_docs/version-3.9.2/user-guides/create-infrastructure.md @@ -0,0 +1,70 @@ +--- +id: create-infrastructure +title: Create an Infrastructure +sidebar_label: Create an Infrastructure +--- + +## Before you begin + +- You can learn about the concept of chaos infrastructures & chaos environments [here](../concepts/infrastructure.md). + +- You will need to create an environment for your chaos infrastructure to reside within. Environments are an abstraction layer over infrastructures, and a detailed guide on the environment creation process can be found [here](./create-environment.md) + +## 1. Go to the Infrastructure section + +Navigate to the `/environments` page (Environments on the left nav), and click on the environment you wish to install the chaos infrastructure in: + + + +## 2. Enable Chaos + +Click on the `Enable Chaos` button: + + + +## 3. Add details of the Infrastructure + +Add the details of the infrastructure such as the name, description and tags, then click on the `Next` button: + + + +## 4. Tune the cluster level specifications + +Choose one of the following modes: + +- **Cluster Wide:** This mode of infrastructure installation allows targeting resources across the entire cluster, in all the namespaces, as part of an experiment. +- **Namespace Mode:** This mode of infrastructure installation allows targeting resources only in the namespace where the chaos infrastructure is deployed. + +By default the installation will take place in the `litmus` namespace and uses `litmus` service account, which can be configured under the K8s cluster details. + +Optionally, you can also specify the node selectors and Kubernetes tolerations for chaos infrastructure deployment in the advanced section + + + +## 5. Deploy your Chaos Infrastructure + +- For cluster-wide access: + +
      +
    1. Select Download, and then copy and run the kubectl command shown on your screen to install the chaos infrastructure.
    2. +
    + + + +- For namespace access: + +
      +
    1. Run the first kubectl command to create the target namespace.
    2. +
    3. Run the second kubectl command to apply the chaos CRDs.
    4. +
    5. Select Download, and then copy and run the third command to install the chaos infrastructure.
    6. +
    + + + +Click `Done` + +**NOTE:** For HTTPS mode of installation of Chaoscenter, you will need to set `SKIP_SSL_VERIFY` as `true` in the infrastructure deployment yaml. + +The newly created infrastructure will appear in the list of infrastructures: + + diff --git a/website/versioned_docs/version-3.9.2/user-guides/create-resilience-probe.md b/website/versioned_docs/version-3.9.2/user-guides/create-resilience-probe.md new file mode 100644 index 00000000..650e7007 --- /dev/null +++ b/website/versioned_docs/version-3.9.2/user-guides/create-resilience-probe.md @@ -0,0 +1,43 @@ +--- +id: create-resilience-probe +title: Create a Resilience Probe +sidebar_label: Create a Resilience Probe +--- + +## Before you begin + +You can learn about the concept of resilience probes [here](../concepts/probes.md) and chaos experiments [here](../concepts/chaos-workflow.md). For this user guide, we will use a HTTP probe. + +## 1. Go to the Resilience Probes section + +Navigate to the `/probes` page (Resilience Probes on the left nav), and click on the `New Probe` button + + + +## 2. Select the type of probe + +Select and click on the type of probe you would like to create, you can read about the available probe types [here](../concepts/probes.md) + + + +## 3. Enter the details of the probe to create + +Enter the details of the probe such as name, description (optional), tags (optional) + + + +## 4. Configure the probe properties + +Configure the properties for the probe you are creating, such as, Timeout, Interval, Retry, etc. + + + +## 5. Configure the probe details + +Configure the details for the probe you are creating, once completed, click the `Setup Probe` button + + + +The new probe will appear in the list as shown: + + diff --git a/website/versioned_docs/version-3.9.2/user-guides/create-user.md b/website/versioned_docs/version-3.9.2/user-guides/create-user.md new file mode 100644 index 00000000..3f8aa73d --- /dev/null +++ b/website/versioned_docs/version-3.9.2/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. Navigate to User Management + +Go to the `User Management` tab of the account settings page: + + + +## 2. Create a new user + +Click on the `New User` button to bring up the `Create New User` modal and enter the details of the new user to be created. + + + +## 3. Confirmation of creation + +After you have added the details of the new user to be created, click the `Confirm` button to create the new user. + + + +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-3.9.2/user-guides/deactivate-user.md b/website/versioned_docs/version-3.9.2/user-guides/deactivate-user.md new file mode 100644 index 00000000..ecec52b9 --- /dev/null +++ b/website/versioned_docs/version-3.9.2/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 deactivation + +On clicking on the `Disable User` option, a confirmation prompt will pop up, click on the `Confirm` button in order to disable the user. + + + +## 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-3.9.2/user-guides/delete-environment.md b/website/versioned_docs/version-3.9.2/user-guides/delete-environment.md new file mode 100644 index 00000000..0c4c92f2 --- /dev/null +++ b/website/versioned_docs/version-3.9.2/user-guides/delete-environment.md @@ -0,0 +1,21 @@ +--- +id: delete-environment +title: Delete an Environment +sidebar_label: Delete an Environment +--- + +## 1. Go to the Environments section + +Navigate to the `/environments` page (Environments on the left nav), click on the `options` icon to open the options menu and select `Delete` option: + + + +## 2. Confirm Environment deletion + +After opening the options menu and clicking on the `Delete` option, you'll see a prompt in order to confirm your action. Please ensure that you want to delete the selected environment and click the `Confirm` button: + + + +The deleted environment details will disappear from the list as shown: + + diff --git a/website/versioned_docs/version-3.9.2/user-guides/delete-experiment.md b/website/versioned_docs/version-3.9.2/user-guides/delete-experiment.md new file mode 100644 index 00000000..fce711f2 --- /dev/null +++ b/website/versioned_docs/version-3.9.2/user-guides/delete-experiment.md @@ -0,0 +1,41 @@ +--- +id: delete-experiment +title: Delete a Chaos experiment +sidebar_label: Delete Chaos experiment +--- + +--- + +If required, it is possible to delete a chaos experiment schedule that you no longer wish to run against your application. + +:::note +This also means that all the runs corresponding to that chaos experiment will also be deleted. +::: + +## Before you begin + +You can learn about the concept of chaos experiments [here](../concepts/chaos-workflow.md) and how to schedule your first chaos experiment [here](schedule-experiment.md). + +## 1. Go to the chaos experiments sections + +In the `Chaos experiment` page, go to the specific experiment you wish to delete: + + + +## 2. Click on the `Delete experiment` option + +After opening the options menu and clicking on the `Delete experiment` option, you'll see a prompt in order to confirm your action. Please ensure that you want to delete the selected chaos experiment and click the `Confirm` button: + + + +## 3. The Chaos experiment has been deleted + +You will observe that the chaos experiment no longer appears in the list of schedules and has been removed. + + + +As stated above, the runs have been removed as well. + +## Learn more + +- [schedule a chaos experiment](schedule-experiment.md) diff --git a/website/versioned_docs/version-3.9.2/user-guides/delete-infrastructure.md b/website/versioned_docs/version-3.9.2/user-guides/delete-infrastructure.md new file mode 100644 index 00000000..60075843 --- /dev/null +++ b/website/versioned_docs/version-3.9.2/user-guides/delete-infrastructure.md @@ -0,0 +1,25 @@ +--- +id: delete-infrastructure +title: Delete an Infrastructure +sidebar_label: Delete an Infrastructure +--- + +## 1. Go to the Infrastructure section + +Navigate to the infrastructure you want to delete, and click on the `options` icon to open the options menu and select `Disable` option: + + + +## 2. Confirm Infrastructure deletion + +After opening the options menu and clicking on the `Disable` option, you'll see a prompt in order to confirm your action. Please ensure that you want to delete the selected infrastructure and click the `Confirm` button: + +:::note +The disabling of the infrastructure from the UI will clean-up the subscriber pod from the cluster, but the remaining resources are left to the user to clean up, please follow the steps and the commands provided in the deletion confirmation modal to do so. +::: + + + +The deleted infrastructure will disappear from the list as shown: + + diff --git a/website/versioned_docs/version-3.9.2/user-guides/delete-resilience-probe.md b/website/versioned_docs/version-3.9.2/user-guides/delete-resilience-probe.md new file mode 100644 index 00000000..75bb90f9 --- /dev/null +++ b/website/versioned_docs/version-3.9.2/user-guides/delete-resilience-probe.md @@ -0,0 +1,27 @@ +--- +id: delete-resilience-probe +title: Delete a Resilience Probe +sidebar_label: Delete a Resilience Probe +--- + +:::note +Deleting a probe will delete all the associations with experiment runs from the chaos control plane. This will also misplace any analytics that had incurred for the previous runs for said probe. +::: + +## 1. Go to the probes sections + +In the `Resilience Probes` page, go to the specific probe you wish to delete: + + + +## 2. Click on the `Delete Probe` option + +After opening the options menu and clicking on the `Delete Probe` option, you'll see a prompt in order to confirm your action. Please ensure that you want to delete the selected resilience probe and click the `Confirm` button: + + + +## 3. The Resilience probe has been deleted + +You will observe that the resilience probe no longer appears in the list of probes and has been removed. + + diff --git a/website/versioned_docs/version-3.9.2/user-guides/download-experiment-manifest.md b/website/versioned_docs/version-3.9.2/user-guides/download-experiment-manifest.md new file mode 100644 index 00000000..a2229dd0 --- /dev/null +++ b/website/versioned_docs/version-3.9.2/user-guides/download-experiment-manifest.md @@ -0,0 +1,31 @@ +--- +id: download-experiment-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-experiment.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-experiment.md) +- [Re-run a chaos scenario](re-run-experiment.md) +- [Delete a chaos scenario](delete-experiment.md) diff --git a/website/versioned_docs/version-3.9.2/user-guides/edit-environment.md b/website/versioned_docs/version-3.9.2/user-guides/edit-environment.md new file mode 100644 index 00000000..4656dd31 --- /dev/null +++ b/website/versioned_docs/version-3.9.2/user-guides/edit-environment.md @@ -0,0 +1,21 @@ +--- +id: edit-environment +title: Edit an Environment +sidebar_label: Edit an Environment +--- + +## 1. Go to the Environments section + +Navigate to the `/environments` page (Environments on the left nav), click on the `options` icon to open the options menu and select `Edit Environment` option: + + + +## 2. Update Environment details + +Update the details of the environment as required and click the `Save` button. + + + +The updated environment details will appear in the list as shown: + + diff --git a/website/versioned_docs/version-3.9.2/user-guides/edit-invite.md b/website/versioned_docs/version-3.9.2/user-guides/edit-invite.md new file mode 100644 index 00000000..3328bbcb --- /dev/null +++ b/website/versioned_docs/version-3.9.2/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 `Remove` button. + + + +## Learn more + +- [Accept an invitation](accept-invite.md) diff --git a/website/versioned_docs/version-3.9.2/user-guides/edit-resilience-probe.md b/website/versioned_docs/version-3.9.2/user-guides/edit-resilience-probe.md new file mode 100644 index 00000000..4c8c96cb --- /dev/null +++ b/website/versioned_docs/version-3.9.2/user-guides/edit-resilience-probe.md @@ -0,0 +1,23 @@ +--- +id: edit-resilience-probe +title: Edit a Resilience Probe +sidebar_label: Edit a Resilience Probe +--- + +## 1. Go to the probes sections + +In the `Resilience Probes` page, go to the specific probe you wish to edit: + + + +## 2. Click on the `Edit Probe` option + +After opening the options menu and clicking on the `Edit Probe` option, you'll see a modal pop-up where you will be able to go through all the steps of probe setup and edit the details on each step (Note: name is unique and cannot be edited): + + + +## 3. The Resilience probe has been edited + +Once you've updated all the details of the probe, click on the `Setup Probe` button to commit the updated details of the probe. + + diff --git a/website/versioned_docs/version-3.9.2/user-guides/edit-schedule.md b/website/versioned_docs/version-3.9.2/user-guides/edit-schedule.md new file mode 100644 index 00000000..d30b8a32 --- /dev/null +++ b/website/versioned_docs/version-3.9.2/user-guides/edit-schedule.md @@ -0,0 +1,52 @@ +--- +id: edit-schedule +title: Edit Chaos Experiment Schedule +sidebar_label: Edit Chaos Experiment Schedule +--- + +--- + +## Before you begin + +You must schedule a chaos experiment. To know more about scheduling chaos experiments click [here](schedule-experiment.md) + +--- + +After you have scheduled a chaos experiment, you might have a need of changing the schedule of a recurring chaos experiment. To edit the schedule follow these steps: + +## 1. Select edit schedule from the menu + +In the `Chaos experiments` page you can click on the triple dots of the experiment to access more options for it. From the menu select the `Edit Experiment` option. + +
    +Selecting Edit Schedule from the Menu +Selecting Edit Schedule from the Menu +
    + +## 2. Click on edit button + +Now you'll be seeing the pipeline diagram of your chaos experiment and you can click on the `Schedule` tab to change the schedule. + +
    +Summary of the Chaos experiment with Edit button +Summary of the Chaos experiment with Edit button +
    + +## 3. Change the schedule + +Here you can change the schedule to the required interval and click on the `Set schedule` button. + +
    +Editing the Schedule +Editing the Schedule +
    + +## 4. Save the changes + +Click the `Save` button to save the changes to the experiment chaos experiment. + +## Learn more + +- [Observe Chaos Experiment](observe-experiment.md) +- [Save Chaos Experiments as a Template](save-as-template.md) +- [Re-run a Chaos Experiment](re-run-experiment.md) diff --git a/website/versioned_docs/version-3.9.2/user-guides/editing-queries-app-dashboard.md b/website/versioned_docs/version-3.9.2/user-guides/editing-queries-app-dashboard.md new file mode 100644 index 00000000..45cd1fa0 --- /dev/null +++ b/website/versioned_docs/version-3.9.2/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-3.9.2/user-guides/event-triggered-chaos.md b/website/versioned_docs/version-3.9.2/user-guides/event-triggered-chaos.md new file mode 100644 index 00000000..19be6710 --- /dev/null +++ b/website/versioned_docs/version-3.9.2/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-3.9.2/user-guides/gitops-configuration.md b/website/versioned_docs/version-3.9.2/user-guides/gitops-configuration.md new file mode 100644 index 00000000..911ba0ea --- /dev/null +++ b/website/versioned_docs/version-3.9.2/user-guides/gitops-configuration.md @@ -0,0 +1,109 @@ +--- +id: gitops-configuration +title: Configuring GitOps +sidebar_label: Configuring GitOps +--- + +:::note +With the latest release of LitmusChaos 3.0.0: +
  • The term Chaos Experiment has been changed to Chaos Fault.
  • +
  • The term Chaos Scenario/Workflow has been changed to Chaos Experiment.
  • +::: + + +## Introduction + +GitOps enables you to configure a single source of truth for your chaos experiment and faults, 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 Infrastructure](../concepts/infrastructure.md) +- [Chaos Experiment](../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 experiments 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` (Project Setup > GitOps on the left nav). +

    + +

    +- Select the `Git Repository` radio button. +- Copy the git URL of your git repository and paste it in the `Repository URL` text box. +- Enter the branch where you want to sync your chaos experiments. +

    + +

    +- You can allow access of your repository either through an access token or through an SSH key. +- In the case of the SSH key, click the button `Generate New SSH Key` and 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 `Save` button. A snackbar 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 experiment, 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 experiments that are created and pushed to the git repository directly, after configuring GitOps. In this case, if the chaos experiment is a single run chaos experiment, then it starts executing as soon as it is pushed to the repository. Alternatively, if the chaos experiment is a scheduled chaos experiment, then it executes as per the defined schedule. On the other hand, updating an existing chaos experiment present in the git repository will not execute the chaos experiment but only sync the chaos experiment resource definition with the ChaosCenter, if applicable. +::: + +## Steps to configure Event-Triggered Chaos Injection + +- Once the chaos experiment is pushed to your repository, you’ll notice every chaos experiment has a `experiment_id`. You can get this from the chaos experiment 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 experiment using this experiment_id and run it on your target application. You can use the following command: + +``` +kubectl annotate deploy/target-application litmuschaos.io/experimentId=${experiment_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 experiment 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 experiment 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 + +## Learn More + +- [Schedule a chaos experiment](../user-guides/schedule-experiment.md) +- [Observe a Chaos experiment](../user-guides/observe-experiment.md) diff --git a/website/versioned_docs/version-3.9.2/user-guides/image-registry.md b/website/versioned_docs/version-3.9.2/user-guides/image-registry.md new file mode 100644 index 00000000..32bdaaa7 --- /dev/null +++ b/website/versioned_docs/version-3.9.2/user-guides/image-registry.md @@ -0,0 +1,63 @@ +--- +id: image-registry +title: Using different Image Registries in a Chaos Experiments +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 experiments. Few images that are used in the Litmus chaos experiments are `litmuschaos:k8s`, `litmuschaos:litmus-checker` etc. +With ChaosCenter, you get the privilege to use your own/custom image registries for Chaos experiments. + +## Before you begin + +To understand the concept of Image Registry, make sure you are aware of [Chaos experiment](../concepts/chaos-workflow.md) and the different image registries that are used in it. + +## Steps to Update Chaos experiment Image Registry + +To updated the Chaos experiment Image Registry, you can go to Image Registry in ChaosCenter (Project Setup > Image Registry on the left nav). 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. Custom Image Registry (Registry Server) +2. Custom Repo (Registry Name) +3. Registry Type `Public/Private` + + +

    + +If the Registry Type is `Private`, make sure to provide the secret. + +Once the details are provided, click on the `Save` button and you can see the updated Image Registry changes. + + + +

    + +Now while scheduling a chaos experiment, the image registry changes will be visible. Here's the code snippet from a Chaos experiment 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 experiment](../concepts/chaos-workflow.md) +- [What is ChaosCenter](../getting-started/resources.md#chaoscenter) diff --git a/website/versioned_docs/version-3.9.2/user-guides/invite-team-member.md b/website/versioned_docs/version-3.9.2/user-guides/invite-team-member.md new file mode 100644 index 00000000..1afe8527 --- /dev/null +++ b/website/versioned_docs/version-3.9.2/user-guides/invite-team-member.md @@ -0,0 +1,30 @@ +--- +id: invite-team-member +title: Invite a Team Member +sidebar_label: Invite Team Member +--- + +--- + +> In the `/setup` route (Project Setup > Members on the sidebar) the `Active/Pending members` tabs 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 `Pending members` tab. + +## 1. Find the user you want to invite + +In the team tab, click the `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/Executor) and hit the same button. + + + +On successful acceptance of the invitation you will be able to collaborate over your project! + +## Learn more + +- [Edit an invitation](edit-invite.md) +- [Accept invite](accept-invite.md) diff --git a/website/versioned_docs/version-3.9.2/user-guides/leave-project.md b/website/versioned_docs/version-3.9.2/user-guides/leave-project.md new file mode 100644 index 00000000..293417fb --- /dev/null +++ b/website/versioned_docs/version-3.9.2/user-guides/leave-project.md @@ -0,0 +1,26 @@ +--- +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 `Projects Joined` section. 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 + +A confirmation dialog will pop up, click on the `Confirm` button to leave the project + + + +## 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-3.9.2/user-guides/manage-app-dashboard.md b/website/versioned_docs/version-3.9.2/user-guides/manage-app-dashboard.md new file mode 100644 index 00000000..4fae3ccb --- /dev/null +++ b/website/versioned_docs/version-3.9.2/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-3.9.2/user-guides/observability-set-up.md b/website/versioned_docs/version-3.9.2/user-guides/observability-set-up.md new file mode 100644 index 00000000..2c288152 --- /dev/null +++ b/website/versioned_docs/version-3.9.2/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-3.9.2/user-guides/observe-experiment.md b/website/versioned_docs/version-3.9.2/user-guides/observe-experiment.md new file mode 100644 index 00000000..9de1408e --- /dev/null +++ b/website/versioned_docs/version-3.9.2/user-guides/observe-experiment.md @@ -0,0 +1,42 @@ +--- +id: observe-experiment +title: Observe Chaos experiment +sidebar_label: Observe Chaos experiment +--- + +--- + +Visualization is an important aspect while doing chaos engineering. It allows the user to discover and inspect different changes that occur during a Chaos Experiment execution.
    +With ChaosCenter, the real-time data and status of the chaos experiments can be observed. Valuable information like pod logs, chaos experiment status, and chaos results can also be viewed. + +## Prerequisites + +The following should be required before creating a Chaos Experiment: + +- ChaosCenter +- [Chaos Experiments](../concepts/chaos-workflow.md) + +## Litmus Chaos Experiment + +If the user chooses to 'Save' and 'Run' the experiment, they will be redirected directly to the experiment execution page where the experiment can be visualised else they will be taken Chaos Experiment Page. + +## Observe a Litmus Chaos Experiment + +To observe a chaos experiment, user needs to select the highlighted experiment run box from the heatmap, it will redirect to experiment run execution page.
    + + +In the chaos experiment, a realtime graph of the chaos experiment is displayed. This graph contains valuable information regarding the status of individual steps of the chaos experiment.

    +

    +To view the details of each step, the user can click on the individual nodes and the right side pane will display the node details, results(once the execution is complete), and the logs related to it. +

    + + + +## Summary + +After scheduling a chaos experiment, a user can view the details of the running chaos experiment from the ChaosCenter. ChaosCenter provides a real-time graph that is used to visualize the chaos experiment and get the details of individual steps of the chaos experiment. Important details like the logs and target applications can be viewed from ChaosCenter. Once the chaos experiment execution is completed, the resiliency score is calculated and the ChaosResult for the ChaosEngine pods is available. + +## Learn More + +- [Explore Probes](../concepts/probes.md) +- [What is a Chaos Experiment](../concepts/chaos-workflow.md) diff --git a/website/versioned_docs/version-3.9.2/user-guides/overview.md b/website/versioned_docs/version-3.9.2/user-guides/overview.md new file mode 100644 index 00000000..7c253a23 --- /dev/null +++ b/website/versioned_docs/version-3.9.2/user-guides/overview.md @@ -0,0 +1,45 @@ +--- +id: overview +title: Overview +sidebar_label: Overview +--- + +--- + +The User Guides section details Processes, User-flows and How-tos detailing all sorts of experiments in various environments. Technical details and inner workings of the various components are explained in the [Concepts](../concepts/overview.md) section. + +### [Advanced Installation](chaoscenter-advanced-installation.md) + +Install ChaosCenter and Chaos Infrastructure in various environment configurations. + +### [Injecting Fault](schedule-experiment.md) + +Constructing, Scheduling, Editing and Observing chaos experiments. + +### [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 experiment 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 Experiment](image-registry.md) + +Using different Image Registries like Docker, Red Hat Quay, Google Container Registry in a Chaos Experiment. + +### [Uninstalling Litmus](uninstall-litmus.md) + +Disconnecting Chaos Infrastructure and uninstalling ChaosCenter. diff --git a/website/versioned_docs/version-3.9.2/user-guides/re-run-experiment.md b/website/versioned_docs/version-3.9.2/user-guides/re-run-experiment.md new file mode 100644 index 00000000..93caf784 --- /dev/null +++ b/website/versioned_docs/version-3.9.2/user-guides/re-run-experiment.md @@ -0,0 +1,30 @@ +--- +id: re-run-experiment +title: Re-run a chaos experiment +sidebar_label: Re-run chaos experiment +--- + +--- + +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 experiment [here](schedule-experiment.md). + +## 1. Go to the chaos experiments sections + +In the `Chaos experiment` page, and click on the play icon for the specific schedule you wish to re-run: + + + +## 2. Click on the `Run Experiment` option + +Having re-run a particular experiment, you will redirected to the chaos studio for the particular execution and see that it has started to run as per the experiment configurations: + + + +## Learn more + +- [Schedule a chaos experiment](schedule-experiment.md) +- [Delete a chaos experiment](delete-experiment.md) diff --git a/website/versioned_docs/version-3.9.2/user-guides/remove-team-member.md b/website/versioned_docs/version-3.9.2/user-guides/remove-team-member.md new file mode 100644 index 00000000..5fa2af38 --- /dev/null +++ b/website/versioned_docs/version-3.9.2/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 `Active members` tab in the Members page, 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 `Options` icon as shown and select the `Remove Member` option. + + + +### 2. Confirmation for removal + +On hitting the `Remove Member` option, you will be prompted to confirm the removal of the member, hit `Confirm` to confirm and remove the member from your project. + + diff --git a/website/versioned_docs/version-3.9.2/user-guides/reset-password.md b/website/versioned_docs/version-3.9.2/user-guides/reset-password.md new file mode 100644 index 00000000..45781ebb --- /dev/null +++ b/website/versioned_docs/version-3.9.2/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 `Reset Password` option + + + +## 2. Change the password + +In the `Reset Password` modal type in the new password in the `New Password` & `Re-enter new password` fields. Once done hit the `Confirm` button to update the password. + + + +## Learn more + +- [View users](view-user.md) diff --git a/website/versioned_docs/version-3.9.2/user-guides/save-as-template.md b/website/versioned_docs/version-3.9.2/user-guides/save-as-template.md new file mode 100644 index 00000000..4d0237ea --- /dev/null +++ b/website/versioned_docs/version-3.9.2/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-experiment.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-experiment.md) +- [Re-run a chaos scenario](re-run-experiment.md) +- [Delete a chaos scenario](delete-experiment.md) diff --git a/website/versioned_docs/version-3.9.2/user-guides/schedule-experiment.md b/website/versioned_docs/version-3.9.2/user-guides/schedule-experiment.md new file mode 100644 index 00000000..dd3444b2 --- /dev/null +++ b/website/versioned_docs/version-3.9.2/user-guides/schedule-experiment.md @@ -0,0 +1,160 @@ +--- +id: schedule-experiment +title: Schedule a Chaos Experiment +sidebar_label: Schedule Chaos Experiment +--- + +--- + +## Before you begin + +You must connect an Chaos Infrastructure before scheduling a chaos experiment. You can [connect an external Chaos Infrastructure](../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 **Chaos Studio** page where you can choose or design your own chaos scenario by doing the following steps: + +## 1. Provide the identifiers for the experiment to be created + +In the Experiment Overview, enter the experiment Name and optional Description and Tags. + +
    +Add Identifiers +
    + +## 2. Choose target chaos infrastructure + +In **Select a Chaos Infrastructure**, select the infrastructure where the target resources reside, and then click **Apply**. + +
    +Selecting an Chaos Infrastructure +
    + +After Selecting the chaos Infrastructure , you can continue by clicking on **Next** button. This takes you to the Experiment Builder tab, where you can choose how to start building your experiment. + +## 3. Choose you want to build your chaos experiment + +
    +Choosing a method +
    + +Select how you want to build the experiment. The options, explained later, are: + +- Blank Canvas - Lets you build the experiment from scratch, adding the specific faults you want. + +- Templates from Chaos Hubs - Lets you preview and select and experiment from pre-curated experiment templates available in Chaos Hubs. + +- Upload YAML - Lets you upload an experiment manifest YAML file. + +These options are explained below. + +**If you select Blank Canvas:** + +The Experiment Builder tab is displayed. + +
    +Add to blank canvas +
    + +a. Select **Add**, then select each fault you want to add to the experiment individually. + +
    +litmus-chaos-hub +
    + +For each fault you select, you'll tune the fault's properties next. + +
    +tune-fault +
    + +b. To tune each fault: + +- **Specify the target application (only for pod-level Kubernetes faults):** This lets the application's corresponding pods be targeted. + +- **Tune fault parameters:** Every fault has a set of common parameters, such as the chaos duration, ramp time, etc., and a set of unique parameters that may be customised as needed. + +- **Add chaos probes:** On the Probes tab, you can add chaos probes to automate the chaos hypothesis checks for a fault during the experiment execution. Probes are declarative checks that aid in the validation of certain criteria that are deemed necessary to declare an experiment as passed. + +- **Tune fault weightage:** Set the weight for the fault, which sets the importance of the fault relative to the other faults in the experiments. This is used to calculate the resilience score of the experiment. + +c. To add a fault that runs in parallel to another fault, point your mouse below an existing fault, and then select Add. + +
    +add-parallel-faults +
    + +In Experiment Builder, faults that are stacked vertically run in parallel, and faults or groups of parallel faults run in sequence from left to right. + +**If you select Templates from Chaos Hubs:** + +a. Select an experiment template from a chaos hub. + +Select Experiment Type to see available chaos hubs to select templates from. +Select a template to see a preview of the faults included. + +
    +select-template-from-chaos-hub +
    + +You can edit the template to add more faults or update the existing faults. + +**If you select Upload YAML:** + +a. Upload an experiment manifest YAML file to create the experiment. + +You can edit the experiment to update the existing faults or add more of them. + +## 4. Save the experiment. + +
    +chaos-experiment-save +
    + +Now, you can choose to either run the experiment right away by selecting the Run button on the top, or create a recurring schedule to run the experiment by selecting the Schedule tab. + +## Advanced experiment setup options + +You can select Advanced Options on the Experiment Builder tab to configure the advanced options (described below) while creating an experiment for a Kubernetes chaos infrastructure: + +
    +advanced-options-experiment-creation +
    + +## General options + +### Node Selector + +Specifies the node on which the experiment pods will be scheduled. Provide the node label as a key-value pair. + +- Can be used with node-level faults to avoid the scheduling of the experiment pod on the target node(s). + +- Can be used to limit the scheduling of the experiment pods on nodes that have an unsupported OS. + +
    +node-selectors +
    + +### Toleration + +Specifies the tolerations that must be satisfied by a tainted node to be able to schedule the experiment pods. For more information on taints and tolerations, go to the [Kubernetes documentation](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/). + +- Can be used with node-level faults to avoid the scheduling of the experiment pod on the target node(s). + +- Can be used to limit the scheduling of the experiment pods on nodes that have an unsupported OS. + +
    +tolerations +
    + +## Learn more + +- [Observe Chaos Scenario ](observe-experiment.md) +- [Edit Schedule](edit-schedule.md) +- [Save Chaos Scenarios as a Template](save-as-template.md) diff --git a/website/versioned_docs/version-3.9.2/user-guides/setup-datasource.md b/website/versioned_docs/version-3.9.2/user-guides/setup-datasource.md new file mode 100644 index 00000000..b40bc148 --- /dev/null +++ b/website/versioned_docs/version-3.9.2/user-guides/setup-datasource.md @@ -0,0 +1,467 @@ +--- +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. + +### 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-3.9.2/user-guides/setup-with-ingress.md b/website/versioned_docs/version-3.9.2/user-guides/setup-with-ingress.md new file mode 100644 index 00000000..29df17c0 --- /dev/null +++ b/website/versioned_docs/version-3.9.2/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 + +- [Install ChaosCenter with HTTP](../getting-started/installation.md)) +- [Install ChaosCenter with HTTPS](chaoscenter-advanced-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 with HTTP](../getting-started/installation.md)) +- [Install ChaosCenter with HTTPS](chaoscenter-advanced-installation.md) diff --git a/website/versioned_docs/version-3.9.2/user-guides/setup-without-ingress.md b/website/versioned_docs/version-3.9.2/user-guides/setup-without-ingress.md new file mode 100644 index 00000000..97f47338 --- /dev/null +++ b/website/versioned_docs/version-3.9.2/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 + +- [Install ChaosCenter with HTTP](../getting-started/installation.md)) +- [Install ChaosCenter with HTTPS](chaoscenter-advanced-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 with HTTP](../getting-started/installation.md)) +- [Install ChaosCenter with HTTPS](chaoscenter-advanced-installation.md) diff --git a/website/versioned_docs/version-3.9.2/user-guides/share-app-dashboard.md b/website/versioned_docs/version-3.9.2/user-guides/share-app-dashboard.md new file mode 100644 index 00000000..93bf92c6 --- /dev/null +++ b/website/versioned_docs/version-3.9.2/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. 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-3.9.2/user-guides/uninstall-litmus.md b/website/versioned_docs/version-3.9.2/user-guides/uninstall-litmus.md new file mode 100644 index 00000000..c2a5cbe3 --- /dev/null +++ b/website/versioned_docs/version-3.9.2/user-guides/uninstall-litmus.md @@ -0,0 +1,95 @@ +--- +id: uninstall-litmus +title: Uninstalling Litmus +sidebar_label: Uninstall Litmus +--- + +--- + +## Chaos Infrastructure + +To disconnect the [Chaos Infrastructure](../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 Infrastructure + + ```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 Infrastructures Page. +3. Click on the three dot menu and select `Disable` of the respective Chaos Infrastructure you want to disconnect. +4. On the Modal that appears, confirm your selection by clicking `Yes` and the selected Chaos Infrastructure would be disconnected from the ChaosCenter. + :::note + The above disconnect would remove the subscriber component from Chaos Infrastructure and thus removing the connectivity between the Chaos Infrastructure and the ChaosCenter. + + If the Chaos Infrastructure 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 Infrastructures 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 + +```bash +kubectl delete sa rolebindings role --all -n +``` + +--- + +## Remove the Litmus CRDs + +To remove all the CRDs Litmus uses, use the following command: + +```bash +kubectl delete -f https://raw.githubusercontent.com/litmuschaos/litmus/3.9.2/chaoscenter/manifests/litmus-portal-crds.yml +``` + +--- + +## ChaosCenter + +> To remove the Chaos Infrastructure Resources you need to follow the above Chaos Infrastructure Uninstall process + +To uninstall the ChaosCenter from the system, follow these steps - + +### Using Kubectl + +```bash +kubectl delete -f ${LITMUS_PORTAL_NAMESPACE}-ns-scoped-litmus-portal-manifest.yml -n ${LITMUS_PORTAL_NAMESPACE} +``` + +### Using Helm + +```bash +helm uninstall litmuschaos --namespace +kubectl delete ns +``` diff --git a/website/versioned_docs/version-3.9.2/user-guides/upgrade.md b/website/versioned_docs/version-3.9.2/user-guides/upgrade.md new file mode 100644 index 00000000..df51461c --- /dev/null +++ b/website/versioned_docs/version-3.9.2/user-guides/upgrade.md @@ -0,0 +1,36 @@ +--- +id: upgrade +title: Upgrade Litmus ChaosCenter to Latest Version +sidebar_label: Upgrade +--- + +--- + +## Upgrade ChaosCenter + +To upgrade Litmus ChaosCenter from 3.8.0 to 3.9.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/3.9.2/litmus-getting-started.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-3.9.2/user-guides/view-chaos-impact.md b/website/versioned_docs/version-3.9.2/user-guides/view-chaos-impact.md new file mode 100644 index 00000000..425cb3b3 --- /dev/null +++ b/website/versioned_docs/version-3.9.2/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-3.9.2/user-guides/view-probe-details.md b/website/versioned_docs/version-3.9.2/user-guides/view-probe-details.md new file mode 100644 index 00000000..e47b3258 --- /dev/null +++ b/website/versioned_docs/version-3.9.2/user-guides/view-probe-details.md @@ -0,0 +1,24 @@ +--- +id: view-resilience-probe +title: View Resilience Probe Details +sidebar_label: View Resilience Probe Details +--- + + +## 1. Go to the probes sections + +In the `Resilience Probes` page, go to the specific probe you wish to view the details of: + + + +## 2. View Execution history + +Click on the specific probe you would like to see the details of, this will redirect you to the `Execution History` tab: + + + +## 3. View Probe configurations + +On the same page you can click on the `Probe Configuration` tab to see the configuration of the said probe: + + diff --git a/website/versioned_docs/version-3.9.2/user-guides/view-user.md b/website/versioned_docs/version-3.9.2/user-guides/view-user.md new file mode 100644 index 00000000..49d25e3d --- /dev/null +++ b/website/versioned_docs/version-3.9.2/user-guides/view-user.md @@ -0,0 +1,21 @@ +--- +id: view-user +title: View all users +sidebar_label: View users +--- + +--- + +> In the `settings` page 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-3.10.0-sidebars.json b/website/versioned_sidebars/version-3.10.0-sidebars.json new file mode 100644 index 00000000..939a4d4d --- /dev/null +++ b/website/versioned_sidebars/version-3.10.0-sidebars.json @@ -0,0 +1,136 @@ +{ + "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" + ] + }, + { + "Architecture": [ + "architecture/overview", + "architecture/architecture-summary", + "architecture/chaos-control-plane", + "architecture/chaos-execution-plane", + "architecture/chaos-fault-flow" + ] + }, + { + "Concepts": [ + "concepts/overview", + "concepts/chaos-infrastructure", + "concepts/chaoshub", + "concepts/chaos-workflow", + "concepts/probes", + "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-advanced-installation", + "user-guides/setup-without-ingress", + "user-guides/setup-with-ingress" + ] + }, + "user-guides/chaos-infrastructure-installation" + ] + }, + { + "Environments": [ + "user-guides/create-environment", + "user-guides/edit-environment", + "user-guides/delete-environment" + ] + }, + { + "Chaos Infrastructure": [ + "user-guides/create-infrastructure", + "user-guides/delete-infrastructure" + ] + }, + { + "Injecting Fault": [ + "user-guides/schedule-experiment", + "user-guides/observe-experiment", + "user-guides/edit-schedule", + "user-guides/download-experiment-manifest", + "user-guides/re-run-experiment", + "user-guides/delete-experiment", + "user-guides/construct-experiment" + ] + }, + { + "Resilience Probes": [ + "user-guides/create-resilience-probe", + "user-guides/delete-resilience-probe", + "user-guides/edit-resilience-probe", + "user-guides/view-resilience-probe" + ] + }, + "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" + ] + }, + { + "Litmusctl": [ + "litmusctl/installation", + "litmusctl/litmusctl-usage" + ] + }, + { + "Integrations": [ + "integrations/prometheus", + "integrations/grafana", + "integrations/backstage" + ] + }, + "troubleshooting", + "best-practices", + "glossary", + "faq" + ] +} diff --git a/website/versioned_sidebars/version-3.9.2-sidebars.json b/website/versioned_sidebars/version-3.9.2-sidebars.json new file mode 100644 index 00000000..939a4d4d --- /dev/null +++ b/website/versioned_sidebars/version-3.9.2-sidebars.json @@ -0,0 +1,136 @@ +{ + "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" + ] + }, + { + "Architecture": [ + "architecture/overview", + "architecture/architecture-summary", + "architecture/chaos-control-plane", + "architecture/chaos-execution-plane", + "architecture/chaos-fault-flow" + ] + }, + { + "Concepts": [ + "concepts/overview", + "concepts/chaos-infrastructure", + "concepts/chaoshub", + "concepts/chaos-workflow", + "concepts/probes", + "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-advanced-installation", + "user-guides/setup-without-ingress", + "user-guides/setup-with-ingress" + ] + }, + "user-guides/chaos-infrastructure-installation" + ] + }, + { + "Environments": [ + "user-guides/create-environment", + "user-guides/edit-environment", + "user-guides/delete-environment" + ] + }, + { + "Chaos Infrastructure": [ + "user-guides/create-infrastructure", + "user-guides/delete-infrastructure" + ] + }, + { + "Injecting Fault": [ + "user-guides/schedule-experiment", + "user-guides/observe-experiment", + "user-guides/edit-schedule", + "user-guides/download-experiment-manifest", + "user-guides/re-run-experiment", + "user-guides/delete-experiment", + "user-guides/construct-experiment" + ] + }, + { + "Resilience Probes": [ + "user-guides/create-resilience-probe", + "user-guides/delete-resilience-probe", + "user-guides/edit-resilience-probe", + "user-guides/view-resilience-probe" + ] + }, + "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" + ] + }, + { + "Litmusctl": [ + "litmusctl/installation", + "litmusctl/litmusctl-usage" + ] + }, + { + "Integrations": [ + "integrations/prometheus", + "integrations/grafana", + "integrations/backstage" + ] + }, + "troubleshooting", + "best-practices", + "glossary", + "faq" + ] +} diff --git a/website/versions.json b/website/versions.json index 3ed0a20b..168c8677 100644 --- a/website/versions.json +++ b/website/versions.json @@ -1,4 +1,6 @@ [ + "3.10.0", + "3.9.2", "3.9.1", "3.9.0", "3.8.0",