diff --git a/website/docs/assets/concepts/chaoshub/chaoshub-add-private.png b/website/docs/assets/concepts/chaoshub/chaoshub-add-private.png
index 27df9ebd..7032fc29 100644
Binary files a/website/docs/assets/concepts/chaoshub/chaoshub-add-private.png and b/website/docs/assets/concepts/chaoshub/chaoshub-add-private.png differ
diff --git a/website/docs/assets/concepts/chaoshub/chaoshub-add-public.png b/website/docs/assets/concepts/chaoshub/chaoshub-add-public.png
index e7a57e00..92dbd089 100644
Binary files a/website/docs/assets/concepts/chaoshub/chaoshub-add-public.png and b/website/docs/assets/concepts/chaoshub/chaoshub-add-public.png differ
diff --git a/website/docs/assets/concepts/chaoshub/chaoshub-after-add.png b/website/docs/assets/concepts/chaoshub/chaoshub-after-add.png
index 22953ecd..7df0b8d4 100644
Binary files a/website/docs/assets/concepts/chaoshub/chaoshub-after-add.png and b/website/docs/assets/concepts/chaoshub/chaoshub-after-add.png differ
diff --git a/website/docs/assets/concepts/chaoshub/chaoshub-chaos-charts.png b/website/docs/assets/concepts/chaoshub/chaoshub-chaos-charts.png
index b69906eb..4a2cc116 100644
Binary files a/website/docs/assets/concepts/chaoshub/chaoshub-chaos-charts.png and b/website/docs/assets/concepts/chaoshub/chaoshub-chaos-charts.png differ
diff --git a/website/docs/assets/concepts/chaoshub/chaoshub-default.png b/website/docs/assets/concepts/chaoshub/chaoshub-default.png
index bec9a147..9ed1fbaa 100644
Binary files a/website/docs/assets/concepts/chaoshub/chaoshub-default.png and b/website/docs/assets/concepts/chaoshub/chaoshub-default.png differ
diff --git a/website/docs/assets/concepts/chaoshub/chaoshub-exp-details.png b/website/docs/assets/concepts/chaoshub/chaoshub-exp-details.png
index 69465277..74b42fd6 100644
Binary files a/website/docs/assets/concepts/chaoshub/chaoshub-exp-details.png and b/website/docs/assets/concepts/chaoshub/chaoshub-exp-details.png differ
diff --git a/website/docs/assets/concepts/chaoshub/chaoshub-predefined-experiments.png b/website/docs/assets/concepts/chaoshub/chaoshub-predefined-experiments.png
new file mode 100644
index 00000000..ba0ebd2f
Binary files /dev/null and b/website/docs/assets/concepts/chaoshub/chaoshub-predefined-experiments.png differ
diff --git a/website/docs/assets/concepts/chaoshub/chaoshub-predefined-wf.png b/website/docs/assets/concepts/chaoshub/chaoshub-predefined-wf.png
deleted file mode 100644
index 513136a3..00000000
Binary files a/website/docs/assets/concepts/chaoshub/chaoshub-predefined-wf.png and /dev/null differ
diff --git a/website/docs/assets/landing-page.png b/website/docs/assets/landing-page.png
index 9fb49bc4..277a1730 100644
Binary files a/website/docs/assets/landing-page.png and b/website/docs/assets/landing-page.png differ
diff --git a/website/docs/assets/login.png b/website/docs/assets/login.png
index b1acc1fc..b105e7d6 100644
Binary files a/website/docs/assets/login.png and b/website/docs/assets/login.png differ
diff --git a/website/docs/assets/user-guides/gitops/gitops-config.png b/website/docs/assets/user-guides/gitops/gitops-config.png
index 3ed5fa50..b270e7a4 100644
Binary files a/website/docs/assets/user-guides/gitops/gitops-config.png and b/website/docs/assets/user-guides/gitops/gitops-config.png differ
diff --git a/website/docs/assets/user-guides/gitops/gitops.png b/website/docs/assets/user-guides/gitops/gitops.png
index 7b99b0e7..a70b076c 100644
Binary files a/website/docs/assets/user-guides/gitops/gitops.png and b/website/docs/assets/user-guides/gitops/gitops.png differ
diff --git a/website/docs/assets/user-guides/image-registry/img-registry-tab.png b/website/docs/assets/user-guides/image-registry/img-registry-tab.png
index 1d7e8c53..b5ecc8c6 100644
Binary files a/website/docs/assets/user-guides/image-registry/img-registry-tab.png and b/website/docs/assets/user-guides/image-registry/img-registry-tab.png differ
diff --git a/website/docs/assets/user-guides/image-registry/img-registry-update.png b/website/docs/assets/user-guides/image-registry/img-registry-update.png
index df7a5e58..15c7955d 100644
Binary files a/website/docs/assets/user-guides/image-registry/img-registry-update.png and b/website/docs/assets/user-guides/image-registry/img-registry-update.png differ
diff --git a/website/docs/assets/user-guides/image-registry/img-registry-updated.png b/website/docs/assets/user-guides/image-registry/img-registry-updated.png
index 12688983..86a1a53f 100644
Binary files a/website/docs/assets/user-guides/image-registry/img-registry-updated.png and b/website/docs/assets/user-guides/image-registry/img-registry-updated.png differ
diff --git a/website/docs/assets/user-guides/injecting-fault/delete-workflow/step-1.png b/website/docs/assets/user-guides/injecting-fault/delete-workflow/step-1.png
index 0eeac428..c2fefdc0 100644
Binary files a/website/docs/assets/user-guides/injecting-fault/delete-workflow/step-1.png and b/website/docs/assets/user-guides/injecting-fault/delete-workflow/step-1.png differ
diff --git a/website/docs/assets/user-guides/injecting-fault/delete-workflow/step-2.png b/website/docs/assets/user-guides/injecting-fault/delete-workflow/step-2.png
index bbfdbe1b..73559664 100644
Binary files a/website/docs/assets/user-guides/injecting-fault/delete-workflow/step-2.png and b/website/docs/assets/user-guides/injecting-fault/delete-workflow/step-2.png differ
diff --git a/website/docs/assets/user-guides/injecting-fault/delete-workflow/step-3.png b/website/docs/assets/user-guides/injecting-fault/delete-workflow/step-3.png
index 4bc55353..22ede174 100644
Binary files a/website/docs/assets/user-guides/injecting-fault/delete-workflow/step-3.png and b/website/docs/assets/user-guides/injecting-fault/delete-workflow/step-3.png differ
diff --git a/website/docs/assets/user-guides/injecting-fault/delete-workflow/step-4.png b/website/docs/assets/user-guides/injecting-fault/delete-workflow/step-4.png
deleted file mode 100644
index b9ccd6ae..00000000
Binary files a/website/docs/assets/user-guides/injecting-fault/delete-workflow/step-4.png and /dev/null differ
diff --git a/website/docs/assets/user-guides/injecting-fault/edit-schedule/edit-schedule-page.png b/website/docs/assets/user-guides/injecting-fault/edit-schedule/edit-schedule-page.png
index 6bd1fe10..eaad8174 100644
Binary files a/website/docs/assets/user-guides/injecting-fault/edit-schedule/edit-schedule-page.png and b/website/docs/assets/user-guides/injecting-fault/edit-schedule/edit-schedule-page.png differ
diff --git a/website/docs/assets/user-guides/injecting-fault/edit-schedule/edit-schedule.png b/website/docs/assets/user-guides/injecting-fault/edit-schedule/edit-schedule.png
index 528c4f22..d7498869 100644
Binary files a/website/docs/assets/user-guides/injecting-fault/edit-schedule/edit-schedule.png and b/website/docs/assets/user-guides/injecting-fault/edit-schedule/edit-schedule.png differ
diff --git a/website/docs/assets/user-guides/injecting-fault/edit-schedule/schedule-menu.png b/website/docs/assets/user-guides/injecting-fault/edit-schedule/schedule-menu.png
index 47909d63..00d6621c 100644
Binary files a/website/docs/assets/user-guides/injecting-fault/edit-schedule/schedule-menu.png and b/website/docs/assets/user-guides/injecting-fault/edit-schedule/schedule-menu.png differ
diff --git a/website/docs/assets/user-guides/injecting-fault/re-run-workflow/step-1.png b/website/docs/assets/user-guides/injecting-fault/re-run-workflow/step-1.png
index c57d2f4a..dd6aaf60 100644
Binary files a/website/docs/assets/user-guides/injecting-fault/re-run-workflow/step-1.png and b/website/docs/assets/user-guides/injecting-fault/re-run-workflow/step-1.png differ
diff --git a/website/docs/assets/user-guides/injecting-fault/re-run-workflow/step-2.png b/website/docs/assets/user-guides/injecting-fault/re-run-workflow/step-2.png
index b1f1ffe6..fbf72596 100644
Binary files a/website/docs/assets/user-guides/injecting-fault/re-run-workflow/step-2.png and b/website/docs/assets/user-guides/injecting-fault/re-run-workflow/step-2.png differ
diff --git a/website/docs/assets/user-guides/injecting-fault/schedule-workflow/add-experiments.png b/website/docs/assets/user-guides/injecting-fault/schedule-workflow/add-experiments.png
deleted file mode 100644
index 8eba3d4c..00000000
Binary files a/website/docs/assets/user-guides/injecting-fault/schedule-workflow/add-experiments.png and /dev/null differ
diff --git a/website/docs/assets/user-guides/injecting-fault/schedule-workflow/add-parallel-faults.png b/website/docs/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/docs/assets/user-guides/injecting-fault/schedule-workflow/add-parallel-faults.png differ
diff --git a/website/docs/assets/user-guides/injecting-fault/schedule-workflow/adjust-weights.png b/website/docs/assets/user-guides/injecting-fault/schedule-workflow/adjust-weights.png
deleted file mode 100644
index a196957b..00000000
Binary files a/website/docs/assets/user-guides/injecting-fault/schedule-workflow/adjust-weights.png and /dev/null differ
diff --git a/website/docs/assets/user-guides/injecting-fault/schedule-workflow/advanced-options-experiment-creation.png b/website/docs/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/docs/assets/user-guides/injecting-fault/schedule-workflow/advanced-options-experiment-creation.png differ
diff --git a/website/docs/assets/user-guides/injecting-fault/schedule-workflow/chaos-experiment-save.png b/website/docs/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/docs/assets/user-guides/injecting-fault/schedule-workflow/chaos-experiment-save.png differ
diff --git a/website/docs/assets/user-guides/injecting-fault/schedule-workflow/choose-workflow.png b/website/docs/assets/user-guides/injecting-fault/schedule-workflow/choose-workflow.png
deleted file mode 100644
index b4e11ac8..00000000
Binary files a/website/docs/assets/user-guides/injecting-fault/schedule-workflow/choose-workflow.png and /dev/null differ
diff --git a/website/docs/assets/user-guides/injecting-fault/schedule-workflow/edit-predefined-workflow.png b/website/docs/assets/user-guides/injecting-fault/schedule-workflow/edit-predefined-workflow.png
deleted file mode 100644
index 72c88e16..00000000
Binary files a/website/docs/assets/user-guides/injecting-fault/schedule-workflow/edit-predefined-workflow.png and /dev/null differ
diff --git a/website/docs/assets/user-guides/injecting-fault/schedule-workflow/edit-sequence.png b/website/docs/assets/user-guides/injecting-fault/schedule-workflow/edit-sequence.png
deleted file mode 100644
index 131c9da1..00000000
Binary files a/website/docs/assets/user-guides/injecting-fault/schedule-workflow/edit-sequence.png and /dev/null differ
diff --git a/website/docs/assets/user-guides/injecting-fault/schedule-workflow/home-schedule-button.png b/website/docs/assets/user-guides/injecting-fault/schedule-workflow/home-schedule-button.png
deleted file mode 100644
index c714411e..00000000
Binary files a/website/docs/assets/user-guides/injecting-fault/schedule-workflow/home-schedule-button.png and /dev/null differ
diff --git a/website/docs/assets/user-guides/injecting-fault/schedule-workflow/litmus-chaos-hub.png b/website/docs/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/docs/assets/user-guides/injecting-fault/schedule-workflow/litmus-chaos-hub.png differ
diff --git a/website/docs/assets/user-guides/injecting-fault/schedule-workflow/new-experiment-blank-canvas.png b/website/docs/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/docs/assets/user-guides/injecting-fault/schedule-workflow/new-experiment-blank-canvas.png differ
diff --git a/website/docs/assets/user-guides/injecting-fault/schedule-workflow/new-experiment-choose-method.png b/website/docs/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/docs/assets/user-guides/injecting-fault/schedule-workflow/new-experiment-choose-method.png differ
diff --git a/website/docs/assets/user-guides/injecting-fault/schedule-workflow/new-experiment-identifiers.png b/website/docs/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/docs/assets/user-guides/injecting-fault/schedule-workflow/new-experiment-identifiers.png differ
diff --git a/website/docs/assets/user-guides/injecting-fault/schedule-workflow/new-experiment-infra-select.png b/website/docs/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/docs/assets/user-guides/injecting-fault/schedule-workflow/new-experiment-infra-select.png differ
diff --git a/website/docs/assets/user-guides/injecting-fault/schedule-workflow/new-experiment-overview-home.png b/website/docs/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/docs/assets/user-guides/injecting-fault/schedule-workflow/new-experiment-overview-home.png differ
diff --git a/website/docs/assets/user-guides/injecting-fault/schedule-workflow/node-selectors.png b/website/docs/assets/user-guides/injecting-fault/schedule-workflow/node-selectors.png
new file mode 100644
index 00000000..42fc903f
Binary files /dev/null and b/website/docs/assets/user-guides/injecting-fault/schedule-workflow/node-selectors.png differ
diff --git a/website/docs/assets/user-guides/injecting-fault/schedule-workflow/schedule.png b/website/docs/assets/user-guides/injecting-fault/schedule-workflow/schedule.png
deleted file mode 100644
index 715d4530..00000000
Binary files a/website/docs/assets/user-guides/injecting-fault/schedule-workflow/schedule.png and /dev/null differ
diff --git a/website/docs/assets/user-guides/injecting-fault/schedule-workflow/select-agent.png b/website/docs/assets/user-guides/injecting-fault/schedule-workflow/select-agent.png
deleted file mode 100644
index 94452774..00000000
Binary files a/website/docs/assets/user-guides/injecting-fault/schedule-workflow/select-agent.png and /dev/null differ
diff --git a/website/docs/assets/user-guides/injecting-fault/schedule-workflow/select-template-from-chaos-hub.png b/website/docs/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/docs/assets/user-guides/injecting-fault/schedule-workflow/select-template-from-chaos-hub.png differ
diff --git a/website/docs/assets/user-guides/injecting-fault/schedule-workflow/target-selection.png b/website/docs/assets/user-guides/injecting-fault/schedule-workflow/target-selection.png
deleted file mode 100644
index 65f776fd..00000000
Binary files a/website/docs/assets/user-guides/injecting-fault/schedule-workflow/target-selection.png and /dev/null differ
diff --git a/website/docs/assets/user-guides/injecting-fault/schedule-workflow/tolerations.png b/website/docs/assets/user-guides/injecting-fault/schedule-workflow/tolerations.png
new file mode 100644
index 00000000..5d915a37
Binary files /dev/null and b/website/docs/assets/user-guides/injecting-fault/schedule-workflow/tolerations.png differ
diff --git a/website/docs/assets/user-guides/injecting-fault/schedule-workflow/tune-fault.png b/website/docs/assets/user-guides/injecting-fault/schedule-workflow/tune-fault.png
new file mode 100644
index 00000000..1d6a9c65
Binary files /dev/null and b/website/docs/assets/user-guides/injecting-fault/schedule-workflow/tune-fault.png differ
diff --git a/website/docs/assets/user-guides/injecting-fault/schedule-workflow/verify-commit.png b/website/docs/assets/user-guides/injecting-fault/schedule-workflow/verify-commit.png
deleted file mode 100644
index 2562f853..00000000
Binary files a/website/docs/assets/user-guides/injecting-fault/schedule-workflow/verify-commit.png and /dev/null differ
diff --git a/website/docs/assets/user-guides/injecting-fault/schedule-workflow/workflow-setting.png b/website/docs/assets/user-guides/injecting-fault/schedule-workflow/workflow-setting.png
deleted file mode 100644
index 56dabcd4..00000000
Binary files a/website/docs/assets/user-guides/injecting-fault/schedule-workflow/workflow-setting.png and /dev/null differ
diff --git a/website/docs/assets/user-guides/managing-projects/change-project-name/step-1.png b/website/docs/assets/user-guides/managing-projects/change-project-name/step-1.png
index 26402e52..817a90ef 100644
Binary files a/website/docs/assets/user-guides/managing-projects/change-project-name/step-1.png and b/website/docs/assets/user-guides/managing-projects/change-project-name/step-1.png differ
diff --git a/website/docs/assets/user-guides/managing-projects/change-project-name/step-2.png b/website/docs/assets/user-guides/managing-projects/change-project-name/step-2.png
index cf396809..50f6f7df 100644
Binary files a/website/docs/assets/user-guides/managing-projects/change-project-name/step-2.png and b/website/docs/assets/user-guides/managing-projects/change-project-name/step-2.png differ
diff --git a/website/docs/assets/user-guides/managing-projects/change-project-name/step-3.png b/website/docs/assets/user-guides/managing-projects/change-project-name/step-3.png
index d54f999a..c383dafd 100644
Binary files a/website/docs/assets/user-guides/managing-projects/change-project-name/step-3.png and b/website/docs/assets/user-guides/managing-projects/change-project-name/step-3.png differ
diff --git a/website/docs/assets/user-guides/managing-projects/leave-project/step-1.png b/website/docs/assets/user-guides/managing-projects/leave-project/step-1.png
index cfd0d161..44c570f0 100644
Binary files a/website/docs/assets/user-guides/managing-projects/leave-project/step-1.png and b/website/docs/assets/user-guides/managing-projects/leave-project/step-1.png differ
diff --git a/website/docs/assets/user-guides/managing-projects/leave-project/step-2.png b/website/docs/assets/user-guides/managing-projects/leave-project/step-2.png
index e274cf2d..821cbf67 100644
Binary files a/website/docs/assets/user-guides/managing-projects/leave-project/step-2.png and b/website/docs/assets/user-guides/managing-projects/leave-project/step-2.png differ
diff --git a/website/docs/assets/user-guides/my-account/step-1.png b/website/docs/assets/user-guides/my-account/step-1.png
index 82ddeeb3..e0a55bb9 100644
Binary files a/website/docs/assets/user-guides/my-account/step-1.png and b/website/docs/assets/user-guides/my-account/step-1.png differ
diff --git a/website/docs/assets/user-guides/my-account/step-2.png b/website/docs/assets/user-guides/my-account/step-2.png
index 6ab4ec95..b5f5a0e4 100644
Binary files a/website/docs/assets/user-guides/my-account/step-2.png and b/website/docs/assets/user-guides/my-account/step-2.png differ
diff --git a/website/docs/assets/user-guides/my-account/step-3.png b/website/docs/assets/user-guides/my-account/step-3.png
index 7a9e8b83..ca1b7f59 100644
Binary files a/website/docs/assets/user-guides/my-account/step-3.png and b/website/docs/assets/user-guides/my-account/step-3.png differ
diff --git a/website/docs/assets/user-guides/my-account/step-4.png b/website/docs/assets/user-guides/my-account/step-4.png
index 485650cd..04d93133 100644
Binary files a/website/docs/assets/user-guides/my-account/step-4.png and b/website/docs/assets/user-guides/my-account/step-4.png differ
diff --git a/website/docs/assets/user-guides/my-account/step-5.png b/website/docs/assets/user-guides/my-account/step-5.png
new file mode 100644
index 00000000..f59da1cd
Binary files /dev/null and b/website/docs/assets/user-guides/my-account/step-5.png differ
diff --git a/website/docs/assets/user-guides/resilience-probes/create-probe/step-1.png b/website/docs/assets/user-guides/resilience-probes/create-probe/step-1.png
new file mode 100644
index 00000000..53277c1c
Binary files /dev/null and b/website/docs/assets/user-guides/resilience-probes/create-probe/step-1.png differ
diff --git a/website/docs/assets/user-guides/resilience-probes/create-probe/step-2.png b/website/docs/assets/user-guides/resilience-probes/create-probe/step-2.png
new file mode 100644
index 00000000..c11a10e8
Binary files /dev/null and b/website/docs/assets/user-guides/resilience-probes/create-probe/step-2.png differ
diff --git a/website/docs/assets/user-guides/resilience-probes/create-probe/step-3.png b/website/docs/assets/user-guides/resilience-probes/create-probe/step-3.png
new file mode 100644
index 00000000..3738ae82
Binary files /dev/null and b/website/docs/assets/user-guides/resilience-probes/create-probe/step-3.png differ
diff --git a/website/docs/assets/user-guides/resilience-probes/create-probe/step-4.png b/website/docs/assets/user-guides/resilience-probes/create-probe/step-4.png
new file mode 100644
index 00000000..5c5d95e4
Binary files /dev/null and b/website/docs/assets/user-guides/resilience-probes/create-probe/step-4.png differ
diff --git a/website/docs/assets/user-guides/resilience-probes/create-probe/step-5.png b/website/docs/assets/user-guides/resilience-probes/create-probe/step-5.png
new file mode 100644
index 00000000..330f9543
Binary files /dev/null and b/website/docs/assets/user-guides/resilience-probes/create-probe/step-5.png differ
diff --git a/website/docs/assets/user-guides/resilience-probes/create-probe/step-6.png b/website/docs/assets/user-guides/resilience-probes/create-probe/step-6.png
new file mode 100644
index 00000000..acb5ece4
Binary files /dev/null and b/website/docs/assets/user-guides/resilience-probes/create-probe/step-6.png differ
diff --git a/website/docs/assets/user-guides/resilience-probes/delete-probe/step-1.png b/website/docs/assets/user-guides/resilience-probes/delete-probe/step-1.png
new file mode 100644
index 00000000..26eb2f09
Binary files /dev/null and b/website/docs/assets/user-guides/resilience-probes/delete-probe/step-1.png differ
diff --git a/website/docs/assets/user-guides/resilience-probes/delete-probe/step-2.png b/website/docs/assets/user-guides/resilience-probes/delete-probe/step-2.png
new file mode 100644
index 00000000..d6714c1c
Binary files /dev/null and b/website/docs/assets/user-guides/resilience-probes/delete-probe/step-2.png differ
diff --git a/website/docs/assets/user-guides/resilience-probes/delete-probe/step-3.png b/website/docs/assets/user-guides/resilience-probes/delete-probe/step-3.png
new file mode 100644
index 00000000..c1d60b56
Binary files /dev/null and b/website/docs/assets/user-guides/resilience-probes/delete-probe/step-3.png differ
diff --git a/website/docs/assets/user-guides/resilience-probes/edit-probe/step-1.png b/website/docs/assets/user-guides/resilience-probes/edit-probe/step-1.png
new file mode 100644
index 00000000..d9657006
Binary files /dev/null and b/website/docs/assets/user-guides/resilience-probes/edit-probe/step-1.png differ
diff --git a/website/docs/assets/user-guides/resilience-probes/edit-probe/step-2.png b/website/docs/assets/user-guides/resilience-probes/edit-probe/step-2.png
new file mode 100644
index 00000000..574e2c9b
Binary files /dev/null and b/website/docs/assets/user-guides/resilience-probes/edit-probe/step-2.png differ
diff --git a/website/docs/assets/user-guides/resilience-probes/edit-probe/step-3.png b/website/docs/assets/user-guides/resilience-probes/edit-probe/step-3.png
new file mode 100644
index 00000000..573c18cb
Binary files /dev/null and b/website/docs/assets/user-guides/resilience-probes/edit-probe/step-3.png differ
diff --git a/website/docs/assets/user-guides/resilience-probes/view-probe/step-1.png b/website/docs/assets/user-guides/resilience-probes/view-probe/step-1.png
new file mode 100644
index 00000000..a0767f90
Binary files /dev/null and b/website/docs/assets/user-guides/resilience-probes/view-probe/step-1.png differ
diff --git a/website/docs/assets/user-guides/resilience-probes/view-probe/step-2.png b/website/docs/assets/user-guides/resilience-probes/view-probe/step-2.png
new file mode 100644
index 00000000..209ff6ae
Binary files /dev/null and b/website/docs/assets/user-guides/resilience-probes/view-probe/step-2.png differ
diff --git a/website/docs/assets/user-guides/resilience-probes/view-probe/step-3.png b/website/docs/assets/user-guides/resilience-probes/view-probe/step-3.png
new file mode 100644
index 00000000..b1d73599
Binary files /dev/null and b/website/docs/assets/user-guides/resilience-probes/view-probe/step-3.png differ
diff --git a/website/docs/assets/user-guides/teaming/accept-invite/step-1.png b/website/docs/assets/user-guides/teaming/accept-invite/step-1.png
index e71493e7..bc0f1a02 100644
Binary files a/website/docs/assets/user-guides/teaming/accept-invite/step-1.png and b/website/docs/assets/user-guides/teaming/accept-invite/step-1.png differ
diff --git a/website/docs/assets/user-guides/teaming/accept-invite/step-2.png b/website/docs/assets/user-guides/teaming/accept-invite/step-2.png
index 3f145251..5dbf0ec4 100644
Binary files a/website/docs/assets/user-guides/teaming/accept-invite/step-2.png and b/website/docs/assets/user-guides/teaming/accept-invite/step-2.png differ
diff --git a/website/docs/assets/user-guides/teaming/edit-invite/step-1.png b/website/docs/assets/user-guides/teaming/edit-invite/step-1.png
index efcf214d..7be1d24e 100644
Binary files a/website/docs/assets/user-guides/teaming/edit-invite/step-1.png and b/website/docs/assets/user-guides/teaming/edit-invite/step-1.png differ
diff --git a/website/docs/assets/user-guides/teaming/invite-team-member/step-1.png b/website/docs/assets/user-guides/teaming/invite-team-member/step-1.png
index 1ebddbcc..619578d7 100644
Binary files a/website/docs/assets/user-guides/teaming/invite-team-member/step-1.png and b/website/docs/assets/user-guides/teaming/invite-team-member/step-1.png differ
diff --git a/website/docs/assets/user-guides/teaming/invite-team-member/step-2.png b/website/docs/assets/user-guides/teaming/invite-team-member/step-2.png
index cf3ed820..63bd8398 100644
Binary files a/website/docs/assets/user-guides/teaming/invite-team-member/step-2.png and b/website/docs/assets/user-guides/teaming/invite-team-member/step-2.png differ
diff --git a/website/docs/assets/user-guides/teaming/invite-team-member/step-3.png b/website/docs/assets/user-guides/teaming/invite-team-member/step-3.png
deleted file mode 100644
index 9aa08475..00000000
Binary files a/website/docs/assets/user-guides/teaming/invite-team-member/step-3.png and /dev/null differ
diff --git a/website/docs/assets/user-guides/teaming/remove-team-member/step-1.png b/website/docs/assets/user-guides/teaming/remove-team-member/step-1.png
index e3206087..2abdae92 100644
Binary files a/website/docs/assets/user-guides/teaming/remove-team-member/step-1.png and b/website/docs/assets/user-guides/teaming/remove-team-member/step-1.png differ
diff --git a/website/docs/assets/user-guides/teaming/remove-team-member/step-2.png b/website/docs/assets/user-guides/teaming/remove-team-member/step-2.png
index a8fbc5c6..763a923f 100644
Binary files a/website/docs/assets/user-guides/teaming/remove-team-member/step-2.png and b/website/docs/assets/user-guides/teaming/remove-team-member/step-2.png differ
diff --git a/website/docs/assets/user-guides/user-management/create-user/step-1.png b/website/docs/assets/user-guides/user-management/create-user/step-1.png
index 403bdae3..bf97a3f7 100644
Binary files a/website/docs/assets/user-guides/user-management/create-user/step-1.png and b/website/docs/assets/user-guides/user-management/create-user/step-1.png differ
diff --git a/website/docs/assets/user-guides/user-management/create-user/step-2.png b/website/docs/assets/user-guides/user-management/create-user/step-2.png
index f5872073..e40b11be 100644
Binary files a/website/docs/assets/user-guides/user-management/create-user/step-2.png and b/website/docs/assets/user-guides/user-management/create-user/step-2.png differ
diff --git a/website/docs/assets/user-guides/user-management/create-user/step-3.png b/website/docs/assets/user-guides/user-management/create-user/step-3.png
index 4b603e7c..eac68c99 100644
Binary files a/website/docs/assets/user-guides/user-management/create-user/step-3.png and b/website/docs/assets/user-guides/user-management/create-user/step-3.png differ
diff --git a/website/docs/assets/user-guides/user-management/deactivate-user/step-1.png b/website/docs/assets/user-guides/user-management/deactivate-user/step-1.png
index 5da567a2..413ac2d9 100644
Binary files a/website/docs/assets/user-guides/user-management/deactivate-user/step-1.png and b/website/docs/assets/user-guides/user-management/deactivate-user/step-1.png differ
diff --git a/website/docs/assets/user-guides/user-management/deactivate-user/step-2.png b/website/docs/assets/user-guides/user-management/deactivate-user/step-2.png
index 59adbed9..8f83055a 100644
Binary files a/website/docs/assets/user-guides/user-management/deactivate-user/step-2.png and b/website/docs/assets/user-guides/user-management/deactivate-user/step-2.png differ
diff --git a/website/docs/assets/user-guides/user-management/deactivate-user/step-3.png b/website/docs/assets/user-guides/user-management/deactivate-user/step-3.png
index 0f535117..df0d1f13 100644
Binary files a/website/docs/assets/user-guides/user-management/deactivate-user/step-3.png and b/website/docs/assets/user-guides/user-management/deactivate-user/step-3.png differ
diff --git a/website/docs/assets/user-guides/user-management/reset-password/step-1.png b/website/docs/assets/user-guides/user-management/reset-password/step-1.png
index 9b48f094..1d0474f4 100644
Binary files a/website/docs/assets/user-guides/user-management/reset-password/step-1.png and b/website/docs/assets/user-guides/user-management/reset-password/step-1.png differ
diff --git a/website/docs/assets/user-guides/user-management/reset-password/step-2.png b/website/docs/assets/user-guides/user-management/reset-password/step-2.png
index 13ae9073..c1b98676 100644
Binary files a/website/docs/assets/user-guides/user-management/reset-password/step-2.png and b/website/docs/assets/user-guides/user-management/reset-password/step-2.png differ
diff --git a/website/docs/assets/user-guides/user-management/view-user/step-1.png b/website/docs/assets/user-guides/user-management/view-user/step-1.png
index a011063b..19fc30e9 100644
Binary files a/website/docs/assets/user-guides/user-management/view-user/step-1.png and b/website/docs/assets/user-guides/user-management/view-user/step-1.png differ
diff --git a/website/docs/assets/workflow-observe-completed.png b/website/docs/assets/workflow-observe-completed.png
new file mode 100644
index 00000000..cb29658e
Binary files /dev/null and b/website/docs/assets/workflow-observe-completed.png differ
diff --git a/website/docs/assets/workflow-observe-log.png b/website/docs/assets/workflow-observe-log.png
index 3f131d54..c2fd5c71 100644
Binary files a/website/docs/assets/workflow-observe-log.png and b/website/docs/assets/workflow-observe-log.png differ
diff --git a/website/docs/assets/workflow-observe-running.png b/website/docs/assets/workflow-observe-running.png
index 263ecf1e..f4a93b10 100644
Binary files a/website/docs/assets/workflow-observe-running.png and b/website/docs/assets/workflow-observe-running.png differ
diff --git a/website/docs/assets/workflow-observe-select.png b/website/docs/assets/workflow-observe-select.png
index bd3c5901..7b6d4374 100644
Binary files a/website/docs/assets/workflow-observe-select.png and b/website/docs/assets/workflow-observe-select.png differ
diff --git a/website/docs/concepts/app-infra-monitoring.md b/website/docs/concepts/app-infra-monitoring.md
deleted file mode 100644
index 63291d3b..00000000
--- a/website/docs/concepts/app-infra-monitoring.md
+++ /dev/null
@@ -1,75 +0,0 @@
----
-id: app-infra-monitoring
-title: Monitor Chaos in your Application/Infrastructure
-sidebar_label: Application/Infra Monitoring
----
-
----
-
-Application OR Infra dashboards provide a way to monitor the chaos impact on application resources, services or cloud infrastructure from within the ChaosCenter. They are user-defined and offer a way to observe systems on Chaos Delegate’s cluster in the specified scope (Cluster or Namespace)
-
-These dashboards are associated with Chaos Delegate(s) and consume a specific Prometheus data source connected to a project in ChaosCenter to display chaos events, verdicts and metrics for cloud resources.
-
-## Prerequisites
-
-The following should be required before knowing about application or infrastructure monitoring using chaos center:
-
-- [Data Source](datasource.md)
-- [Chaos Scenario](chaos-workflow.md)
-
-## Data flow architecture
-
-The chaos center automatically gives the functionality to create dashboards for chaos delegates registered under a project and provides chaos interleaved monitoring of services and targets for both applications and underlying infrastructure. Litmus follows an open observability model which enables users to plug metrics from any Prometheus exporter into the data source connected to a chaos center project to visualize the same on dashboards. Some of the standard metrics include `kube-state-metrics` and `node-exporter-metrics` to monitor Kubernetes and infrastructure. Similarly many applications expose metrics that can be scraped via Prometheus or have standard exporters to expose the same. The `prometheus-black-box-exporter` can also be used to collect basic application metrics running on Kubernetes.
-
-
-
-Data flow for application and infrastructure monitoring
-
-
-## Interleaving chaos events and metrics
-
-Litmus Chaos delegate comprises several components, one of them being the [chaos-exporter](https://github.com/litmuschaos/chaos-exporter) It is a Prometheus exporter for event and gauge metrics generated as chaos engine events and chaos experiment verdict during fault injection using the Litmus chaos operator. Two important prometheus metrics being `litmuschaos_awaited_experiments` and `litmuschaos_experiment_verdict` These two metrics are consumed for each chaos delegate monitoring dashboard in a Chaos center project. They are pulled from the data source and then transformed to generate a single metric patched with details from both. The final metric is visualized as an enclosed area on every graph panel on a monitoring dashboard in view.
-
-Whenever a fault is injected the starting point of the enclosed area marks the time of first chaos injection after the pre-chaos check completes. Sequential injections from a single chaos engine are combined together to form a single event enclosure to give the viewer a cleaner projection of the chaos interval overlaid on top of the metrics from application resource, service or underlying infrastructure being monitored. The end marker represents the end of the chaos injection phase. The user can hover on the enclosed area after expanding the graph view to make use of the integrated `Chaos metric info` table on the graph panel where metadata of the AUT, chaos experiment, engine, chaos scenario and results like probe success percentage and verdict are logged which are updated with each iteration of chaos injection based on a defined chaos engine. Hovering over different enclosures allows users to browse chaos injections independently.
-
-The identity of each chaos injection for Chaos center is the `chaosresult_name` parsed from the labels of both the event metric and the verdict metric as a consistent legend name. This forms the basis of updates on the chaos injection and patching of verdict to a chaos event enclosure. Litmus center uses an algorithm to update all the chaos metric table information based on the field name and the timestamp of chaos injection associated with it for each event based on its corresponding verdict.
-
-Both chaos event query and chaos verdict queries can be updated from the Chaos center UI based on metric collection methods and Prometheus data source configuration, provided the legend `chaosresult_name` is always available as a label to both the metrics, to be used by the ETL pipeline for ensuring that the chaos interleaving algorithm works impeccably for all fault injections on the chaos delegate cluster.
-
-> Default chaos event query
-
-```json
-litmuschaos_awaited_experiments{job="chaos-exporter", chaos_injection_time!="", instance="chaos-exporter-service"}
-```
-
-> Default chaos verdict query
-
-```json
-litmuschaos_experiment_verdict{job="chaos-exporter", chaosresult_verdict!="Awaited", instance="chaos-exporter-service"}
-```
-
-The central chaos table on the dashboard level above the graph panels shows an aggregate view of all the faults injected during the time interval set while browsing the dashboard. The fields of the table being, `Chaos result name`, `Chaos Scenario`, `Engine context` and `Verdict`. The `Verdict` shows only the verdict of the latest fault injection associated with a `Chaos result name`. In order to browse all the verdicts associated and more data fields of the particular fault injection, the user can hover over the enclosure on any expanded graph panel and view it on the integrated `Chaos metric info` table.
-
-## Schema for monitoring dashboards
-
-The monitoring dashboards in chaos center follow a definite structure as a JSON. The diagram below shows a pictorial representation of the same.
-
-
-
-JSON schema for monitoring dashboards
-
-
-[Raw JSON](https://raw.githubusercontent.com/litmuschaos/litmus/master/monitoring/portal-dashboards/schema.json)
-
-## Summary
-
-Building a hypothesis around steady-state behaviour, varying real-world events, running experiments in production, automating them to run as a chaos scenario in CI pipelines, and minimizing the blast radius are some advanced chaos practices. These are all backed by extensive monitoring infrastructure managed by SREs heading IT operations. Monitoring chaos and performance metrics is an observability paradigm providing real-time insights into the four golden signals for monitoring distributed systems namely, latency, traffic, errors, and saturation. LitmusChaos facilitates real-time monitoring for `events` and `verdicts` using a 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. Litmus also provides in-house monitoring support with interleaved dashboards on chaos center which can be shared across teams.
-
-## Resources
-
-
-
-## Learn More
-
-- [Observe a Chaos Scenario](visualize-workflow.md)
-- [Chaos Scenario Statistics](workflow-statistics.md)
diff --git a/website/docs/concepts/chaos-engine.md b/website/docs/concepts/chaos-engine.md
deleted file mode 100644
index cfe24b36..00000000
--- a/website/docs/concepts/chaos-engine.md
+++ /dev/null
@@ -1,912 +0,0 @@
----
-id: chaos-engine
-title: ChaosEngine
-sidebar_label: ChaosEngine
----
-
----
-
-The ChaosEngine CR is the main user-facing chaos custom resource with a namespace scope and is designed to hold information around how the chaos experiments are executed. 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 status of the chaos experiments, making it the single source of truth with respect to the chaos.
-
-## Prerequisites
-
-To understand the concepts of ChaosEngine better make sure you are aware of the Chaos Experiment Custom Resources
-
-## ChaosEngine
-
-### State Specification
-
-This section describes the fields in the ChaosEngine spec and the possible values that can be set against the same.
-
-
-
-
Field
-
.spec.engineState
-
-
-
Description
-
Flag to control the state of the chaosengine
-
-
-
Type
-
Mandatory
-
-
-
Range
-
active, stop
-
-
-
Default
-
active
-
-
-
Notes
-
The engineState in the spec is a user defined flag to trigger chaos. Setting it to active ensures successful execution of chaos. Patching it with stop aborts ongoing experiments. It has a corresponding flag in the chaosengine status field, called engineStatus which is updated by the controller based on actual state of the ChaosEngine.
-
-
-
-### Application Specification
-
-
-
-
Field
-
.spec.appinfo.appns
-
-
-
Description
-
Flag to specify namespace of application under test
-
-
-
Type
-
Optional
-
-
-
Range
-
user-defined (type: string)
-
-
-
Default
-
n/a
-
-
-
Notes
-
The appns in the spec specifies the namespace of the AUT. Usually provided as a quoted string. It is optional for the infra chaos.
-
-
-
-
-
-
Field
-
.spec.appinfo.applabel
-
-
-
Description
-
Flag to specify unique label of application under test
The applabel in the spec specifies a unique label of the AUT. Usually provided as a quoted string of pattern key=value. Note that if multiple applications share the same label within a given namespace, the AUT is filtered based on the presence of the chaos annotation litmuschaos.io/chaos: "true". If, however, the annotationCheck is disabled, then a random application (pod) sharing the specified label is selected for chaos. It is optional for the infra chaos.
-
-
-
-
-
-
Field
-
.spec.appinfo.appkind
-
-
-
Description
-
Flag to specify resource kind of application under test
The appkind in the spec specifies the Kubernetes resource type of the app deployment. The Litmus ChaosOperator supports chaos on deployments, statefulsets and daemonsets. Application health check routines are dependent on the resource types, in case of some experiments. It is optional for the infra chaos
-
-
-
-
-
-
Field
-
.spec.auxiliaryAppInfo
-
-
-
Description
-
Flag to specify one or more app namespace-label pairs whose health is also monitored as part of the chaos experiment, in addition to a primary application specified in the .spec.appInfo. NOTE: If the auxiliary applications are deployed in namespaces other than the AUT, ensure that the chaosServiceAccount is bound to a cluster role and has adequate permissions to list pods on other namespaces.
The auxiliaryAppInfo in the spec specifies a (comma-separated) list of namespace-label pairs for downstream (dependent) apps of the primary app specified in .spec.appInfo in case of pod-level chaos experiments. In case of infra-level chaos experiments, this flag specifies those apps that may be directly impacted by chaos and upon which health checks are necessary.
-
-
-
-**Note**: Irrespective of the nature of the chaos experiment, i.e., pod-level (single-app impact/lesser blast radius) or infra-level(multi-app impact/higher blast radius), the `.spec.appinfo` is a must-fill where the experiment is pointed to at least one primary app whose health is measured as an indicator of the resiliency / success of the chaos experiment.
-
-### RBAC Specification
-
-
-
-
Field
-
.spec.chaosServiceAccount
-
-
-
Description
-
Flag to specify serviceaccount used for chaos experiment
-
-
-
Type
-
Mandatory
-
-
-
Range
-
user-defined (type: string)
-
-
-
Default
-
n/a
-
-
-
Notes
-
The chaosServiceAccount in the spec specifies the name of the serviceaccount mapped to a role/clusterRole with enough permissions to execute the desired chaos experiment. The minimum permissions needed for any given experiment is provided in the .spec.definition.permissions field of the respective chaosexperiment CR.
-
-
-
-### Runtime Specification
-
-
-
-
Field
-
.spec.annotationCheck
-
-
-
Description
-
Flag to control annotationChecks on applications as prerequisites for chaos
-
-
-
Type
-
Optional
-
-
-
Range
-
true, false
-
-
-
Default
-
true
-
-
-
Notes
-
The annotationCheck in the spec controls whether or not the operator checks for the annotation "litmuschaos.io/chaos" to be set against the application under test (AUT). Setting it to true ensures the check is performed, with chaos being skipped if the app is not annotated, while setting it to false suppresses this check and proceeds with chaos injection.
-
-
-
-
-
-
Field
-
.spec.terminationGracePeriodSeconds
-
-
-
Description
-
Flag to control terminationGracePeriodSeconds for the chaos pods(abort case)
-
-
-
Type
-
Optional
-
-
-
Range
-
integer value
-
-
-
Default
-
30
-
-
-
Notes
-
The terminationGracePeriodSeconds in the spec controls the terminationGracePeriodSeconds for the chaos resources in abort case. Chaos pods contains chaos revert upon abortion steps, which continuously looking for the termination signals. The terminationGracePeriodSeconds should be provided in such a way that the chaos pods got enough time for the revert before completely terminated.
-
-
-
-
-
-
Field
-
.spec.jobCleanupPolicy
-
-
-
Description
-
Flag to control cleanup of chaos experiment job post execution of chaos
-
-
-
Type
-
Optional
-
-
-
Range
-
delete, retain
-
-
-
Default
-
delete
-
-
-
Notes
-
The jobCleanupPolicy controls whether or not the experiment pods are removed once execution completes. Set to retain for debug purposes (in the absence of standard logging mechanisms).
-
-
-
-### Component Specification
-
-
-
-
Field
-
.spec.components.runner.image
-
-
-
Description
-
Flag to specify image of ChaosRunner pod
-
-
-
Type
-
Optional
-
-
-
Range
-
user-defined (type: string)
-
-
-
Default
-
n/a (refer Notes)
-
-
-
Notes
-
The .components.runner.image allows developers to specify their own debug runner images. Defaults for the runner image can be enforced via the operator env CHAOS_RUNNER_IMAGE
-
-
-
-
-
-
Field
-
.spec.components.runner.imagePullPolicy
-
-
-
Description
-
Flag to specify imagePullPolicy for the ChaosRunner
-
-
-
Type
-
Optional
-
-
-
Range
-
Always, IfNotPresent
-
-
-
Default
-
IfNotPresent
-
-
-
Notes
-
The .components.runner.imagePullPolicy allows developers to specify the pull policy for chaos-runner. Set to Always during debug/test.
-
-
-
-
-
-
Field
-
.spec.components.runner.imagePullSecrets
-
-
-
Description
-
Flag to specify imagePullSecrets for the ChaosRunner
The .spec.components.runner.secrets provides for a means to push secrets (typically project ids, access credentials etc.,) into the chaos runner pod. These are especially useful in case of platform-level/infra-level chaos experiments.
-
-
-
-
-
-
Field
-
.spec.components.runner.nodeSelector
-
-
-
Description
-
Node selectors for the runner pod
-
-
-
Type
-
Optional
-
-
-
Range
-
Labels in the from of label key=value
-
-
-
Default
-
n/a
-
-
-
Notes
-
The .spec.components.runner.nodeSelector The nodeselector contains labels of the node on which runner pod should be scheduled. Typically used in case of infra/node level chaos.
-
-
-
-
-
-
Field
-
.spec.components.runner.resources
-
-
-
Description
-
Specify the resource requirements for the ChaosRunner pod
-
-
-
Type
-
Optional
-
-
-
Range
-
user-defined (type: corev1.ResourceRequirements)
-
-
-
Default
-
n/a
-
-
-
Notes
-
The .spec.components.runner.resources contains the resource requirements for the ChaosRunner Pod, where we can provide resource requests and limits for the pod.
-
-
-
-
-
-
Field
-
.spec.components.runner.tolerations
-
-
-
Description
-
Toleration for the runner pod
-
-
-
Type
-
Optional
-
-
-
Range
-
user-defined (type: []corev1.Toleration)
-
-
-
Default
-
n/a
-
-
-
Notes
-
The .spec.components.runner.tolerations Provides tolerations for the runner pod so that it can be scheduled on the respective tainted node. Typically used in case of infra/node level chaos.
-
-
-
-### Experiment Specification
-
-
-
-
Field
-
.spec.experiments[].name
-
-
-
Description
-
Name of the chaos experiment CR
-
-
-
Type
-
Mandatory
-
-
-
Range
-
user-defined (type: string)
-
-
-
Default
-
n/a
-
-
-
Notes
-
The experiment[].name specifies the chaos experiment to be executed by the ChaosOperator.
-
-
-
-
-
-
Field
-
.spec.experiments[].spec.components.env
-
-
-
Description
-
Environment variables passed to the chaos experiment
The experiment[].spec.components.env specifies the array of tunables passed to the experiment pods. Though the field is optional from a chaosengine definition viewpoint, it is almost always necessary to provide experiment tunables via this definition. While some of the env variables override the defaults in the experiment CR and some of the env are mandatory additions filling in for placeholders/empty values in the experimet CR. For a list of "mandatory" & "optional" env for an experiment, refer to the respective experiment documentation.
The experiment[].spec.components.configMaps provides for a means to insert config information into the experiment. The configmaps definition is validated for correctness and those specified are checked for availability (in the cluster/namespace) before being mounted into the experiment pods.
The experiment[].spec.components.secrets provides for a means to push secrets (typically project ids, access credentials etc.,) into the experiment pods. These are especially useful in case of platform-level/infra-level chaos experiments. The secrets definition is validated for correctness and those specified are checked for availability (in the cluster/namespace) before being mounted into the experiment pods.
The .components.runner.experimentImagePullSecrets allows developers to specify the imagePullSecret name for ChaosExperiment.
-
-
-
-
-
-
Field
-
.spec.experiments[].spec.components.nodeSelector
-
-
-
Description
-
Provide the node selector for the experiment pod
-
-
-
Type
-
Optional
-
-
-
Range
-
Labels in the from of label key=value
-
-
-
Default
-
n/a
-
-
-
Notes
-
The experiment[].spec.components.nodeSelector The nodeselector contains labels of the node on which experiment pod should be scheduled. Typically used in case of infra/node level chaos.
Provides the timeout and retry values for the status checks. Defaults to 180s & 90 retries (2s per retry)
-
-
-
Type
-
Optional
-
-
-
Range
-
It contains values in the form {`delay: int, timeout: int`}
-
-
-
Default
-
delay: 2s and timeout: 180s
-
-
-
Notes
-
The experiment[].spec.components.statusCheckTimeouts The statusCheckTimeouts override the status timeouts inside chaosexperiments. It contains timeout & delay in seconds.
-
-
-
-
-
-
Field
-
.spec.experiments[].spec.components.resources
-
-
-
Description
-
Specify the resource requirements for the ChaosExperiment pod
-
-
-
Type
-
Optional
-
-
-
Range
-
user-defined (type: corev1.ResourceRequirements)
-
-
-
Default
-
n/a
-
-
-
Notes
-
The experiment[].spec.components.resources contains the resource requirements for the ChaosExperiment Pod, where we can provide resource requests and limits for the pod.
Annotations that needs to be provided in the pod which will be created (experiment-pod)
-
-
-
Type
-
Optional
-
-
-
Range
-
user-defined (type: label key=value)
-
-
-
Default
-
n/a
-
-
-
Notes
-
The .spec.components.experimentAnnotation allows developers to specify the custom annotations for the experiment pod.
-
-
-
-
-
-
Field
-
.spec.experiments[].spec.components.tolerations
-
-
-
Description
-
Toleration for the experiment pod
-
-
-
Type
-
Optional
-
-
-
Range
-
user-defined (type: []corev1.Toleration)
-
-
-
Default
-
n/a
-
-
-
Notes
-
The .spec.components.tolerationsTolerations for the experiment pod so that it can be scheduled on the respective tainted node. Typically used in case of infra/node level chaos.
-
-
-
-
-
-
Field
-
.spec.experiments[].spec.probe
-
-
-
Description
-
Declarative way to define the chaos hypothesis
-
-
-
Type
-
Optional
-
-
-
Range
-
user-defined
-
-
-
Default
-
n/a
-
-
-
Notes
-
The .probe allows developers to specify the chaos hypothesis. It supports four types: cmdProbe, k8sProbe, httpProbe, promProbe. For more details refer
-
-
-
-## Summary
-
-The ChaosEngine CR is the user-facing CR which helps in binding the application instance with the ChaosExperiment. It defines the Run Policies and also holds the status of your experiment. This CR helps you customize the experiment according to your need since it can override some of the default characteristics/tunables in your experiment CR.
-
-This CR is also updated/patched with status of the chaos experiments, making it the single source of truth with respect to the chaos.
-
-## Resources
-
-
-
-## Learn More
-
-- [Explore Probes](probes.md)
-- [What is a Chaos Scenario](chaos-workflow.md)
-- [Examine the ChaosResult](chaos-result.md)
diff --git a/website/docs/concepts/chaos-experiment.md b/website/docs/concepts/chaos-experiment.md
deleted file mode 100644
index acb7a0fe..00000000
--- a/website/docs/concepts/chaos-experiment.md
+++ /dev/null
@@ -1,424 +0,0 @@
----
-id: chaos-experiment
-title: ChaosExperiment
-sidebar_label: ChaosExperiment
----
-
----
-
-ChaosExperiment CR is the heart of litmus and contains the low-level execution information. They serve as off-the-shelf templates that one needs to "pull" (install on the cluster.md) before including them as part of a chaos run against any target applications (the binding being defined in the [ChaosEngine](chaos-engine.md)). The experiments are installed on the cluster as Kubernetes custom resources and are designed to hold granular details of the experiment such as image, library, necessary permissions, chaos parameters (set to their default values). Most of the ChaosExperiment parameters, are essentially tunables that can be overridden from the ChaosEngine resource. The ChaosExperiment CRs are the primary artifacts hosted on the [ChaosHub](https://hub.litmuschaos.io)
-
-This section describes the fields in the ChaosExperiment spec and the possible values that can be set against the same.
-
-## Scope Specification
-
-
-
-
Field
-
.spec.definition.scope
-
-
-
Description
-
Flag to specify the scope of the ChaosExperiment
-
-
-
Type
-
Optional
-
-
-
Range
-
Namespaced, Cluster
-
-
-
Default
-
n/a (depends on experiment type)
-
-
-
Notes
-
The .spec.definition.scope specifies the scope of the experiment. It can be Namespaced scope for pod level experiments and Cluster for the experiments having a cluster wide impact.
-
-
-
-
-
-
Field
-
.spec.definition.permissions
-
-
-
Description
-
Flag to specify the minimum permission to run the ChaosExperiment
-
-
-
Type
-
Optional
-
-
-
Range
-
user-defined (type: list)
-
-
-
Default
-
n/a
-
-
-
Notes
-
The .spec.definition.permissions specify the minimum permission that is required to run the ChaosExperiment. It also helps to estimate the blast radius for the ChaosExperiment.
-
-
-
-## Component Specification
-
-
-
-
Field
-
.spec.definition.image
-
-
-
Description
-
Flag to specify the image to run the ChaosExperiment
-
-
-
Type
-
Mandatory
-
-
-
Range
-
user-defined (type: string)
-
-
-
Default
-
n/a (refer Notes)
-
-
-
Notes
-
The .spec.definition.image allows the developers to specify their experiment images. Typically set to the Litmus go-runner or the ansible-runner. This feature of the experiment enables BYOC (BringYourOwnChaos), where developers can implement their own variants of a standard chaos experiment
-
-
-
-
-
-
Field
-
.spec.definition.imagePullPolicy
-
-
-
Description
-
Flag that helps the developers to specify imagePullPolicy for the ChaosExperiment
-
-
-
Type
-
Mandatory
-
-
-
Range
-
IfNotPresent, Always (type: string)
-
-
-
Default
-
Always
-
-
-
Notes
-
The .spec.definition.imagePullPolicy allows developers to specify the pull policy for ChaosExperiment image. Set to Always during debug/test
-
-
-
-
-
-
Field
-
.spec.definition.args
-
-
-
Description
-
Flag to specify the entrypoint for the ChaosExperiment
-
-
-
Type
-
Mandatory
-
-
-
Range
-
user-defined (type:list of string)
-
-
-
Default
-
n/a
-
-
-
Notes
-
The .spec.definition.args specifies the entrypoint for the ChaosExperiment. It depends on the language used in the experiment. For litmus-go the .spec.definition.args contains a single binary of all experiments and managed via -name flag to indicate experiment to run(-name (exp-name)).
-
-
-
-
-
-
Field
-
.spec.definition.command
-
-
-
Description
-
Flag to specify the shell on which the ChaosExperiment will execute
-
-
-
Type
-
Mandatory
-
-
-
Range
-
user-defined (type: list of string).
-
-
-
Default
-
/bin/bash
-
-
-
Notes
-
The .spec.definition.command specifies the shell used to run the experiment /bin/bash is the most common shell to be used.
The .spec.definition.env specifies the array of tunables passed to the experiment pods as environment variables. It is used to manage the experiment execution. We can set the default values for all the variables (tunable) here which can be overridden by ChaosEngine from .spec.experiments[].spec.components.env if required. To know about the variables that need to be overridden check the list of "mandatory" & "optional" env for an experiment as provided within the respective experiment documentation.
The .spec.definition.securityContext.podSecurityContext allows the developers to specify the security context for the ChaosPod which applies to all containers inside the Pod.
-
-
-
-
-
-
Field
-
.spec.definition.configMaps
-
-
-
Description
-
Flag to specify the configmap for ChaosPod
-
-
-
Type
-
Optional
-
-
-
Range
-
user-defined
-
-
-
Default
-
n/a
-
-
-
Notes
-
The .spec.definition.configMaps allows the developers to mount the ConfigMap volume into the experiment pod.
-
-
-
-
-
-
Field
-
.spec.definition.secrets
-
-
-
Description
-
Flag to specify the secrets for ChaosPod
-
-
-
Type
-
Optional
-
-
-
Range
-
user-defined
-
-
-
Default
-
n/a
-
-
-
Notes
-
The .spec.definition.secrets specify the secret data to be passed for the ChaosPod. The secrets typically contains confidential information like credentials.
-
-
-
-
-
-
Field
-
.spec.definition.experimentAnnotations
-
-
-
Description
-
Flag to specify the custom annotation to the ChaosPod
-
-
-
Type
-
Optional
-
-
-
Range
-
user-defined (type:map[string]string)
-
-
-
Default
-
n/a
-
-
-
Notes
-
The .spec.definition.experimentAnnotations allows the developer to specify the Custom annotation for the chaos pod.
-
-
-
-
-
-
Field
-
.spec.definition.hostFileVolumes
-
-
-
Description
-
Flag to specify the host file volumes to the ChaosPod
-
-
-
Type
-
Optional
-
-
-
Range
-
user-defined (type:map[string]string)
-
-
-
Default
-
n/a
-
-
-
Notes
-
The .spec.definition.hostFileVolumes allows the developer to specify the host file volumes to the ChaosPod.
-
-
-
-
-
-
Field
-
.spec.definition.hostPID
-
-
-
Description
-
Flag to specify the host PID for the ChaosPod
-
-
-
Type
-
Optional
-
-
-
Range
-
true, false (type:bool)
-
-
-
Default
-
n/a
-
-
-
Notes
-
The .spec.definition.hostPID allows the developer to specify the host PID for the ChaosPod.
-
-
diff --git a/website/docs/concepts/chaos-result.md b/website/docs/concepts/chaos-result.md
deleted file mode 100644
index 37f17580..00000000
--- a/website/docs/concepts/chaos-result.md
+++ /dev/null
@@ -1,349 +0,0 @@
----
-id: chaos-result
-title: ChaosResult
-sidebar_label: ChaosResult
----
-
----
-
-ChaosResult resource holds the results of a ChaosExperiment with a namespace scope. It is created or updated at runtime by the experiment itself. It holds important information like the ChaosEngine reference, Experiment State, Verdict of the experiment (on completion), salient application/result attributes. It is also a source for metrics collection. It is updated/patched with the status of the experiment run. It is not removed as part of the default cleanup procedures to allow for extended reference.
-
-## Prerequisites
-
-To understand the concept of ChaosResult, make sure you have good knowledge of the [ChaosEngine](chaos-engine.md) CR and
-[Chaos Scenario](chaos-workflow.md).
-
-## ChaosResult Spec
-
-This section describes the fields/details provided by the ChaosResult spec.
-
-### Component Details
-
-
-
-
Field
-
.spec.engine
-
-
-
Description
-
Flag to hold the ChaosEngine name for the experiment
-
-
-
Type
-
Optional
-
-
-
Range
-
n/a (type: string)
-
-
-
Notes
-
The .spec.engine holds the engine name for the current course of the experiment.
-
-
-
-
-
-
Field
-
.spec.experiment
-
-
-
Description
-
Flag to hold the ChaosExperiment name which induces chaos.
-
-
-
Type
-
Optional
-
-
-
Range
-
n/a (type: string)
-
-
-
Notes
-
The .spec.experiment holds the ChaosExperiment name for the current course of the experiment.
-
-
-
-### Status Details
-
-
-
-
Field
-
.status.experimentStatus.failstep
-
-
-
Description
-
Flag to show the failure step of the ChaosExperiment
-
-
-
Type
-
Mandatory
-
-
-
Range
-
n/a(type: string)
-
-
-
Notes
-
The .status.experimentStatus.failstep Show the step at which the experiment failed. It helps in faster debugging of failures in the experiment execution.
-
-
-
-
-
-
Field
-
.status.experimentStatus.phase
-
-
-
Description
-
Flag to show the current phase of the experiment
-
-
-
Type
-
Mandatory
-
-
-
Range
-
Awaited,Running,Completed,Aborted (type: string)
-
-
-
Notes
-
The .status.experimentStatus.phase shows the current phase in which the experiment is. It gets updated as the experiment proceeds.If the experiment is aborted then the status will be Aborted.
-
-
-
-
-
-
Field
-
.status.experimentStatus.probesuccesspercentage
-
-
-
Description
-
Flag to show the probe success percentage
-
-
-
Type
-
Mandatory
-
-
-
Range
-
1 to 100 (type: int)
-
-
-
Notes
-
The .status.experimentStatus.probesuccesspercentage shows the probe success percentage which is a ratio of successful checks v/s total probes.
-
-
-
-
-
-
Field
-
.status.experimentStatus.verdict
-
-
-
Description
-
Flag to show the verdict of the experiment.
-
-
-
Type
-
Mandatory
-
-
-
Range
-
Awaited,Pass,Fail,Stopped (type: string)
-
-
-
Notes
-
The .status.experimentStatus.verdict shows the verdict of the experiment. It is Awaited when the experiment is in progress and ends up with Pass or Fail according to the experiment result.
-
-
-
-
-
-
Field
-
.status.history.passedRuns
-
-
-
Description
-
It contains cumulative passed run count
-
-
-
Type
-
Mandatory
-
-
-
Range
-
ANY NON NEGATIVE INTEGER
-
-
-
Notes
-
The .status.history.passedRuns contains cumulative passed run counts for a specific ChaosResult.
-
-
-
-
-
-
Field
-
.status.history.failedRuns
-
-
-
Description
-
It contains cumulative failed run count
-
-
-
Type
-
Mandatory
-
-
-
Range
-
ANY NON NEGATIVE INTEGER
-
-
-
Notes
-
The .status.history.failedRuns contains cumulative failed run counts for a specific ChaosResult.
-
-
-
-
-
-
Field
-
.status.history.stoppedRuns
-
-
-
Description
-
It contains cumulative stopped run count
-
-
-
Type
-
Mandatory
-
-
-
Range
-
ANY NON NEGATIVE INTEGER
-
-
-
Notes
-
The .status.history.stoppedRuns contains cumulative stopped run counts for a specific ChaosResult.
-
-
-
-### Probe Details
-
-
-
-
Field
-
.status.probestatus.name
-
-
-
Description
-
Flag to show the name of probe used in the experiment
-
-
-
Type
-
Mandatory
-
-
-
Range
-
n/a n/a (type: string)
-
-
-
Notes
-
The .status.probestatus.name shows the name of the probe used in the experiment.
-
-
-
-
-
-
Field
-
.status.probestatus.status.continuous
-
-
-
Description
-
Flag to show the result of probe in continuous mode
-
-
-
Type
-
Optional
-
-
-
Range
-
Awaited,Passed,Better Luck Next Time (type: string)
-
-
-
Notes
-
The .status.probestatus.status.continuous helps to get the result of the probe in the continuous mode. The httpProbe is better used in the Continuous mode.
-
-
-
-
-
-
Field
-
.status.probestatus.status.postchaos
-
-
-
Description
-
Flag to show the probe result post chaos
-
-
-
Type
-
Optional
-
-
-
Range
-
Awaited,Passed,Better Luck Next Time (type:map[string]string)
-
-
-
Notes
-
The .status.probestatus.status.postchaos shows the result of probe setup in EOT mode executed at the End of Test as a post-chaos check.
-
-
-
-
-
-
Field
-
.status.probestatus.status.prechaos
-
-
-
Description
-
Flag to show the probe result pre chaos
-
-
-
Range
-
Awaited,Passed,Better Luck Next Time (type:string)
-
-
-
Notes
-
The .status.probestatus.status.prechaos shows the result of probe setup in SOT mode executed at the Start of Test as a pre-chaos check.
-
-
-
-
-
-
Field
-
.status.probestatus.type
-
-
-
Description
-
Flag to show the type of probe used
-
-
-
Range
-
-HTTPProbe,K8sProbe,CmdProbe(type:string)
-
-
-
Notes
-
The .status.probestatus.type shows the type of probe used.
-
-
-
-## Summary
-
-Just like the ChaosExperiment CR and ChaosEngine CR, ChaosResult is a Custom Resource provided by Litmus.
-ChaosResult resource holds the results of a ChaosExperiment. It comprises of some important information related to the experiment execution like Experiment Details, Verdict, Phase, ProbeSuccessPercentage etc. It is updated/patched with every experiment run. It can also be used as a source for matrics collection.
-
-## Learn More
-
-- [Run a Chaos Scenario](../getting-started/run-your-first-workflow.md)
-- [Observe a chaos scenario](visualize-workflow.md)
diff --git a/website/docs/concepts/chaos-workflow.md b/website/docs/concepts/chaos-workflow.md
index 674802e0..c2c69abb 100644
--- a/website/docs/concepts/chaos-workflow.md
+++ b/website/docs/concepts/chaos-workflow.md
@@ -1,33 +1,38 @@
---
id: chaos-workflow
-title: Chaos Scenario
-sidebar_label: Chaos Scenario
+title: Chaos Experiment
+sidebar_label: Chaos Experiment
---
---
-**Chaos Scenario** is a set of different operations coupled together to achieve desired chaos impact on a Kubernetes Cluster.
+**Chaos Experiment** is a set of different operations coupled together to achieve desired chaos impact on a Kubernetes Cluster.
It is useful in automating a series of pre-conditioning steps or action which is necessary to be performed before triggering the chaos injection.
-A Chaos Scenario can also be used to perform different operations parallelly to achieve a desired chaos injection scenario.
+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 Scenario:
+The following should be required before creating a Chaos Experiment:
- [ChaosCenter](../getting-started/resources.md#chaoscenter)
-- [Chaos Delegate](../getting-started/resources.md#chaosagents)
-- [Chaos Experiment CR](chaos-experiment.md)
-- [ChaosEngine CR](chaos-engine.md)
+- [Chaos Infrastructure](../getting-started/resources.md#chaosagents)
- [Probes](probes.md)
-## How do we define and execute a Chaos Scenario ?
+## How do we define and execute a Chaos Experiment ?
-LitmusChaos leverages the popular chaos scenario and GitOps tool **Argo** to achieve this goal. Argo enables the creation of different chaos scenarios together in from of chaos scenarios which are extremly simple and efficient to use.
-With the help of **ChaosCenter**, chaos scenarios with different type of experiments can be created. In a Chaos Scenario, the experiments can be added in a parallel way and the user can tune the chaos scenario by adding additional steps to simulate a desired fault that might occur in production stage.
+LitmusChaos leverages the popular GitOps tool **Argo** to achieve this goal. Argo enables the creation of different chaos experiments together in form of chaos experiments which are extremely simple and efficient to use.
+With the help of **ChaosCenter**, chaos experiments with different types of faults can be created. In a Chaos Experiment, the faults can be set to execute in parallel to each other and the user can tune the chaos experiment by adding additional steps to simulate a desired fault that might occur in the production stage.
-### Life Cycle of a Chaos Scenario
+### Life Cycle of a Chaos Experiment
-Here is a sample pod-delete chaos scenario from ChaosCenter.
+Here is a sample pod-delete chaos experiment from ChaosCenter.
```yaml
apiVersion: argoproj.io/v1alpha1
@@ -204,10 +209,10 @@ spec:
strategy: OnWorkflowCompletion
```
-The structure of a chaos scenario is similar to that of a Kubernetes Object. It consists of the mandatory fields like `apiVersion`, `kind`, `metadata`, `spec`.
+The 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 Scenario is where the different steps are mentioned and the overall life cycle of the chaos scenario is described.
-We can see different `templates` are present in the spec of a chaos scenario.
+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:
@@ -222,20 +227,20 @@ templates:
```
Here in this template, we can see different steps are present.
-These include installing the chaos experiments, executing the chaos engine of the experiment and at the end we have the revert chaos step which deletes/removes the resources that were created as part of the chaos scenario.
+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 experiments in the form of probes. These probes are defined in the ChaosEngines of the experiment and are updated when the experiment execution takes place.
-The overall chaos scenario result can be viewed with the ChaosResult CRD which contains the `verdict` and the `probeSuccessPercentage` (a ratio of successful checks v/s total probes).
+Some additional checks can be added with the faults in the form of probes. These probes are defined in the ChaosEngines of the faults and are updated when the fault execution takes place.
+The overall chaos experiment result can be viewed with the ChaosResult CRD which contains the `verdict` and the `probeSuccessPercentage` (a ratio of successful checks v/s total probes).
## What is a run?
-A chaos scenario run can be defined as single/one-time execution of the chaos scenario. There can be multiple runs of a single chaos scenario. If the chaos scenario consists of a cron syntax, it will run periodically according to the cron provided in the chaos scenario.
+A chaos experiment run can be defined as a single/one-time execution of the chaos experiment. There can be multiple runs of a single chaos experiment. If the chaos experiment consists of a cron syntax, it will run periodically according to the cron provided in the chaos experiment.
-## What is Resiliency Score?
+## What is Resilience Score?
-**Resiliency score** is the measure of how resilient is the chaos scenario when different chaos scenarios are performed on the Kubernetes System.
+**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 scenario, certain weights are assigned to all the experiments present in the chaos scenario. These weights signify the priority/importance of the experiment. The higher the weight, the more significant is the experiment.
+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:
@@ -243,19 +248,19 @@ In ChaosCenter, the weight priority is generally divided into three sections:
- 4-6: Medium Priority
- 7-10: High Priority
-Once a weight has been assigned to the experiment, we look for the Probe Success Percentage for that experiment itself (Post Chaos) and calculate the total resilience result for that experiment as a multiplication of the weight given and the probe success percentage returned after the Chaos Run.
+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 experiment = (Weight Given to that experiment * Probe Success Percentage)
-Overall Resilience Score = Total Test Result / Sum of the assigned weights of the experiments
+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
```
-## What is a Cron Chaos Scenario?
+## What is a Cron Chaos Experiment?
-Cron Chaos Scenario is a type of chaos scenario that runs on a pre-defined schedule. It consists of a mandatory field `spec.schedule`. A cron syntax is provided in this field at which the chaos scenario execution takes
+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 Scenario for Podtato-Head application:
+Here's a sample Cron Chaos Experiment for Podtato-Head application:
```yaml
apiVersion: argoproj.io/v1alpha1
@@ -391,17 +396,17 @@ spec:
timezone: Asia/Calcutta
```
-In the above chaos scenario, we can see the cron syntax at `spec.schedule` is
+In the above chaos experiment, we can see the cron syntax at `spec.schedule` is
```
spec:
schedule: 10 0-23 * * *
```
-This means the chaos scenario will be executed at the 10th minute of every hour.
+This means the chaos experiment will be executed at the 10th minute of every hour.
-A chaos scenario can be changed into Cron Chaos Scenario from the ChaosCenter.
-While scheduling a chaos scenario, in the `Schedule` step, there are few options as part of Recurring Schedules. These include:
+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
@@ -410,17 +415,10 @@ While scheduling a chaos scenario, in the `Schedule` step, there are few options
## Summary
-Chaos Scenario is combination of different steps combined together to perfrom a specific chaos use-case on a Kubernetes system. These steps can include install experiment steps, ChaosEngine CR for target selection, revert-chaos steps etc. Chaos Scenarios can be scheduled for a later time with the help of Cron Chaos Scenarios.
-These chaos scenarios consist of a cron syntax that is used for scheduling a chaos scenario. Once the chaos scenario execution is completed, the resiliency of the targeted application is calculated. Several weights are assigned to different experiments in the chaos scenario. These weights are used along with the ProbeSuccessPercentage to find out the resiliency score.
-
-## Resources
-
-
-
-
+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 Scenario](visualize-workflow.md)
-- [Examine the ChaosResult](chaos-result.md)
+- [Visualize a Chaos Experiment](visualize-experiment.md)
diff --git a/website/docs/concepts/chaoshub.md b/website/docs/concepts/chaoshub.md
index a0ac4d8f..66351540 100644
--- a/website/docs/concepts/chaoshub.md
+++ b/website/docs/concepts/chaoshub.md
@@ -6,11 +6,11 @@ sidebar_label: ChaosHub
---
-ChaosHub allows you to orchestrate chaos scenarios from the Public **[ChaosHub](http://hub.litmuschaos.io/)** or an alternate source for the Experiments (basically, a **[fork](https://github.com/litmuschaos/chaos-charts)** of the public hub with custom experiments).
+ChaosHub allows you to orchestrate chaos experiments from the Public **[ChaosHub](http://hub.litmuschaos.io/)** or an alternate source for the Experiments (basically, a **[fork](https://github.com/litmuschaos/chaos-charts)** of the public hub with custom faults).
## Prerequisites
-The following are the prerequisites for creating a Chaos Scenario:
+The following are the prerequisites for creating a Chaos Experiment:
- Fork of [Chaos-Charts](https://github.com/litmuschaos/chaos-charts) repository
@@ -20,7 +20,7 @@ An active internet connection is required to clone the git repository for the fi
## Connecting a Git repository using ChaosHub
-With ChaosHub, you can construct chaos scenarios by selecting, tuning and sequencing different experiments together from their connected ChaosHubs.
+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.
@@ -63,26 +63,26 @@ If some changes are made into the git repository, you can reflect these changes
To make changes in a hub like changing the name, branch, access token etc, you can select the **Edit Hub** option from the ChaosHub card.
-## Chaos Scenarios and Experiments in a ChaosHub
+## Chaos Experiments and Experiments in a ChaosHub
-### 1. View the PreDefined Chaos Scenarios
+### 1. View the PreDefined Chaos Experiments
-After connecting a ChaosHub, you can view the different pre-defined chaos scenarios present in the ChaosHub.
+After connecting a ChaosHub, you can view the different pre-defined chaos experiments present in the ChaosHub.
-
+
-### 2. View the Chaos-Experiments
+### 2. View the Chaos Faults
-Similarly, you can view the different charts and the experiment. These charts are sorted according to different categories like generic, aws, azure, kube-components etc.
+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 experiment details
+### 3. View the fault details
-You can select one of the chaos experiment and can examine the experiment details.
-The experiment page consists of all the important details like the description of the experiment, a tutorial video, the maintainer of the experiment etc.
-You can also find experiment yaml link, RBAC link and the ChaosEngine yaml link of the experiment.
-These yaml links are required for the creation of Custom Chaos Scenarios.
+You can select one of the chaos faults and can examine the fault details.
+The fault page consists of all the important details like the description of the fault, a tutorial video, the maintainer of the fault, etc.
+You can also find the fault yaml link, RBAC link, and the ChaosEngine yaml link of the fault.
+These yaml links are required for the creation of Custom Chaos Experiments.
@@ -92,13 +92,11 @@ To remove a ChaosHub from a project, you can select the **Disconnect Hub** optio
## Summary
-ChaosHubs are basically a collection of different clones of the Chaos-Charts repository, which consists of a variety of experiments and pre-defined chaos scenarios. You can use a ChaosHub to construct a custom chaos scenarios and tune it according to the use-case. These ChaosHubs can also be synced with the latest changes. New experiments and pre-defined chaos scenarios can also be added in the repository which can be directly used in the ChaosCenter.
-
-## Resources
-
-
+You can select one of the chaos faults and can examine the fault details.
+The fault page consists of all the important details like the description of the fault, a tutorial video, the maintainer of the fault, etc.
+You can also find the fault yaml link, RBAC link, and the ChaosEngine yaml link of the fault.
+These yaml links are required for the creation of Custom Chaos Experiments.
## Learn More
-- [What is a Chaos Scenario](chaos-workflow.md)
-- [Examine the ChaosResult](chaos-result.md)
+- [What is a Chaos Experiment](chaos-workflow.md)
diff --git a/website/docs/concepts/datasource.md b/website/docs/concepts/datasource.md
deleted file mode 100644
index 9faaf4b2..00000000
--- a/website/docs/concepts/datasource.md
+++ /dev/null
@@ -1,51 +0,0 @@
----
-id: datasource
-title: Manage Datasources
-sidebar_label: Datasource
----
-
----
-
-The primary stateful data store for litmus's chaos center is a mongoDB statefulset. It powers all the features in chaos center including authentication, chaos injection and analysis, chaos delegate connections etc. Apart from the primary data store, the portal provides a way to add Prometheus (TSDB) data sources for time series data visualization and monitoring. The principle of Open observability drives the chaos center and allows users to manage the data sources for a project in multiple topologies for chaos delegate specific and cross chaos delegate dashboards. The system allows to either have multiple data sources or a single data source scraping metrics and events from all target chaos delegates for monitoring chaos impact on
-application OR infrastructure.
-
-## Prerequisites
-
-The following should be required before knowing about managing data sources in chaos center:
-
-- [Running Chaos Scenarios](../getting-started/run-your-first-workflow.md)
-- [Prometheus TSDB](https://prometheus.io/)
-
-## Data flow architecture
-
-The chaos center provides the functionality to connect multiple prometheus data sources across projects to harness insights on application or system behavior during chaos manifested on real-time monitoring dashboards. Litmus follows an open observability model which enables users to plug metrics from any Prometheus exporter into the data source connected to a chaos center project to visualize the same on dashboards. Along with system and application metrics the metrics exposed by `chaos-exporter` service (a prometheus metrics exporter for chaos injection events and results or verdicts) on the execution plane or target chaos delegate's cluster is necessary to be ingested into the same data source to be connected to the project in order to facilitate chaos interleaving. Existing monitoring infrastructure for observing the target chaos delegate's cluster can also be used if it is prometheus based, plugging the metrics from `chaos-exporter` in such cases should be sufficient.
-
-
-
-Data flow from data sources
-
-
-## Health check for Time-series database
-
-The query timeout is used for all the queries associated with all the dashboards connected to the given data source, including querying data while editing the dashboard queries, although the default request timeout for the health check of the data source while connecting, updating or listing it is `5 seconds`.
-
-## Scrape interval
-
-The scrape interval is used to control the lower limit of minStep for queries multiplying by denominator of query resolution for a dashboard consuming the data source; the same might be used for limiting the refresh rate for dashboard views with relative time range in later versions of the Litmus center.
-
-## Supported versions
-
-The Litmus center supports Prometheus 2.1 or later.
-
-## Summary
-
-LitmusChaos facilitates in-house real-time monitoring for `events` and `verdicts` metrics exposed by the native `chaos-exporter` for each target chaos delegate. These events and metrics can be scraped from a Prometheus TSDB connected to chaos center to overlay on top of application performance and infrastructure monitoring graphs. Some considerations for health-check, metrics scraping interval and version support have been stated.
-
-## Resources
-
-
-
-## Learn More
-
-- [Visualize a Chaos Scenario](visualize-workflow.md)
-- [Application and infrastructure monitoring](app-infra-monitoring.md)
diff --git a/website/docs/concepts/gitops.md b/website/docs/concepts/gitops.md
index 30dc8850..05c725ab 100644
--- a/website/docs/concepts/gitops.md
+++ b/website/docs/concepts/gitops.md
@@ -8,41 +8,42 @@ sidebar_label: GitOps
## Prerequisites
-- Chaos Delegate
-- [Chaos Scenario](chaos-workflow.md)
+- Chaos Infrastructure
+- [Chaos Experiment](chaos-workflow.md)
-GitOps feature in Litmus enables you to configure a single source of truth for your chaos scenarios and experiments, any changes made either to the artifacts stored in the configured git repository or the portal will be synced. This allows you to create and execute chaos scenarios directly from git enabling a vast scope of automation in CI/CD pipelines.
+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 scenarios with any changes in the resource spec. Currently, the event supported for chaos injection is resource image change, configuration change, change in replicas, and many more.
-The event-driven chaos injection allows Litmus to be integrated with traditional GitOps flow that involves automated deployment of applications or workloads, for example, you can now automatically trigger chaos scenarios whenever a new release is created for your application and is deployed by a continuous delivery system.
+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 delegate and can be more than one, other is the self chaos delegate where the Litmus(red cluster) is installed. After an chaos delegate is connected to Litmus, an event-tracker pod will be installed which is responsible for event-driven chaos injection by tracking the changes in your target application.
+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: App version changes from V1 to V2), it gets triggered and informs the graphql-server pod, the server will then try to look for the chaos scenario using `workflow_id` from the git repository. Once it gets the required chaos scenario, it will send it to the subscriber which is responsible for applying the chaos scenario into the target cluster. After the chaos scenario run is completed you can check the resiliency of your application.
+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 scenario identity which will be subscribed by the target application deployment and it is present in the chaos scenario label.
+- `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.
-## Resources
-
-
-
-
-
## Learn More
- [Configuring GitOps](../user-guides/gitops-configuration.md)
-- [Schedule a chaos scenario](../user-guides/schedule-workflow.md)
-- [Observe a Chaos Scenario](../user-guides/observe-workflow.md)
+- [Schedule a Chaos Experiment](../user-guides/schedule-experiment.md)
+- [Observe a Chaos Experiment](../user-guides/observe-experiment.md)
diff --git a/website/docs/concepts/infrastructure.md b/website/docs/concepts/infrastructure.md
new file mode 100644
index 00000000..dab7d774
--- /dev/null
+++ b/website/docs/concepts/infrastructure.md
@@ -0,0 +1,32 @@
+---
+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 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/docs/concepts/open-observability.md b/website/docs/concepts/open-observability.md
deleted file mode 100644
index 62f2015f..00000000
--- a/website/docs/concepts/open-observability.md
+++ /dev/null
@@ -1,71 +0,0 @@
----
-id: open-observability
-title: Open Observability
-sidebar_label: Open Observability
----
-
----
-
-Litmus 2.0 builds on principle of Open observability through observability hooks such as probes to validate steady state hypothesis along with chaos injection. Chaos exporter also provides prometheus metrics which can be used to generate alerts based on events and also to view chaos impact and application performance in terms of probe success percentage and experiment verdict. It provides for several integration points with Prometheus's alert manager and Grafana, also for the in-house application and infrastructure monitoring capabilities with chaos events, metadata and results.
-
-## Prerequisites
-
-The following should be required before knowing about Open observability hooks in litmus 2.0:
-
-- [Probes](probes.md)
-- [Application / Infra. monitoring](app-infra-monitoring.md)
-
-## Probes
-
-Litmus probes are pluggable checks that can be defined within the ChaosEngine for any chaos experiment. The experiment pods execute these checks based on the mode they are defined in & factor their success as necessary conditions in determining the verdict of the experiment (along with the standard `in-built` checks).
-
-_Litmus currently supports four types of probes:_
-
-- **httpProbe:** To query health/downstream URIs
-- **cmdProbe:** To execute any user-desired health-check function implemented as a shell command
-- **k8sProbe:** To perform CRUD operations against native & custom Kubernetes resources
-- **promProbe:** To execute promql queries and match prometheus metrics for specific criteria
-
-These probes can be used in isolation or in several combinations to achieve the desired checks.
-
-More about Probes can be found [here](probes.md)
-
-## Chaos exporter
-
-Chaos exporter is a custom `Prometheus` and `CloudWatch` exporter to expose Litmus Chaos metrics. Typically deployed along with the chaos-operator deployment, which, in-turn is associated with all `chaosresults` in the cluster.
-
-_Two types of metrics are exposed:_
-
-#### AggregateMetrics:
-
-These metrics are derived from all the `chaosresults` present inside WATCH_NAMESPACE. If WATCH_NAMESPACE is not defined then it derives metrics from all namespaces. It exposes total_passed_experiment, total_failed_experiment, total_awaited_experiment, experiment_run_count, experiment_installed_count metrics.
-
-#### ExperimentScoped:
-
-Individual experiment run status. It exposes passed_experiment, failed_experiment, awaited_experiment, probe_success_percentage, startTime, endTime, totalDuration, chaosInjectTime metrics
-
-All metrics exported from chaos exporter can be found [here](https://github.com/litmuschaos/chaos-exporter)
-
-## Integrations
-
-- [Prometheus](../integrations/prometheus)
-
-- [Grafana](../integrations/grafana)
-
-- [AlertManager](https://github.com/litmuschaos/tutorials/issues/6)
-
-## Summary
-
-Litmus supports several kinds of `probes` and also has a `chaos-exporter` on it's execution plane on the chaos delegate's cluster which is essential for interleaved monitoring, integrated alerts and to hook into existing observability infrastructure. Chaos experimentation is a lot about hypothesizing around the application and/or infrastructure behavior, controlling blast radius & measuring SLOs. SREs love to visualize the impact of chaos - either actively (live) or recorded (as with automated chaos tests)
-
-## Resources
-
-[Observability Considerations in Chaos: The Metrics Story](https://dev.to/ksatchit/observability-considerations-in-chaos-the-metrics-story-6cb)
-
-[Monitoring Litmus Chaos Experiments](https://dev.to/ksatchit/monitoring-litmus-chaos-experiments-198a)
-
-## Learn More
-
-- [Prometheus](../integrations/prometheus)
-- [Grafana](../integrations/grafana)
-- [Application and infrastructure monitoring](app-infra-monitoring.md)
diff --git a/website/docs/concepts/overview.md b/website/docs/concepts/overview.md
index 34233aa8..5f2e2134 100644
--- a/website/docs/concepts/overview.md
+++ b/website/docs/concepts/overview.md
@@ -8,33 +8,21 @@ sidebar_label: Overview
The Concepts section contains Definitions, Design principles, Terminology and Working technical theory. This section will not have the actual usage instructions or guides those will be made available in the [User Guides](../user-guides/overview.md) section.
-### [Chaos Experiment](chaos-experiment.md)
-
-ChaosExperiment CR is the heart of litmus and contains the low-level execution information.
-
### [Probes](probes.md)
-Probes are pluggable checks that can be defined within the ChaosEngine for any Chaos Experiment.
-
-### [ChaosEngine](chaos-engine.md)
-
-The ChaosEngine CR is the main user-facing chaos custom resource with a namespace scope and is designed to hold information around how the chaos experiments are executed.
-
-### [ChaosResult](chaos-result.md)
-
-ChaosResult resource holds the results of a ChaosExperiment with a namespace scope.
+Probes are pluggable checks that can be defined within the ChaosEngine for any Chaos Fault.
### [ChaosHub](chaoshub.md)
-ChaosHub allows you to orchestrate chaos scenarios from the Public **[ChaosHub](http://hub.litmuschaos.io/)** or an alternate source for the Experiments.
+ChaosHub allows you to orchestrate chaos experiments from the Public **[ChaosHub](http://hub.litmuschaos.io/)** or an alternate source for the Faults.
-### [Chaos Scenario](chaos-workflow.md)
+### [Chaos Experiment](chaos-workflow.md)
-Chaos Scenario is a set of different operations coupled together to achieve desired chaos impact on a Kubernetes Cluster.
+Chaos Experiment is a set of different operations coupled together to achieve desired chaos impact on a Kubernetes Cluster.
-### [Observability](workflow-statistics.md)
+### [Chaos Infrastructure](infrastructure.md)
-Monitoring and observability during and post chaos using built-in Litmus analytics dashboard as well as external observability tools.
+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)
@@ -42,7 +30,7 @@ Role Privileges of different users in the ChaosCenter.
### [Projects](projects.md)
-Project management system which can be used for working on chaos scenario with multiple different projects across different chaos delegates.
+Project management system which can be used for working on chaos experiment with multiple different projects across different chaos infrastructures.
### [Teaming](probes.md)
@@ -50,4 +38,4 @@ Teaming feature to facilitate collaboration between users using project level ro
### [GitOps](gitops.md)
-GitOps feature in Litmus enables you to configure a single source of truth for your chaos scenarios and experiments.
+GitOps feature in Litmus enables you to configure a single source of truth for your chaos experiments and faults.
diff --git a/website/docs/concepts/probes.md b/website/docs/concepts/probes.md
index 9a6a3d28..c28b22b5 100644
--- a/website/docs/concepts/probes.md
+++ b/website/docs/concepts/probes.md
@@ -1,16 +1,16 @@
---
id: probes
-title: Probes
-sidebar_label: Probes
+title: Resilience Probes
+sidebar_label: Resilience Probes
---
---
-In Litmus, Probes are pluggable checks that can be defined within the ChaosEngine for any Chaos Experiment. The experiment pods execute these checks based on the mode they are defined in & factor their success as necessary conditions in determining the verdict of the experiment (along with the standard `in-built` checks).
+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](chaos-engine.md) Custom Resources and promql queries (for Prometheus Probes)
+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
@@ -38,10 +38,10 @@ Some common attributes shared between the Probes:
- **interval**: The period between subsequent retries
- **probePollingInterval**: The time interval for which continuous probe should be sleep after each iteration
- **initialDelaySeconds**: Represents the initial waiting time interval for the probes.
-- **stopOnFailure**: It can be set to true/false to stop or continue the experiment execution after probe fails
+- **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 experiment's serviceAccount `(-sa)` permissions, then the additional permissions should be provided inside the corresponding Role/ClusterRole bind with the serviceAccount `(-sa)`.
+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)`.
:::
---
@@ -50,11 +50,11 @@ If probe needs any additional RBAC permissions other than the experiment's servi
### httpProbe
-The `httpProbe` allows developers to specify a URL which the experiment uses to gauge health/service availability (or other custom conditions) as part of the entry/exit criteria. The received status code is mapped against an expected status. It supports http `Get` and `Post` methods.
+The `httpProbe` allows developers to specify a URL which the fault uses to gauge health/service availability (or other custom conditions) as part of the entry/exit criteria. The received status code is mapped against an expected status. It supports http `Get` and `Post` methods.
In HTTP `Get` method it sends a http `GET` request to the provided url and matches the response code based on the given criteria(`==`, `!=`, `oneOf`).
-In HTTP `Post` method it sends a http `POST` request to the provided url. The http body can be provided in the `body` field. In the case of a complex POST request in which the body spans multiple lines, the `bodyPath` attribute can be used to provide the path to a file consisting of the same. This file can be made available to the experiment pod via a ConfigMap resource, with the ConfigMap name being defined in the [ChaosEngine](chaos-engine.md) OR the ChaosExperiment CR.
+In HTTP `Post` method it sends a http `POST` request to the provided url. The http body can be provided in the `body` field. In the case of a complex POST request in which the body spans multiple lines, the `bodyPath` attribute can be used to provide the path to a file consisting of the same. This file can be made available to the fault pod via a ConfigMap resource, with the ConfigMap name being defined in the [ChaosEngine](glossary.md) OR the ChaosExperiment CR.
It can be defined at `.spec.experiments[].spec.probe` inside ChaosEngine.
> `body` and `bodyPath` are mutually exclusive
@@ -87,7 +87,7 @@ The `httpProbe` is better used in the Continuous mode of operation as a parallel
The `cmdProbe` allows developers to run shell commands and match the resulting output as part of the entry/exit criteria. The intent behind this probe was to allow users to implement a non-standard & imperative way for expressing their hypothesis. For example, the cmdProbe enables you to check for specific data within a database, parse the value out of a JSON blob being dumped into a certain path or check for the existence of a particular string in the service logs.
-In order to enable this behaviour, the probe supports an inline mode in which the command is run from within the experiment image as well as a source mode, where the command execution is carried out from within a new pod whose image can be specified. While inline is preferred for simple shell commands, source mode can be used when application-specific binaries are required. The cmdProbe can be defined at `.spec.experiments[].spec.probe` the path inside the ChaosEngine.
+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:
@@ -99,7 +99,7 @@ probe:
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
+ source: # omit this tag to "inline" the probe
image: '/'
hostNetwork: false
mode: 'Edge'
@@ -114,7 +114,7 @@ probe:
### k8sProbe
-With the proliferation of custom resources & operators, especially in the case of stateful applications, the steady-state is manifested as status parameters/flags within Kubernetes resources. k8sProbe addresses verification of the desired resource state by allowing users to define the Kubernetes GVR (group-version-resource) with appropriate filters (field selectors/label selectors). The experiment makes use of the Kubernetes Dynamic Client to achieve this.The `k8sProbe` can be defined at `.spec.experiments[].spec.probe` the path inside ChaosEngine.
+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.
@@ -144,9 +144,9 @@ probe:
### **promProbe**
-The `promProbe` allows users to run Prometheus queries and match the resulting output against specific conditions. The intent behind this probe is to allow users to define metrics-based SLOs in a declarative way and determine the experiment verdict based on its success. The probe runs the query on a Prometheus server defined by the `endpoint`, and checks whether the output satisfies the specified `criteria`.
+The `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 experiment pod via a ConfigMap resource, with the ConfigMap being passed in the ChaosEngine OR the ChaosExperiment CR.
+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.
@@ -173,9 +173,9 @@ probe:
## Probe Status & Deriving Inferences
-The litmus chaos experiments run the probes defined in the ChaosEngine and update their stage-wise success in the ChaosResult custom resource, with details including the overall `probeSuccessPercentage` (a ratio of successful checks v/s total probes) and failure step, where applicable. The success of a probe is dependent on whether the expected status/results are met and also on whether it is successful in all the experiment phases defined by the probe’s execution mode. For example, probes that are executed in “Edge” mode, need the checks to be successful both during the pre-chaos & post-chaos phases to be declared as successful.
+The 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 an experiment is the logical conjunction of all probes defined in the ChaosEngine and an inbuilt entry/exit criteria. Failure of either indicates a failed hypothesis and is deemed experiment failure.
+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.
@@ -230,7 +230,7 @@ Events:
## Probe Chaining
-Probe chaining enables reuse of probe a result represented by the template function `{{ ..probeArtifact.Register}})` in subsequent "downstream" probes defined in the ChaosEngine. Note that the order of execution of probes in the experiment depends purely on the order in which they are defined in the ChaosEngine.
+Probe chaining 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`.
@@ -622,7 +622,7 @@ This section describes the different fields of the litmus probes and the possibl
Notes
-
The .httpProbe/inputs.url contains the URL which the experiment uses to gauge health/service availability (or other custom conditions) as part of the entry/exit criteria.
+
The .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.
@@ -783,7 +783,7 @@ This section describes the different fields of the litmus probes and the possibl
Notes
-
The .httpProbe/inputs.method.post.bodyPath This field is used in case of complex POST request in which the body spans multiple lines, the bodyPath attribute can be used to provide the path to a file consisting of the same. This file can be made available to the experiment pod via a ConfigMap resource, with the ConfigMap name being defined in the ChaosEngine OR the ChaosExperiment CR.
+
The .httpProbe/inputs.method.post.bodyPath This field is used in case of complex POST request in which the body spans multiple lines, the bodyPath attribute can be used to provide the path to a file consisting of the same. This file can be made available to the fault pod via a ConfigMap resource, with the ConfigMap name being defined in the ChaosEngine OR the ChaosExperiment CR.
@@ -900,7 +900,7 @@ This section describes the different fields of the litmus probes and the possibl
Notes
-
The .promProbe/inputs.queryPath This field is used in case of complex queries that spans multiple lines, the queryPath attribute can be used to provide the path to a file consisting of the same. This file can be made available to the experiment pod via a ConfigMap resource, with the ConfigMap name being defined in the ChaosEngine OR the ChaosExperiment CR.
+
The .promProbe/inputs.queryPath This field is used in case of complex queries that spans multiple lines, the queryPath attribute can be used to provide the path to a file consisting of the same. This file can be made available to the fault pod via a ConfigMap resource, with the ConfigMap name being defined in the ChaosEngine OR the ChaosExperiment CR.
@@ -1028,7 +1028,7 @@ This section describes the different fields of the litmus probes and the possibl
Description
-
Flags to hold the stop or continue the experiment on probe failure
+
Flags to hold the stop or continue the fault on probe failure
Type
@@ -1040,7 +1040,7 @@ This section describes the different fields of the litmus probes and the possibl
Notes
-
The .runProperties.stopOnFailure can be set to true/false to stop or continue the experiment execution after probe fails
+
The .runProperties.stopOnFailure can be set to true/false to stop or continue the fault execution after probe fails
@@ -1115,19 +1115,21 @@ This section describes the different fields of the litmus probes and the possibl
-## Resources
+## Summary
-
+Probes are pluggable checks that can be defined within the ChaosEngine for any Chaos Experiment. There are four kinds of probes `httpProbe` (allows developers to specify a URL which the 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).
-## Summary
+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 are pluggable checks that can be defined within the ChaosEngine for any Chaos Experiment. There are four kinds of probes `httpProbe` (allows developers to specify a URL which the experiment uses to gauge health/service availability as part of the entry/exit criteria), `cmdProbe` (allows developers to run shell commands and match the resulting output as part of the entry/exit criteria), `k8sProbe` (addresses verification of the desired resource state by allowing users to define the Kubernetes GVR with appropriate filters) and `promProbe` (allows users to run Prometheus queries and match the resulting output against specific conditions).
+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.
-The different modes these probes can be used in are `SoT`, `EoT`, `Edge`, `Continuous` and `OnChaos`. The litmus chaos experiments run the probes defined in the ChaosEngine and update their stage-wise success in the ChaosResult custom resource with `probeSuccessPercentage`. A `probeSuccessPercentage` is the ratio of successful checks v/s total probes.
+:::note
+With the latest release of LitmusChaos 3.0.0:
-Probes can be Chained, Probe chaining enables reuse of probe, the order of execution of probes in the experiment depends purely on the order in which they are defined in the ChaosEngine.
+
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 ChaosResult Custom Resource](chaos-result.md)
-- [Explore the ChaosEngine Custom Resource](chaos-engine.md)
+- [Explore the Custom Resources](glossary.md)
diff --git a/website/docs/concepts/projects.md b/website/docs/concepts/projects.md
index 2ea59eab..18bd1d2f 100644
--- a/website/docs/concepts/projects.md
+++ b/website/docs/concepts/projects.md
@@ -6,11 +6,11 @@ sidebar_label: Projects
---
-The ChaosCenter comes with a project management system which can be used for working on chaos scenarios with multiple different projects across different chaos delegates.
+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 abpout the concept of `projects`, it is important to note that a `project` signifies a separation between Chaos Delegates,Schedules, [Visualization](visualize-workflow.md), and Teams (discussed in the next section) configurations, and prior knowledge of these will prove fruitful in understanding the concept of `projects` in-depth.
+Before learning about the concept of `projects`, it is important to note that a `project` signifies a separation between Chaos infrastructures, Schedules, [Visualization](visualize-experiment.md), and Teams (discussed in the next section) configurations, and prior knowledge of these will prove fruitful in understanding the concept of `projects` in-depth.
## Projects
diff --git a/website/docs/concepts/teaming.md b/website/docs/concepts/teaming.md
index a8abfae9..2ab89eab 100644
--- a/website/docs/concepts/teaming.md
+++ b/website/docs/concepts/teaming.md
@@ -14,9 +14,9 @@ Each user has a default project created on user creation by the admin for which
Teaming is based on the following principles and each user can have one of the 3 project roles:
-- **Owner:** One who created the project and owns it. Only the owner has permission to manage(invite or remove) the members in his/her project. The owner can schedule chaos scenarios, update chaos scenarios, delete chaos scenarios and view the analytics.
+- **Owner:** One who created the project and owns it. Only the owner has permission to manage(invite or remove) the members in his/her project. The owner can schedule chaos experiments, update and delete chaos experiments.
- **Editor:** Members invited with the editor role can do everything an owner can except for managing the project.
-- **Viewer:** Members having a viewer role can only view the analytics related to the chaos scenarios and the chaos scenarios themselves, but are not given the permission to schedule chaos scenarios in the project.
+- **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
diff --git a/website/docs/concepts/user-management.md b/website/docs/concepts/user-management.md
index 9930d583..b4146745 100644
--- a/website/docs/concepts/user-management.md
+++ b/website/docs/concepts/user-management.md
@@ -22,7 +22,7 @@ ChaosCenter supports two portal level roles for defining the privilege levels of
**Admin** is the highest privilege level offered in the portal and the admin has complete access to all the features offered by the portal.
-**Non-admin users:** Non-admin users get all the same privileges as an admin level user, with the exception of the user management feature which is an admin exclusive feature to facilitate an admin to manage their teams on the portal. (Example: In an organization, multiple different teams might be formed to inject chaos on different chaos delegates which have no layover between each other.)
+**Non-admin users:** Non-admin users get all the same privileges as an admin-level user, with the exception of the user management feature which is an admin-exclusive feature to facilitate an admin to manage their teams on the portal. (Example: In an organization, multiple different teams might be formed to inject chaos into different chaos infrastructures that have no layover between each other.)
## Learn more
diff --git a/website/docs/concepts/visualize-experiment.md b/website/docs/concepts/visualize-experiment.md
new file mode 100644
index 00000000..d0129178
--- /dev/null
+++ b/website/docs/concepts/visualize-experiment.md
@@ -0,0 +1,42 @@
+---
+id: visualize-experiment
+title: Visualize the Chaos Experiment Execution
+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 should be required before creating a Chaos Experiment:
+
+- ChaosCenter
+- [Chaos Experiments](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.
+
+## Visualize 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](probes.md)
+- [What is a Chaos Experiment](chaos-workflow.md)
diff --git a/website/docs/concepts/visualize-workflow.md b/website/docs/concepts/visualize-workflow.md
deleted file mode 100644
index f6629d39..00000000
--- a/website/docs/concepts/visualize-workflow.md
+++ /dev/null
@@ -1,71 +0,0 @@
----
-id: visualize-workflow
-title: Visualize the Chaos Scenario Execution
-sidebar_label: Visualize Chaos Scenario
----
-
----
-
-Visualization is an important aspect while doing chaos engineering. It allows the user to discover and inspect different changes that occur during a Chaos Scenario execution.
-With ChaosCenter, the real-time data and status of the chaos scenarios can be observed. Valuable information like pod logs, chaos scenario status, chaos results can also be viewed.
-
-## Prerequisites
-
-The following should be required before creating a Chaos Scenario:
-
-- ChaosCenter
-- [Chaos Scenarios](chaos-workflow.md)
-
-## Litmus Chaos Scenario
-
-After scheduling a chaos scenario, you are redirected to the Litmus Chaos Scenario page which is divided into 2 sections `Runs` and `Schedules`.
-
-### Runs
-
-This section consists the list of individual chaos scenario
-runs and its related data like `Chaos Scenario Name`, `Status`, `Reliability Score` etc.
-This table displays the real-time status of the chaos scenarios.
-
-### Schedules
-
-This section consists the list of chaos scenario schedules.
-These schedules can consist one time chaos scenario runs or Cron Chaos Scenarios. User can perfom serveral operations in this table, few of them are listed below:
-
-- Disable a Cron Chaos Scenario
-- Download the chaos scenario manifest
-- Save the chaos scenarios as a template
-- Edit a schedule
-- Re-run a chaos scenario etc
-
-## Visualize a Litmus Chaos Scenario
-
-To observe a chaos scenario, user can either click on the chaos scenario name or click on the three dots and select `Show the chaos scenario` option in the runs table.
-
-
-The Chaos Scenario Details page is divided into 2 sections:
-
-- **Graph View**: In this section a realtime graph of the chaos scenario is displayed. This graph contains valuable information regarding the status of individual steps of the chaos scenario.
-
- To view the details of the step, you can click on the individual nodes. This will open a field which displays the node details and the logs related to it.
-
-
-
-:::note
-If the selected node is an experiment pod which consists of ChaosEngine CRD, a button to Download the logs will be available. Similarly, a tab named `Chaos Results` will also be available, which displays the ChaosResult of the experiment once the chaos scenario execution is completed.
-:::
-
-- **Table View** : Similar to the Graph View, this tab consists the table view of the chaos scenario. The table consists of the different chaos scenario steps along with their status.
-
-
- On clicking the View Logs & Results button in the table, a pop-over is displayed with the logs of the selected step.
-
-
-## Summary
-
-After scheduling a chaos scenario, a user can view the details of the running chaos scenario from the ChaosCenter. ChaosCenter provides a realtime graph that is used to visualise the chaos scenario and get the details of individual step of the chaos scenario. Important details like the logs and target applications can be viewed from ChaosCenter. These logs are also downloadable. User can view the details in 2 different ways i.e `Graph View` and `Table View`. Once the chaos scenario exection is completed, the resiliency score is calcualted and the ChaosResult for the ChaosEngine pods are available now.
-
-## Learn More
-
-- [Explore Probes](probes.md)
-- [What is a Chaos Scenario](chaos-workflow.md)
-- [Examine the ChaosResult](chaos-result.md)
diff --git a/website/docs/concepts/workflow-statistics.md b/website/docs/concepts/workflow-statistics.md
deleted file mode 100644
index 8ab4714e..00000000
--- a/website/docs/concepts/workflow-statistics.md
+++ /dev/null
@@ -1,50 +0,0 @@
----
-id: workflow-statistics
-title: Chaos Scenarios Statistics
-sidebar_label: Scenarios Statistics
----
-
----
-
-Chaos injections often tends to disrupt tightly coupled micro-services and processes. Visualizing the results and plotting analytical graphs prove to be useful under such circumstances. An analytical overview of chaos scenarios for an entire month or a year can help in benchmarking release cycles and building a viable cloud-native product. Also a comparative study over time or rather just being able to observe and plot resiliency scores across different types of chaos scenarios on different subsystems provide a conclusive summary of the reliability metrics for an application under test (AUT) and the supporting platform or infrastructure.
-
-## Prerequisites
-
-The following should be required before knowing about chaos scenario statistics:
-
-- [Chaos Scenarios](chaos-workflow.md)
-- [Visualize Chaos Scenarios](visualize-workflow.md)
-
-## Data flow architecture
-
-The chaos center automatically detects scheduled chaos scenario runs on all connected chaos delegates for a project and provides statistical graphs and visualizations. Data for chaos scenarios runs and chaos results from all the chaos delegates are stored in a mongoDB database which is then ingested into analytical pipelines in the control plane server to transform the raw data into meaningful insights for browsing and reporting.
-
-
-
-Data flow for statistical analysis
-
-
-## Chaos engine context
-
-The `context` is a user defined label for a chaos engine to indicate the intent or the target of chaos. Some of it's uses are for naming AUT, micro-service, infrastructure resource etc. Engine context can be added or updated by the user via the UI. It is used to filter chaos experiments, results, tests during statistical analysis and for filtering chaos injection events during real time monitoring of application or infrastructure metrics interleaved with chaos. It defaults to the target application label and namespace separated by `_` while using chaos center for scheduling chaos scenarios.
-
-## Chaos scenario subject
-
-The `subject` is a user defined label for a chaos scenario to indicate the intent or the target of chaos. Some of it's uses are for naming AUT, micro-service, infrastructure resource etc. Chaos Scenarios subject can be added or updated by the user via the UI. It is used to filter chaos scenarios during statistical analysis and is stored as a metadata for referencing to a particular application group or version on a given target cluster with chaos delegate. It defaults to the target application name and namespace separated by `_` while using chaos center for scheduling chaos scenarios.
-
-## Summary
-
-Statistics of a chaos scenarios schedule across its runs and analyzing application performance across chaos scenarios on a target cluster's AUT are facilitated via the data stored in the persistent storage (mongoDB), collected by the connected chaos delegate plane components like `subscriber` and `chaos-exporter`. Engine `context` and Chaos Scenario `subject` are meant to provide the user with more granular control over the target of chaos while analyzing results or monitoring system or application metrics in real-time under stress or chaos.
-
-## Resources
-
-
-
-
-
-[Analyzing chaos scenarios](https://dev.to/code_igx/analysing-chaos-workflows-with-litmus-portal-4e67)
-
-## Learn More
-
-- [Explore Probes](probes.md)
-- [Application and infrastructure monitoring](app-infra-monitoring.md)
diff --git a/website/docs/faq.md b/website/docs/faq.md
index dd4aaff4..968dc757 100644
--- a/website/docs/faq.md
+++ b/website/docs/faq.md
@@ -6,13 +6,19 @@ 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 litmus portal-server deployment, also there are the db user and db password keys that can be tuned in the configmap like `DB_USER: "admin"` and `DB_PASSWORD: "1234"`.
+We 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.
-### 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.
+### 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).
@@ -24,63 +30,51 @@ Other than that there is another key in the control plane’s configmap `litmus-
The above holds for the control plane and self chaos delegate, for the external chaos delegates which can be connected using the litmusctl CLI you can provide the scope of the chaos delegate while using the utility to connect your other cluster to the control plane with access to just a single namespace or cluster-wide access.
Using a combination of AgentScope: cluster and `PORTAL_SCOPE` env set to cluster would give you cluster-admin privileges to inject chaos on all namespaces where the control plane/portal is installed. For external chaos delegates just selecting the scope of installation as cluster would be sufficient via litmusctl.
-### What does failed status of chaos scenario means in LitmusPortal?
-
-Failed status indicates that either there is some misconfiguration in the chaos scenario or the default hypothesis of experiment was disproved and some of the experiments in the chaos scenario failed, In such case the resiliency score will be less than 100.
-
-### How can I setup chaoshub of my own gitlab repo in Litmus Portal?
-
-In the litmus portal when you go to the chaoshub section and you click on connect new hub button, you can see that there are two modes of authentication i.e public mode and private mode. In public mode, you only have to provide the git URL and branch name.
-
-In private mode, we have two types of authentication; Access token and SSH key.
-For the access token, go to the settings of GitLab and in the Access token section, add a token with read repository permission. After getting the token, go to the Litmus portal and provide the GitLab URL and branch name along with the access token. After submitting, your own chaos hub is connected to the Litmus portal.
-For the SSH key, click on the SSH and it will generate a public key. You have to use this public key and put it in your GitLab account. Just go to the settings of GitLab, you can see the SSH key section, go to the SSH key section and add your public key. After adding the public key. Get the ssh type URL of the git repository and put it in the Litmus Portal along with the branch. After submitting, your own chaoshub is connected to the Litmus Portal.
+### Does Litmus 3.0 support backward compatibility with Litmus 2.0?
-### Does Litmus 2.0 maintain backward compatibility with kubernetes?
-
-Yes, Litmus maintains a separate CRD manifest to support backward compatibility.
+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 experiments outside of the k8s cluster which is dockerized under this image litmuschaos/ansible-runner:ci. But other components such as chaos-operator, chaos-exporter, and runner are Kubernetes native. They requires k8s cluster to run on it.
-
-### How to achieve High Availability of MongoDB and how can we add persistence to MongoDB?
+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.
-Currently, the MongoDB instance is not HA, we can install the MongoDB operator along with mongo to achieve HA. This MongoDB CRD allows for specifying the desired size and version as well as several other advanced options. Along with the Mongodb operator, we will use the MongoDB sts with PV to add the persistence.
+## Chaos Experiment
-### Can I create chaos scenarios without using dashboard?
+### What does failed status of chaos experiment means in LitmusPortal?
-Currently, you can’t. But we are working on it. Shortly we will publish samples for doing this via API/SDK and litmusctl.
-
-### Does Litmusctl support actions that are currently performed from the portal dashboard?
+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.
-For now, you can create chaos delegates and projects, also you can get the chaos delegates and project details by using litmusctl. To know more about litmusctl please refer to the [documentation of litmusctl](https://github.com/litmuschaos/litmusctl/blob/master/Usage.md).
-
-### What is the minimum system requirement to run Portal and chaos delegate together?
-
-To run LitmusPortal you need to have a minimum of 1 GiB memory and 1 core of CPU free.
+### How is resilience score calculated?
-### Can I use Litmus in Production?
+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).
-Yes, you can use Litmuschaos in production. Litmus has a wide variety of experiments and is designed as per the principles of chaos. But, if you are new to Chaos Engineering, we would recommend you to first try Litmus on your dev environment, and then after getting the confidence, you should use it in Production.
+## Chaoshub
-### How is resilience score calculated?
+### How can I setup chaoshub of my own gitlab repo in Chaoscenter?
-The Resilience score is calculated on the basis of the weightage and the Probe Success Percentage of the experiment. Resilience for one single experiment is the multiplication of the weight given to that experiment and the Probe Success Percentage. Then we get the total test result by adding the resilience score of all the experiments. The Final Resilience Score is calculated by dividing the total test result by the sum of the weights of all the experiments combined in the single chaos scenario. For more detail refer to [this blog](https://dev.to/litmus-chaos/how-the-resilience-score-algorithm-works-in-litmus-1d22).
+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.
-### How can we use litmus in our DevOps pipeline/cycle?
+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.
-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.
+## Gitops
### How can users integrate Litmuschaos in their environment with Gitops?
-Gitops feature in Litmus enables users to sync chaos scenarios from a configured git repo, any chaos scenario inserts/updates made to the repo will be monitored and picked up by litmus portal and will be executed on the target cluster. Litmus portal gitops also includes an event-driven chaos injection feature where users can annotate an application to be watched for changes and if and when the change happens chaos scenarios can be triggered automatically. This integrates with other gitops tools like flux/argo cd and enables users to automatically run chaos scenarios whenever a new release happens or a particular change occurs in the application.
+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 scenarios created will be stored in the configured repo in the path `litmus//.yaml`.
+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 executiom 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?
@@ -93,3 +87,13 @@ litmusctl will prompt if your installed litmusctl and litmus control plane are c
### 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/docs/getting-started/create-your-first-custom-chaos-experiment.md b/website/docs/getting-started/create-your-first-custom-chaos-experiment.md
new file mode 100644
index 00000000..cb5843b7
--- /dev/null
+++ b/website/docs/getting-started/create-your-first-custom-chaos-experiment.md
@@ -0,0 +1,7 @@
+---
+id: create-your-first-custom-chaos-experiment
+title: create-your-first-custom-chaos-experiment
+sidebar_label: create-your-first-custom-chaos-experiment
+---
+
+create-your-first-custom-chaos-experiment placeholder
\ No newline at end of file
diff --git a/website/docs/getting-started/installation.md b/website/docs/getting-started/installation.md
index 48ef6907..772182f0 100644
--- a/website/docs/getting-started/installation.md
+++ b/website/docs/getting-started/installation.md
@@ -22,7 +22,7 @@ Before deploying LitmusChaos, make sure the following items are there
## Installation
-Users looking to use Litmus for the first time have two options available to them today. One way is to use a hosted Litmus service like [Harness Chaos Engineering SaaS](https://cloud.chaosnative.com/). Alternatively, users looking for some more flexibility can install Litmus into their own Kubernetes cluster.
+Users 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.
@@ -38,9 +38,9 @@ import TabItem from '@theme/TabItem';
Refer to the below details for Self-Hosted Litmus installation.
- Harness offers a free service for community members which makes getting started with Litmus easy. Create an account to get started. Once logged in, create a new hosted control plane and connect to it via the up CLI. Litmus can be used as a hosted cloud service using Harness Chaos Engineering SaaS. Harness Chaos Engineering SaaS executes your Chaos Scenarios in the cloud by managing all your Chaos Control Plane components, while the Chaos Execution Plane components exist on your Kubernetes cluster as part of an external chaos delegate.
+ 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.
+ To get started with Harness Chaos Engineering SaaS, visit Harness Chaos Engineering SaaS and register for free. You can skip the below installation steps.
@@ -94,13 +94,7 @@ Visit https://docs.litmuschaos.io to find more info.
### **Install Litmus using kubectl**
-#### **Install Litmus ChaosCenter**
-
-Applying the manifest file will install all the required service account configuration and ChaosCenter.
-
-```bash
-kubectl apply -f https://litmuschaos.github.io/litmus/3.0.0-beta8/litmus-3.0.0-beta8.yaml
-```
+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).
---
@@ -117,11 +111,15 @@ kubectl apply -f https://litmuschaos.github.io/litmus/3.0.0-beta8/litmus-3.0.0-b
Expected Output
```bash
- NAME READY STATUS RESTARTS AGE
- litmusportal-server-6fd57cc89-6w5pn 1/1 Running 0 57s
- litmusportal-auth-server-7b596fff9-5s6g5 1/1 Running 0 57s
- mongo-0 1/1 Running 0 57s
- litmusportal-frontend-55974fcf59-cxxrf 1/1 Running 0 58s
+ 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:
@@ -133,12 +131,14 @@ kubectl apply -f https://litmuschaos.github.io/litmus/3.0.0-beta8/litmus-3.0.0-b
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
+ 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
```
---
@@ -162,17 +162,17 @@ mongo-service ClusterIP 10.43.227.10 2701
mongo-headless-service ClusterIP None 27017/TCP 101s
```
-> **Note**: In this case, the PORT for `litmusportal-frontend-service` is `30385`. Yours will be different.
+> **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:30385/
+http://172.17.0.3:31846/
```
-> Where `172.17.0.3` is my NodeIP and `30385` is the frontend service PORT. If using a LoadBalancer, the only change would be to provide a `:`. [Learn more about how to access ChaosCenter with LoadBalancer](../user-guides/setup-without-ingress.md#with-loadbalancer)
+> 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)
You should be able to see the Login Page of Litmus ChaosCenter. The **default credentials** are
@@ -187,34 +187,9 @@ By default you are assigned with a default project with Owner permissions.
-## **Verify Successful Registration of the Self Chaos Delegate**
-
-Once the project is created, the cluster is automatically registered as a chaos target via installation of [Chaos Delegate](resources.md#chaosagents). This is represented as [Self Chaos Delegate](resources.md#types-of-chaosagents) in [ChaosCenter](resources.md#chaoscenter).
-
-```bash
-kubectl get pods -n litmus
-```
-
-```bash
-NAME READY STATUS RESTARTS AGE
-chaos-exporter-547b59d887-4dm58 1/1 Running 0 5m27s
-chaos-operator-ce-84ddc8f5d7-l8c6d 1/1 Running 0 5m27s
-event-tracker-5bc478cbd7-xlflb 1/1 Running 0 5m28s
-litmusportal-frontend-97c8bf86b-mx89w 1/1 Running 0 15m
-litmusportal-server-6fd57cc89-6w5pn 1/1 Running 0 15m
-litmusportal-auth-server-7b596fff9-5s6g5 1/1 Running 0 15m
-mongo-0 1/1 Running 0 15m
-subscriber-958948965-qbx29 1/1 Running 0 5m30s
-workflow-controller-78fc7b6c6-w82m7 1/1 Running 0 5m32s
-```
-
-## Resources
-
-
-
## Learn more
- [Install ChaosCenter in Namespace Scope](../user-guides/chaoscenter-namespace-scope-installation.md)
-- [Connect External Chaos Delegates to ChaosCenter](../user-guides/chaosagents-installation.md)
+- [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/docs/getting-started/run-your-first-workflow.md b/website/docs/getting-started/run-your-first-experiment.md
similarity index 99%
rename from website/docs/getting-started/run-your-first-workflow.md
rename to website/docs/getting-started/run-your-first-experiment.md
index 6f15b463..4af01a5d 100644
--- a/website/docs/getting-started/run-your-first-workflow.md
+++ b/website/docs/getting-started/run-your-first-experiment.md
@@ -1,5 +1,5 @@
---
-id: run-your-first-workflow
+id: run-your-first-experiment
title: Run your First Chaos Scenario in 5 minutes
sidebar_label: Run Your First Chaos Scenario
---
diff --git a/website/docs/glossary.md b/website/docs/glossary.md
index b69b8a12..4ac3a594 100644
--- a/website/docs/glossary.md
+++ b/website/docs/glossary.md
@@ -1,7 +1,59 @@
---
id: glossary
title: Glossary
-sidebar_label: glossary
+sidebar_label: Glossary
---
-## Coming Soon
+:::note
+Pleas 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 Name
+
Description
+
User Guides
+
+
+
ChaosEngine
+
Contains the ChaosEngine specifications user-guide
+
+## Terminology Changes
+
+With the latest release of LitmusChaos 3.0.0 the following terminologies have been changed:
+
+
+
+
Old terminology
+
Updated terminology
+
+
+
Chaos Experiment
+
Chaos Fault
+
+
+
Chaos Scenario/Workflow
+
Chaos Experiment
+
+
+
Chaos Delegate/Agent
+
Chaos Infrastructure
+
+
diff --git a/website/docs/integrations/grafana.md b/website/docs/integrations/grafana.md
index 8c149d57..24bd7876 100644
--- a/website/docs/integrations/grafana.md
+++ b/website/docs/integrations/grafana.md
@@ -12,10 +12,9 @@ Chaos Engineering is the discipline of experimenting on a system to build confid
The following should be required before integrating Grafana with litmus 2.0:
-- [Running Chaos Scenarios](../getting-started/run-your-first-workflow.md)
+- [Running Chaos Experiments](../getting-started/run-your-first-experiment.md)
- [Prometheus TSDB](https://prometheus.io/)
- [Prometheus Integration](prometheus.md)
-- [Application and infrastructure monitoring](../concepts/app-infra-monitoring.md)
## Grafana setup with provisioned data source amd dashboards using Prometheus deployment with scrape jobs
@@ -270,5 +269,4 @@ sum(litmuschaos_awaited_experiments{job="litmus/chaos-exporter"})
## Learn More
-- [Application and infrastructure monitoring](../concepts/app-infra-monitoring.md)
- [Observability Setup](../user-guides/observability-set-up.md)
diff --git a/website/docs/integrations/prometheus.md b/website/docs/integrations/prometheus.md
index f0a4d4a1..e4c5aa97 100644
--- a/website/docs/integrations/prometheus.md
+++ b/website/docs/integrations/prometheus.md
@@ -12,10 +12,9 @@ LitmusChaos facilitates real-time monitoring for events and metrics using it’s
The following should be required before integrating Prometheus in litmus 2.0:
-- [Running Chaos Scenarios](../getting-started/run-your-first-workflow.md)
+- [Running Chaos Scenarios](../getting-started/run-your-first-experiment.md)
- [Prometheus TSDB](https://prometheus.io/)
- [Probes](../concepts/probes.md)
-- [Data source](../concepts/datasource.md)
## Prometheus deployment with scrape job
@@ -200,7 +199,6 @@ Know more on promProbe [here](../concepts/probes.md)
## Learn More
-- [Application and infrastructure monitoring](../concepts/app-infra-monitoring.md)
- [Observability Setup](../user-guides/observability-set-up.md)
- [Configure Data Source](../user-guides/configure-datasource.md)
- [Grafana Integration](grafana.md)
diff --git a/website/docs/introduction/features.md b/website/docs/introduction/features.md
index 7cdc1406..92149836 100644
--- a/website/docs/introduction/features.md
+++ b/website/docs/introduction/features.md
@@ -33,17 +33,6 @@ A high-level feature overview of Litmus 2.0 are as follows
Visualize chaos scenario run statistics and aggregated schedules
-
Compare two or more Chaos Scenarios
-
Upload shared/downloadable dashboards available in the community
-
Edit queries, Tune dashboards to create a custom one from scratch
-
Monitor effect of chaos in real time with interleaved events and metrics from Prometheus Datasource
-
-
- Chaos Scenario Management
@@ -74,9 +63,8 @@ Below is a high level comparison between Litmus 1.x and Litmus 2.0 providing a h
## Learn more
-- [Run your first chaos scenario in 5 minutes](../getting-started/run-your-first-workflow.md)
+- [Run your first chaos scenario in 5 minutes](../getting-started/run-your-first-experiment.md)
- [Install Litmus](../getting-started/installation.md)
-- [Visualize Chaos Scenarios](../concepts/visualize-workflow.md)
+- [Visualize Chaos Scenarios](../concepts/visualize-experiment.md)
- Chaos Schedule
-- [Monitoring](../concepts/app-infra-monitoring.md)
- [View the different User Guides](../user-guides/overview.md)
diff --git a/website/docs/litmusctl/chaos-workflow-creation.md b/website/docs/litmusctl/chaos-workflow-creation.md
deleted file mode 100644
index f616d9b3..00000000
--- a/website/docs/litmusctl/chaos-workflow-creation.md
+++ /dev/null
@@ -1,131 +0,0 @@
----
-id: chaos-workflow-creation
-title: Create Scenarios using Litmusctl
-sidebar_label: Create Chaos Scenarios
----
-
----
-
-> Notes:
->
-> - For litmusctl v0.10.0 or latest
-> - Compatible with Litmus 2.9.0 or latest
-
-### litmusctl Syntax
-
-`litmusctl` has a syntax to use as follows:
-
-```shell
-litmusctl [command] [TYPE] [flags]
-```
-
-- Command: refers to what you do want to perform (create, get and config)
-- Type: refers to the feature type you are performing a command against (chaos delegate, project etc.)
-- Flags: It takes some additional information for resource operations. For example, `--installation-mode` allows you to specify an installation mode.
-
-Litmusctl is using the `.litmusconfig` config file to manage multiple accounts
-
-1. If the --config flag is set, then only the given file is loaded. The flag may only be set once and no merging takes place.
-2. Otherwise, the ${HOME}/.litmusconfig file is used, and no merging takes place.
-
----
-
-### Steps to create a Chaos Scenario
-
-- To setup an account with litmusctl
-
-```shell
-litmusctl config set-account --endpoint="" --username="" --password=""
-```
-
-- To create a Chaos Scenario by passing a manifest file
- > Note:
- >
- > - To get `project-id`, apply `litmusctl get projects`
- > - To get `chaos-delegate-id`, apply `litmusctl get chaos-delegates --project-id=""`
-
-```shell
-litmusctl create chaos-scenario -f custom-chaos-scenario.yml --project-id="" --chaos-delegate-id=""
-```
-
-#### Verify the new Chaos Scenario
-
-To verify the successful creation, you can either view the list of chaos scenarios at the ChaosCenter dashboard or run the below given command to list the chaos scenarios within a given project.
-
-```shell
-litmusctl get chaos-scenarios --project-id=""
-```
-
-**Output:**
-
-```
-CHAOS SCENARIO ID CHAOS SCENARIO NAME CHAOS SCENARIO TYPE NEXT SCHEDULE CHAOS DELEGATE ID CHAOS DELEGATE NAME LAST UPDATED BY
-9433b48c-4ab7-4544-8dab-4a7237619e09 custom-chaos-scenario-1627980541 Non Cron Scenario None f9799723-29f1-454c-b830-ae8ba7ee4c30 Self-Chaos-Delegate admin
-Showing 1 of 1 chaos scenarios
-```
-
----
-
-### Additional commands
-
-- To list all the chaos scenario runs within a project, issue the following command.
-
-```shell
-litmusctl get chaos-scenario-runs --project-id=""
-```
-
-**Output:**
-
-```
-CHAOS SCENARIO RUN ID STATUS RESILIENCY SCORE CHAOS SCENARIO ID CHAOS SCENARIO NAME TARGET CHAOS DELEGATE LAST RUN EXECUTED BY
-8ceb712c-1ed4-40e6-adc4-01f78d281506 Running 0.00 9433b48c-4ab7-4544-8dab-4a7237619e09 custom-chaos-scenario-1627980541 Self-Chaos-Delegate June 1 2022, 10:28:02 pm admin
-Showing 1 of 1 scenario runs
-```
-
-- To describe a particular chaos scenario, issue the following command.
-
-```shell
-litmusctl describe chaos-scenario 9433b48c-4ab7-4544-8dab-4a7237619e09 --project-id=""
-```
-
-**Output:**
-
-```
-apiVersion: argoproj.io/v1alpha1
-kind: Workflow
-metadata:
- creationTimestamp: null
- labels:
- cluster_id: f9799723-29f1-454c-b830-ae8ba7ee4c30
- subject: custom-chaos-scenario_litmus
- workflow_id: 9433b48c-4ab7-4544-8dab-4a7237619e09
- workflows.argoproj.io/controller-instanceid: f9799723-29f1-454c-b830-ae8ba7ee4c30
- name: custom-chaos-scenario-1627980541
- namespace: litmus
-spec:
-...
-```
-
-- To delete a particular chaos scenario, issue the following command.
-
-```shell
-litmusctl delete chaos-scenario df91c6b2-ad33-45ae-9a2f-00cb87978657 --project-id=""
-```
-
-**Output:**
-
-```
-🚀 Chaos scenario successfully deleted.
-```
-
-For more information related to flags, Use `litmusctl --help`.
-
----
-
-## Learn More
-
-- [Learn More about Litmusctl](installation.md)
-- [Installing Chaos Delegate in interactive mode](./usage-interactive-mode.md)
-- [Installing Chaos Delegate in non interactive mode](./usage-non-interactive-mode.md)
-- [Setup Endpoints and Access ChaosCenter without Ingress](../user-guides/setup-without-ingress.md)
-- [Setup Endpoints and Access ChaosCenter with Ingress](../user-guides/setup-with-ingress.md)
diff --git a/website/docs/litmusctl/installation.md b/website/docs/litmusctl/installation.md
index b0711935..466e0cd7 100644
--- a/website/docs/litmusctl/installation.md
+++ b/website/docs/litmusctl/installation.md
@@ -6,13 +6,13 @@ sidebar_label: Installation
---
-The Litmuschaos command-line tool, litmusctl, allows you to manage litmuschaos's chaos delegate plane. You can use litmusctl to connect and disconnect chaos delegates, create chaos scenarios, project, and manage multiple litmuschaos accounts.
+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 delegates. The CLI currently uses the default path of kubeconfig i.e. `~/.kube/config`.
+- **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)
@@ -20,99 +20,7 @@ Litmusctl CLI requires the following things:
For more information including a complete list of litmusctl operations, see the litmusctl reference documentation.
-- For v0.12.0 or latest: Click here
-- For v0.2.0 or earlier: Click here
-
-## Compatibility matrix
-
-To check compatibility of litmusctl with Chaos Center
-
-
-
litmusctl version
-
Lowest Chaos Center supported version
-
Highest Chaos Center supported version
-
-
-
0.7.0
-
2.4.0
-
2.8.0
-
-
-
0.8.0
-
2.4.0
-
2.8.0
-
-
-
0.9.0
-
2.4.0
-
2.8.0
-
-
-
0.10.0
-
2.9.0
-
3.0.0-beta8
-
-
-
0.11.0
-
2.9.0
-
3.0.0-beta8
-
-
-
0.12.0
-
2.9.0
-
3.0.0-beta8
-
-
-
0.13.0
-
2.9.0
-
3.0.0-beta8
-
-
-
0.14.0
-
2.9.0
-
3.0.0-beta8
-
-
-
0.15.0
-
2.9.0
-
3.0.0-beta8
-
-
-
0.16.0
-
2.9.0
-
3.0.0-beta8
-
-
-
0.17.0
-
2.9.0
-
3.0.0-beta8
-
-
-
0.18.0
-
2.9.0
-
3.0.0-beta8
-
-
-
0.19.0
-
2.9.0
-
3.0.0-beta8
-
-
-
0.20.0
-
2.9.0
-
3.0.0-beta8
-
-
-
0.21.0
-
2.9.0
-
3.0.0-beta8
-
-
-
0.22.0
-
2.9.0
-
3.0.0-beta8
-
-
+- For 0.23.0 or latest: Click here
## Installation
@@ -120,114 +28,50 @@ To install the latest version of litmusctl follow the below steps:
diff --git a/website/docs/litmusctl/usage-interactive-mode.md b/website/docs/litmusctl/usage-interactive-mode.md
deleted file mode 100644
index 4ef02181..00000000
--- a/website/docs/litmusctl/usage-interactive-mode.md
+++ /dev/null
@@ -1,423 +0,0 @@
----
-id: usage-interactive-mode
-title: Installing Chaos Delegate in interactive mode
-sidebar_label: Using interactive mode
----
-
----
-
-# Usage: Litmusctl v0.12.0 (Interactive mode)
-
-> Notes:
->
-> - For litmusctl v0.12.0 or latest
-> - Compatible with Litmus 2.12.0 or latest
-
-### litmusctl Syntax
-
-`litmusctl` has a syntax to use as follows:
-
-```shell
-litmusctl [command] [TYPE] [flags]
-```
-
-- Command: refers to what you do want to perform (connect, create, get and config)
-- Type: refers to the feature type you are performing a command against (chaos-delegate, project etc.)
-- Flags: It takes some additional information for resource operations. For example, `--installation-mode` allows you to specify an installation mode.
-
-Litmusctl is using the `.litmusconfig` config file to manage multiple accounts
-
-1. If the --config flag is set, then only the given file is loaded. The flag may only be set once and no merging takes place.
-2. Otherwise, the ${HOME}/.litmusconfig file is used, and no merging takes place.
-
-Litmusctl supports both interactive and non-interactive(flag based) modes.
-
-> Only `litmusctl connect chaos-delegate` command needs --non-interactive flag, other commands don't need this flag to be in non-interactive mode. If mandatory flags aren't passed, then litmusctl takes input in an interactive mode.
-
-Multiple external Chaos Delegate can be connected to the ChaosCenter with the help of the command line utility [litmusctl](installation.md)
-
-### Steps to connect a Chaos Delegate
-
-- To setup an account with litmusctl
-
-```shell
-litmusctl config set-account
-```
-
-Next, you need to enter ChaosCenter details to login into your ChaosCenter account. Fields to be filled in:
-
-**ChaosCenter URL:** Enter the URL used to access the ChaosCenter.
-
-> Example, https://preview.litmuschaos.io/
-
-**Username:** Enter your ChaosCenter username.
-**Password:** Enter your ChaosCenter password.
-
-```
-Host endpoint where litmus is installed: https://preview.litmuschaos.io/
-Username [Default: admin]: admin
-
-Password:
-account.username/admin configured
-```
-
-- To connect a Chaos Delegate in a cluster mode
-
-```shell
-litmusctl connect chaos-delegate
-```
-
-There will be a list of existing projects displayed on the terminal. Select the desired project by entering the sequence number indicated against it.
-
-```
-Project list:
-1. Project-Admin
-
-Select a project [Range: 1-1]: 1
-```
-
-Next, select the installation mode based on your requirement by entering the sequence number indicated against it.
-
-Litmusctl can install a Chaos Delegate in two different modes.
-
-- cluster mode: With this mode, the Chaos Delegate can run the chaos in any namespace. It installs appropriate cluster roles and cluster role bindings to achieve this mode.
-
-- namespace mode: With this mode, the Chaos Delegate can run the chaos in its namespace. It installs appropriate roles and role bindings to achieve this mode.
-
-Note: With namespace mode, the user needs to create the namespace to install the Chaos Delegate as a prerequisite.
-
-```
-Installation Modes:
-1. Cluster
-2. Namespace
-
-Select Mode [Default: cluster] [Range: 1-2]: 1
-
-🏃 Running prerequisites check....
-🔑 clusterrole ✅
-🔑 clusterrolebinding ✅
-🌟 Sufficient permissions. Installing the Chaos Delegate...
-
-```
-
-Next, enter the details of the new Chaos Delegate.
-
-Fields to be filled in
-
-
-
Field
-
Description
-
-
Chaos Delegate Name:
-
Enter a name of the Chaos Delegate which needs to be unique across the project
-
-
-
Chaos Delegate Description:
-
Fill in details about the Chaos Delegate
-
-
-
Skip SSL verification
-
Choose whether Chaos Delegate will skip SSL/TLS verification
-
-
-
Node Selector:
-
To deploy the Chaos Delegate on a particular node based on the node selector labels
-
-
-
Platform Name:
-
Enter the platform name on which this Chaos Delegate is hosted. For example, AWS, GCP, Rancher etc.
-
-
-
Enter the namespace:
-
You can either enter an existing namespace or enter a new namespace. In cases where the namespace does not exist, litmusctl creates it for you
-
-
-
Enter service account:
-
You can either enter an existing or new service account
-
-
-
-```
-Enter the details of the Chaos Delegate
-
-Chaos Delegate Name: New-Chaos-Delegate
-
-Chaos Delegate Description: This is a new Chaos Delegate
-
-Do you want Chaos Delegate to skip SSL/TLS check (Y/N) (Default: N): n
-
-Do you want NodeSelector to be added in the Chaos Delegate deployments (Y/N) (Default: N): N
-
-Platform List:
-1. AWS
-2. GKE
-3. Openshift
-4. Rancher
-5. Others
-
-Select a platform [Default: Others] [Range: 1-5]: 5
-
-Enter the namespace (new or existing namespace) [Default: litmus]:
-👍 Continuing with litmus namespace
-```
-
-Once, all these steps are implemented you will be able to see a summary of all the entered fields.
-After verification of these details, you can proceed with the connection of the Chaos Delegate by entering Y. The process of connection might take up to a few seconds.
-
-```
-Enter service account [Default: litmus]:
-
-📌 Summary
-Chaos Delegate Name: New-Chaos-Delegate
-Chaos Delegate Description: This is a new Chaos Delegate
-Chaos Delegate SSL/TLS Skip: false
-Platform Name: Others
-Namespace: litmus
-Service Account: litmus (new)
-
-Installation Mode: cluster
-
-🤷 Do you want to continue with the above details? [Y/N]: Y
-👍 Continuing Chaos Delegate connection!!
-Applying YAML:
-https://preview.litmuschaos.io/api/file/eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJjbHVzdGVyX2lkIjoiMDUyZmFlN2UtZGM0MS00YmU4LWJiYTgtMmM4ZTYyNDFkN2I0In0.i31QQDG92X5nD6P_-7TfeAAarZqLvUTFfnAghJYXPiM.yaml
-
-💡 Connecting Chaos Delegate to ChaosCenter.
-🏃 Chaos Delegate is running!!
-
-🚀 Chaos Delegate Connection Successful!! 🎉
-👉 Litmus Chaos Delegates can be accessed here: https://preview.litmuschaos.io/targets
-```
-
-#### Verify the new Chaos Delegate Connection\*\*
-
-To verify, if the connection process was successful you can view the list of connected Chaos Delegates from the Targets section on your ChaosCenter and ensure that the connected Chaos Delegate is in Active State.
-
----
-
-### Steps to create a Chaos Scenario
-
-* To setup an account with litmusctl
-```shell
-litmusctl config set-account --endpoint="" --username="" --password=""
-```
-
-* To create a Chaos Scenario by passing a manifest file
-> Note:
-> * To get `project-id`, apply `litmusctl get projects`
-> * To get `chaos-delegate-id`, apply `litmusctl get chaos-delegates --project-id=""`
-```shell
-litmusctl create chaos-scenario -f custom-chaos-scenario.yml --project-id="" --chaos-delegate-id=""
-```
-
----
-
-### Additional commands
-
-- To view the current configuration of `.litmusconfig`, type:
-
-```shell
-litmusctl config view
-```
-
-**Output:**
-
-```
-accounts:
-- users:
- - expires_in: "1626897027"
- token: eyJhbGciOiJIUzUxMiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE2MjY4OTcwMjcsInJvbGUiOiJhZG1pbiIsInVpZCI6ImVlODZkYTljLTNmODAtNGRmMy04YzQyLTExNzlhODIzOTVhOSIsInVzZXJuYW1lIjoiYWRtaW4ifQ.O_hFcIhxP4rhyUN9NEVlQmWesoWlpgHpPFL58VbJHnhvJllP5_MNPbrRMKyFvzW3hANgXK2u8437u
- username: admin
- - expires_in: "1626944602"
- token: eyJhbGciOiJIUzUxMiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE2MjY5NDQ2MDIsInJvbGUiOiJ1c2VyIiwidWlkIjoiNjFmMDY4M2YtZWY0OC00MGE1LWIzMjgtZTU2ZDA2NjM1MTE4IiwidXNlcm5hbWUiOiJyYWoifQ.pks7xjkFdJD649RjCBwQuPF1_QMoryDWixSKx4tPAqXI75ns4sc-yGhMdbEvIZ3AJSvDaqTa47XTC6c8R
- username: litmus-user
- endpoint: https://preview.litmuschaos.io
-apiVersion: v1
-current-account: https://preview.litmuschaos.io
-current-user: litmus-user
-kind: Config
-```
-
-- To get an overview of the accounts available within `.litmusconfig`, use the `config get-accounts` command:
-
-```shell
-litmusctl config get-accounts
-```
-
-**Output:**
-
-```
-CURRENT ENDPOINT USERNAME EXPIRESIN
- https://preview.litmuschaos.io admin 2021-07-22 01:20:27 +0530 IST
-* https://preview.litmuschaos.io raj 2021-07-22 14:33:22 +0530 IST
-```
-
-- To alter the current account use the `use-account` command:
-
-```shell
-litmusctl config use-account
-
-Host endpoint where litmus is installed: https://preview.litmuschaos.io
-
-Username: admin
-```
-
-- To create a project, apply the following command :
-
-```shell
-litmusctl create project
-
-Enter a project name: new
-```
-
-- To view all the projects with the user, use the `get projects` command.
-
-```shell
-litmusctl get projects
-```
-
-**Output:**
-
-```
-PROJECT ID PROJECT NAME CREATEDAT
-50addd40-8767-448c-a91a-5071543a2d8e Developer Project 2021-07-21 14:38:51 +0530 IST
-7a4a259a-1ae5-4204-ae83-89a8838eaec3 DevOps Project 2021-07-21 14:39:14 +0530 IST
-```
-
-- To get an overview of the Chaos Delegates available within a project, issue the following command.
-
-```shell
-litmusctl get chaos-delegates
-
-Enter the Project ID: 50addd40-8767-448c-a91a-5071543a2d8e
-```
-
-**Output:**
-
-```
-CHAOS DELEGATE ID CHAOS DELEGATE NAME STATUS REGISTRATION
-55ecc7f2-2754-43aa-8e12-6903e4c6183a chaos-delegate-1 ACTIVE REGISTERED
-13dsf3d1-5324-54af-4g23-5331g5v2364f chaos-delegate-2 INACTIVE NOT REGISTERED
-```
-
-
-* To disconnect an Chaos Delegate, issue the following command..
-```shell
-litmusctl disconnect chaos-delegate --project-id=""
-```
-
-**Output:**
-
-```
-🚀 Chaos Delegate successfully disconnected.
-```
-
-
-* To list the created Chaos Scenarios within a project, issue the following command.
-```shell
-litmusctl get chaos-scenarios --project-id=""
-```
-
-**Output:**
-
-```
-CHAOS SCENARIO ID CHAOS SCENARIO NAME CHAOS SCENARIO TYPE NEXT SCHEDULE CHAOS DELEGATE ID CHAOS DELEGATE NAME LAST UPDATED BY
-9433b48c-4ab7-4544-8dab-4a7237619e09 custom-chaos-scenario-1627980541 Non Cron Chaos Scenario None f9799723-29f1-454c-b830-ae8ba7ee4c30 Self-Chaos-delegate admin
-
-Showing 1 of 1 Chaos Scenarios
-```
-
-
-* To list all the Chaos Scenario runs within a project, issue the following command.
-```shell
-litmusctl get chaos-scenario-runs --project-id=""
-```
-
-**Output:**
-
-```
-CHAOS SCENARIO RUN ID STATUS RESILIENCY SCORE CHAOS SCENARIO ID CHAOS SCENARIO NAME TARGET CHAOS DELEGATE LAST RUN EXECUTED BY
-8ceb712c-1ed4-40e6-adc4-01f78d281506 Running 0.00 9433b48c-4ab7-4544-8dab-4a7237619e09 custom-chaos-scenario-1627980541 Self-Chaos-Delegate June 1 2022, 10:28:02 pm admin
-
-Showing 1 of 1 Chaos Scenario runs
-```
-
-
-* To describe a particular Chaos Scenario, issue the following command.
-```shell
-litmusctl describe chaos-scenario --project-id=""
-```
-
-**Output:**
-
-```
-apiVersion: argoproj.io/v1alpha1
-kind: Workflow
-metadata:
- creationTimestamp: null
- labels:
- cluster_id: f9799723-29f1-454c-b830-ae8ba7ee4c30
- subject: custom-chaos-scenario_litmus
- workflow_id: 9433b48c-4ab7-4544-8dab-4a7237619e09
- workflows.argoproj.io/controller-instanceid: f9799723-29f1-454c-b830-ae8ba7ee4c30
- name: custom-chaos-scenario-1627980541
- namespace: litmus
-spec:
-...
-```
-
-
-* To delete a particular Chaos Scenario, issue the following command.
-```shell
-litmusctl delete chaos-scenario --project-id=""
-```
-
-**Output:**
-
-```
-🚀 Chaos Scenario successfully deleted.
-```
-
----
-
-## Flag details
-
-
-
Flag
-
Short Flag
-
Type
-
Description
-
-
--cacert
-
-
String
-
custom ca certificate used by litmusctl for communicating with portal
-
-
-
--config
-
-
String
-
config file (default is $HOME/.litmusctl)
-
-
-
--skipSSL
-
-
Boolean
-
litmusctl will skip ssl/tls verification while communicating with portal
-
-
-
--help
-
-h
-
-
help for litmusctl
-
-
-
-For more information related to flags, Use `litmusctl --help`.
-## Learn More
-
-- [Learn More about Litmusctl](installation.md)
-- [Installing Chaos Delegates in non interactive mode](./usage-non-interactive-mode.md)
-- [Create Chaos Scenarios using Litmusctl](./chaos-workflow-creation.md)
-- [Setup Endpoints and Access ChaosCenter without Ingress](../user-guides/setup-without-ingress.md)
-- [Setup Endpoints and Access ChaosCenter with Ingress](../user-guides/setup-with-ingress.md)
diff --git a/website/docs/litmusctl/usage-non-interactive-mode.md b/website/docs/litmusctl/usage-non-interactive-mode.md
deleted file mode 100644
index 2f62112c..00000000
--- a/website/docs/litmusctl/usage-non-interactive-mode.md
+++ /dev/null
@@ -1,329 +0,0 @@
----
-id: usage-non-interactive-mode
-title: Installing Chaos Delegates in non interactive mode
-sidebar_label: Using non interactive mode
----
-
----
-
-# Usage: Litmusctl v0.12.0
-
-> Notes:
->
-> - For litmusctl v0.12.0 or latest
-> - Compatible with Litmus 2.12.0 or latest
-
-### litmusctl Syntax
-`litmusctl` has a syntax to use as follows:
-
-```shell
-litmusctl [command] [TYPE] [flags]
-```
-* Command: refers to what you do want to perform (connect, create, get and config)
-* Type: refers to the feature type you are performing a command against (chaos-delegate, project etc.)
-* Flags: It takes some additional information for resource operations. For example, `--installation-mode` allows you to specify an installation mode.
-
-Litmusctl is using the `.litmusconfig` config file to manage multiple accounts
-1. If the --config flag is set, then only the given file is loaded. The flag may only be set once and no merging takes place.
-2. Otherwise, the ${HOME}/.litmusconfig file is used, and no merging takes place.
-
-Litmusctl supports both interactive and non-interactive(flag based) modes.
-> Only `litmusctl connect chaos-delegate` command needs --non-interactive flag, other commands don't need this flag to be in non-interactive mode. If mandatory flags aren't passed, then litmusctl takes input in an interactive mode.
-
-### Installation modes
-Litmusctl can install a Chaos Delegate in two different modes.
-* cluster mode: With this mode, the Chaos Delegate can run the chaos in any namespace. It installs appropriate cluster roles and cluster role bindings to achieve this mode. It can be enabled by passing a flag `--installation-mode=cluster`
-
-* namespace mode: With this mode, the Chaos Delegate can run the chaos in its namespace. It installs appropriate roles and role bindings to achieve this mode. It can be enabled by passing a flag `--installation-mode=namespace`
-
-Note: With namespace mode, the user needs to create the namespace to install the Chaos Delegate as a prerequisite.
-
-### Minimal steps to connect a Chaos Delegate
-
-* To setup an account with litmusctl
-```shell
-litmusctl config set-account --endpoint="" --username="" --password=""
-```
-
-* To create an Chaos Delegate with an existing project
-> Note: To get `project-id`. Apply `litmusctl get projects`
-
-```shell
-litmusctl connect chaos-delegate --name="" --project-id="" --non-interactive
-```
-
-### Flags for `connect chaos-delegate` command
-
-
Flag
-
Short Flag
-
Type
-
Description
-
-
--description
-
-
String
-
Set the Chaos Delegate description (default "---")
-
-
-
--name
-
-
String
-
Set the name of Chaos Delegate which should be unique
-
-
-
--skip-ssl
-
-
Boolean
-
Set whether Chaos Delegate will skip ssl/tls check (can be used for self-signed certs, if cert is not provided in portal) (default false)
-
-
-
--chaos-delegate-type
-
-
String
-
Set the chaos-delegate-type to external for external Chaos Delegates | Supported=external/internal (default "external")
-
-
-
--installation-mode
-
-
String
-
Set the installation mode for the kind of Chaos Delegate | Supported=cluster/namespace (default "cluster")
-
-
-
--kubeconfig
-
-k
-
String
-
Set to pass kubeconfig file if it is not in the default location ($HOME/.kube/config)
-
-
-
--namespace
-
-
String
-
Set the namespace for the Chaos Delegate installation (default "litmus")
-
-
-
--node-selector
-
-
String
-
Set the node-selector for Chaos Delegate components | Format: key1=value1,key2=value2)
-
-
-
--non-interactive
-
-n
-
String
-
Set it to true for non interactive mode | Note: Always set the boolean flag as --non-interactive=Boolean
-
-
-
--ns-exists
-
-
Boolean
-
Set the --ns-exists=false if the namespace mentioned in the --namespace flag is not existed else set it to --ns-exists=true | Note: Always set the boolean flag as --ns-exists=Boolean
-
-
-
--platform-name
-
-
String
-
Set the platform name. Supported- AWS/GKE/Openshift/Rancher/Others (default "Others")
-
-
-
--sa-exists
-
-
Boolean
-
Set the --sa-exists=false if the service-account mentioned in the --service-account flag is not existed else set it to --sa-exists=true | Note: Always set the boolean flag as --sa-exists=Boolean"
-
-
-
--service-account
-
-
String
-
Set the service account to be used by the Chaos Delegate (default "litmus")
-
-
-
--config
-
-
String
-
config file (default is $HOME/.litmusctl)
-
-
-
----
-
-### Steps to create a chaos scenaro
-
-* To setup an account with litmusctl
-```shell
-litmusctl config set-account --endpoint="" --username="" --password=""
-```
-
-* To create a Chaos Scenario by passing a manifest file
-> Note:
-> * To get `project-id`, apply `litmusctl get projects`
-> * To get `chaos-delegate-id`, apply `litmusctl get chaos-delegates --project-id=""`
-```shell
-litmusctl create chaos-scenario -f custom-chaos-scenario.yml --project-id="" --chaos-delegate-id=""
-```
-
----
-
-### Additional commands
-
-* To view the current configuration of `.litmusconfig`, type:
-```shell
-litmusctl config view
-```
-
-**Output:**
-```
-accounts:
-- users:
- - expires_in: "1626897027"
- token: eyJhbGciOiJIUzUxMiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE2MjY4OTcwMjcsInJvbGUiOiJhZG1pbiIsInVpZCI6ImVlODZkYTljLTNmODAtNGRmMy04YzQyLTExNzlhODIzOTVhOSIsInVzZXJuYW1lIjoiYWRtaW4ifQ.O_hFcIhxP4rhyUN9NEVlQmWesoWlpgHpPFL58VbJHnhvJllP5_MNPbrRMKyFvzW3hANgXK2u8437u
- username: admin
- - expires_in: "1626944602"
- token: eyJhbGciOiJIUzUxMiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE2MjY5NDQ2MDIsInJvbGUiOiJ1c2VyIiwidWlkIjoiNjFmMDY4M2YtZWY0OC00MGE1LWIzMjgtZTU2ZDA2NjM1MTE4IiwidXNlcm5hbWUiOiJyYWoifQ.pks7xjkFdJD649RjCBwQuPF1_QMoryDWixSKx4tPAqXI75ns4sc-yGhMdbEvIZ3AJSvDaqTa47XTC6c8R
- username: litmus-user
- endpoint: https://preview.litmuschaos.io
-apiVersion: v1
-current-account: https://preview.litmuschaos.io
-current-user: litmus-user
-kind: Config
-```
-
-* To get an overview of the accounts available within `.litmusconfig`, use the `config get-accounts` command:
-
-```shell
-litmusctl config get-accounts
-```
-
-**Output:**
-
-```
-CURRENT ENDPOINT USERNAME EXPIRESIN
- https://preview.litmuschaos.io admin 2021-07-22 01:20:27 +0530 IST
-* https://preview.litmuschaos.io raj 2021-07-22 14:33:22 +0530 IST
-```
-
-* To alter the current account use the `use-account` command with the --endpoint and --username flags:
-```shell
-litmusctl config use-account --endpoint="" --username=""
-```
-
-* To create a project, apply the following command with the `--name` flag:
-```shell
-litmusctl create project --name=""
-```
-
-* To view all the projects with the user, use the `get projects` command.
-```shell
-litmusctl get projects
-```
-
-**Output:**
-
-```
-PROJECT ID PROJECT NAME CREATEDAT
-50addd40-8767-448c-a91a-5071543a2d8e Developer Project 2021-07-21 14:38:51 +0530 IST
-7a4a259a-1ae5-4204-ae83-89a8838eaec3 DevOps Project 2021-07-21 14:39:14 +0530 IST
-```
-
-
-* To get an overview of the Chaos Delegates available within a project, issue the following command.
-```shell
-litmusctl get chaos-delegates --project-id=""
-```
-
-**Output:**
-
-```
-CHAOS DELEGATE ID CHAOS DELEGATE NAME STATUS REGISTRATION
-55ecc7f2-2754-43aa-8e12-6903e4c6183a chaos-delegate-1 ACTIVE REGISTERED
-13dsf3d1-5324-54af-4g23-5331g5v2364f chaos-delegate-2 INACTIVE NOT REGISTERED
-```
-
-
-* To disconnect a Chaos Delegate, issue the following command..
-```shell
-litmusctl disconnect chaos-delegate --project-id=""
-```
-
-**Output:**
-
-```
-🚀 Chaos Delegate successfully disconnected.
-```
-
-
-* To list the created Chaos Scenarios within a project, issue the following command.
-```shell
-litmusctl get chaos-scenarios --project-id=""
-```
-
-**Output:**
-
-```
-CHAOS SCENARIO ID CHAOS SCENARIO NAME CHAOS SCENARIO TYPE NEXT SCHEDULE CHAOS DELEGATE ID CHAOS DELEGATE NAME LAST UPDATED BY
-9433b48c-4ab7-4544-8dab-4a7237619e09 custom-chaos-scenario-1627980541 Non Cron Chaos Scenario None f9799723-29f1-454c-b830-ae8ba7ee4c30 Self-Chaos-delegate admin
-
-Showing 1 of 1 Chaos Scenarios
-```
-
-
-* To list all the Chaos Scenario runs within a project, issue the following command.
-```shell
-litmusctl get chaos-scenario-runs --project-id=""
-```
-
-**Output:**
-
-```
-CHAOS SCENARIO RUN ID STATUS RESILIENCY SCORE CHAOS SCENARIO ID CHAOS SCENARIO NAME TARGET CHAOS DELEGATE LAST RUN EXECUTED BY
-8ceb712c-1ed4-40e6-adc4-01f78d281506 Running 0.00 9433b48c-4ab7-4544-8dab-4a7237619e09 custom-chaos-scenario-1627980541 Self-Chaos-Delegate June 1 2022, 10:28:02 pm admin
-
-Showing 1 of 1 Chaos Scenario runs
-```
-
-
-* To describe a particular Chaos Scenario, issue the following command.
-```shell
-litmusctl describe chaos-scenario --project-id=""
-```
-
-**Output:**
-
-```
-apiVersion: argoproj.io/v1alpha1
-kind: Workflow
-metadata:
- creationTimestamp: null
- labels:
- cluster_id: f9799723-29f1-454c-b830-ae8ba7ee4c30
- subject: custom-chaos-scenario_litmus
- workflow_id: 9433b48c-4ab7-4544-8dab-4a7237619e09
- workflows.argoproj.io/controller-instanceid: f9799723-29f1-454c-b830-ae8ba7ee4c30
- name: custom-chaos-scenario-1627980541
- namespace: litmus
-spec:
-...
-```
-
-
-* To delete a particular Chaos Scenario, issue the following command.
-```shell
-litmusctl delete chaos-scenario --project-id=""
-```
-
-**Output:**
-
-```
-🚀 Chaos Scenario successfully deleted.
-```
-
-
-
-For more information related to flags, Use `litmusctl --help`.
-
-## Learn More
-
-- [Learn More about Litmusctl](installation.md)
-- [Installing Chaos Delegate in interactive mode](./usage-interactive-mode.md)
-- [Create Chaos Scenarios using Litmusctl](./chaos-workflow-creation.md)
-- [Setup Endpoints and Access ChaosCenter without Ingress](../user-guides/setup-without-ingress.md)
-- [Setup Endpoints and Access ChaosCenter with Ingress](../user-guides/setup-with-ingress.md)
diff --git a/website/docs/troubleshooting.md b/website/docs/troubleshooting.md
index 7aaf4f2c..2a4c029b 100644
--- a/website/docs/troubleshooting.md
+++ b/website/docs/troubleshooting.md
@@ -6,20 +6,9 @@ sidebar_label: Troubleshooting
---
-### Subscriber is crashing with the error `dial:websocket: bad handshake`
-
-It is a network issue. It seems your subscriber is unable to access the server.
-While installing chaos delegate, It creates a config called agent-config to store some metadata like server endpoint, accesskey, etc. That server endpoint can be generated in many ways:
+## Installation
-- Ingress (If INGRESS=true in server deployment envs)
-- Loadbalancer (it generates lb type of ip based on the server svc type)
-- NodePort (it generates nodeport type of ip based on the server svc type)
-- ClusterIP (it generates clusterip type of ip based on the server svc type)
-
-So, you can edit the agent-config and update the node IP. Once edited, restart the subscriber.
-We suggest using ingress, so that if the endpoint IP changes, then it won't affect your chaos delegate.
-
-### Not able to connect to the Litmus chaos Control Plane hosted on GKE cluster.
+### 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:
@@ -27,38 +16,39 @@ In GKE you have to setup a firewall rule to allow TCP traffic on the node port.
If this firewall rule is set up, It may be accessible on nodeIp:port where nodeIp is the external IP address of your node.
-### I forgot my Litmus portal password. How can I reset my credentials?
-
-Just run the following command:
-
-`kubectl exec -it mongo-0 -n litmus -- mongo -u admin -p 1234 <<< $'use auth\ndb.usercredentials.update({username:"admin"},{$set:{password:"$2a$15$sNuQl9y/Ok92N19UORcro.3wulEyFi0FfJrnN/akOQe3uxTZAzQ0C"}})\nexit\n'`
-
-Make sure to update the namespace and mongo pod name according to your setup, the rest should remain the same. This command will update the password to `litmus`.
+### While uninstalling Chaoscenter using helm, some components like subscriber, exporter, event, chaos scenatios, etc are not removed.
-### While uninstalling Litmus portal using helm, some components like subscriber, exporter, event, chaos scenatios, 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.
-These are chaos delegate components, which are launched by the control plane server, so first disconnect the chaos delegatefrom the portal then uninstall the portal using helm.
-
-### Unable to Install Litmus portal using helm. Server pod and mongo pod are in CrashLoopBackOff state. Got this error while checking the logs of mongo container `chown: changing ownership of '/data/db/.snapshot': Read-only file system`.
+### 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.
-### We were setting up Litmus Portal, however, the Self Chaos Delegate status is showing pending. Any idea why is this happening?
+## 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:
-The litmusportal-server-service might not be reachable due to inbound rules. You can enable the traffic to it if on GKE/EKS/AKS (by adding the port to inbound rules for traffic).
-You have to check the logs of the subscriber pod and expose the port mentioned for the communication with the server.
+- 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)
-### After logging in for the first time to the portal, `/getStarted` page keep loading after I provided the new password
+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.
-First, try to clear the browser cache and cookies and refresh the page, this might solve your problem.
-If your problem persists, then delete all the cluster role bindings, PV and PVC used by litmus and try to reinstall the litmus again.
+## 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 experiments part of the tune chaos scenario page.
+You can find these in tune faults part of the tune chaos experiment page.
+
+## Chaoshub
### We have installed ChaosCenter successfully but the Litmus ChaosHub is in error state and manual cloning of a Git repository does not work.
@@ -70,7 +60,7 @@ It is most probably a network issue. Currently the ChaosHub feature is not suppo
kubectl exec -i -t -n litmus --container graphql-server -- sh
```
-Check if the Chaos Experiments directory is available. The directory structure is like
+Check if the Chaos faults directory is available. The directory structure is like
```
/tmp/version//
@@ -89,7 +79,7 @@ mkdir
- 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
+kubectl cp /:/ -c graphql-server
```
Example:
@@ -98,7 +88,9 @@ Example:
kubectl cp /home/amitkrdas/Chaos-Charts/chaos-charts/ litmus/litmusportal-server-6df9c5895d-57xx7:/tmp/version/686c1da2-da9c-4029-9c6a-528a9455a3b3/"Litmus ChaosHub" -c graphql-server
```
-- Step 4: Once the chaos experiments directory is copied, refresh the ChaosHub page in ChaosCenter.
+- Step 4: Once the chaos faults directory is copied, refresh the ChaosHub page in ChaosCenter.
+
+## Litmusctl
### Getting invalid token error while running litmusctl commands
diff --git a/website/docs/user-guides/accept-invite.md b/website/docs/user-guides/accept-invite.md
index 76b50280..6f2991db 100644
--- a/website/docs/user-guides/accept-invite.md
+++ b/website/docs/user-guides/accept-invite.md
@@ -6,10 +6,10 @@ sidebar_label: Accept invite
---
-Once the invitation is received, you can take a look at details including the sender's name, role, and project name, then decide whether to accept or decline the invitation.
+Once 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 header or the `View Project` option as shown below:
+Once accepted, you can switch to the project using the side nav as shown below:
-
+
diff --git a/website/docs/user-guides/account-settings.md b/website/docs/user-guides/account-settings.md
index 35ea6fa5..a7c1bbee 100644
--- a/website/docs/user-guides/account-settings.md
+++ b/website/docs/user-guides/account-settings.md
@@ -6,31 +6,47 @@ sidebar_label: Account Settings
---
-Under the `My Account` tab, you can change your personal details such as the email, full name, and password.
+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:
+
+
+
+
+
## Edit Personal Details
-Enter your name and your email address in the following text fields and click on the `Save Changes` button.
+Click the edit icon to open the edit modal:
-
+
+
+
-Once done successfully, you’ll be getting a modal indicating a successful completion of the operation.
+Enter your name and your email address in the following text fields and click on the `Confirm` button to save the new details.
-
+
+
+
## Change Password
-On the same page, you can change your password by providing your current as well as your new password and then click on the `Change Password` button.
+On the same page, you can change your password by clicking on the `Change Password` button.
-
+
+
+
-> Note: If you have forgotten your password, please contact your admin to reset your password
+To update your password enter your current password as well as the new password you wish to set and click **Confirm**
-On successful completion, you’ll be getting a modal indicating that the password has been changed.
+
+
+
+
+> 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
diff --git a/website/docs/user-guides/change-project-name.md b/website/docs/user-guides/change-project-name.md
index 380727e7..4e117af6 100644
--- a/website/docs/user-guides/change-project-name.md
+++ b/website/docs/user-guides/change-project-name.md
@@ -14,23 +14,23 @@ The concept of `Projects` is discussed [here](../concepts/projects.md) and will
## Steps
-### 1. Go to `My Project`
+### 1. Go to `Account setting`
-Go to the `Team` section of settings and scroll to the `My project` section:
+Go to the `Overview` section of settings and scroll to the `Your Projects` section:
### 2. Enter edit mode
-Click on either the text (demonstrated in this example as `admin’s project`) or on the edit icon next to it to enter the edit mode:
+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 away anywhere in the screen. You will notice that the name of the project has been changed in the `My Project` section as well as the header of the portal.
+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
diff --git a/website/docs/user-guides/chaosagents-installation.md b/website/docs/user-guides/chaos-infrastructure-installation.md
similarity index 68%
rename from website/docs/user-guides/chaosagents-installation.md
rename to website/docs/user-guides/chaos-infrastructure-installation.md
index 3aeb0bab..b2f28d6b 100644
--- a/website/docs/user-guides/chaosagents-installation.md
+++ b/website/docs/user-guides/chaos-infrastructure-installation.md
@@ -1,22 +1,21 @@
---
-id: chaosagents-installation
-title: Chaos Delegate Installation
-sidebar_label: Chaos Delegate
+id: chaos-infrastructure-installation
+title: chaos-infrastructure-installation
+sidebar_label: chaos-infrastructure-installation
---
---
## Prerequisites
-- Before connecting a Chaos Delegate to the [ChaosCenter](../getting-started/resources.md#chaoscenter), learn about what is a [Chaos Delegate](../getting-started/resources.md#chaosagents) in Litmus.
+- 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 Delegate
+## Connecting Chaos Infrastructure
-- Learn to [connect Chaos Delegate with non interactive mode using litmuctl](../litmusctl/usage-non-interactive-mode.md)
-- Learn to [connect Chaos Delegate with interactive mode using litmuctl](../litmusctl/usage-interactive-mode.md)
+- Learn to [connect Chaos Infrastructure with non interactive mode using litmuctl](../litmusctl/litmusctl-usage.md)
-## Resource Requiremenets for Chaos Delegate plane components
+## Resource Requiremenets for Chaos Infrastructure plane components
The Resource requests provided here have been estimated using data gathered manually through different methods -
diff --git a/website/docs/user-guides/chaoscenter-oauth-dex-installation.md b/website/docs/user-guides/chaoscenter-oauth-dex-installation.md
index f8b557d9..6fa3a895 100644
--- a/website/docs/user-guides/chaoscenter-oauth-dex-installation.md
+++ b/website/docs/user-guides/chaoscenter-oauth-dex-installation.md
@@ -162,6 +162,6 @@ Go to http://litmusportal-frontend-service/auth/dex/login, you should be prompte
## Learn more
- [Install ChaosCenter in Namespace Scope](../user-guides/chaoscenter-namespace-scope-installation.md)
-- [Connect External Chaos Delegates to ChaosCenter](../user-guides/chaosagents-installation.md)
+- [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/docs/user-guides/construct-workflow.md b/website/docs/user-guides/construct-experiment.md
similarity index 98%
rename from website/docs/user-guides/construct-workflow.md
rename to website/docs/user-guides/construct-experiment.md
index b6244075..e6a14802 100644
--- a/website/docs/user-guides/construct-workflow.md
+++ b/website/docs/user-guides/construct-experiment.md
@@ -1,5 +1,5 @@
---
-id: construct-workflow
+id: construct-experiment
title: Construct Chaos Scenario YAML without ChaosCenter
sidebar_label: Construct Chaos Scenario YAML
---
@@ -15,7 +15,7 @@ A basic chaos scenario consists of these steps:
## Before we begin
-To construct a Chaos Scenario without ChaosCenter, make sure you are aware of [Chaos Scenario](../concepts/chaos-workflow.md), [ChaosEngine CR](../concepts/chaos-engine.md) and the different steps present in it.
+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
@@ -272,4 +272,3 @@ spec:
## Learn More
- [What are the different Probes](../concepts/probes.md)
-- [What is ChaosResult](../concepts/chaos-result.md)
diff --git a/website/docs/user-guides/create-resilience-probe.md b/website/docs/user-guides/create-resilience-probe.md
new file mode 100644
index 00000000..f0015c85
--- /dev/null
+++ b/website/docs/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:
+
+
\ No newline at end of file
diff --git a/website/docs/user-guides/create-user.md b/website/docs/user-guides/create-user.md
index 6613560b..3f8aa73d 100644
--- a/website/docs/user-guides/create-user.md
+++ b/website/docs/user-guides/create-user.md
@@ -8,25 +8,25 @@ sidebar_label: Create User
This feature enables the admin to create a new user by assigning a unique username and password for the user. In addition to this, the admin can also provide the name and email address of the new user which is optional.
-## 1. Create a new user
+## 1. Navigate to User Management
-Click the `Create new user` button as observed below:
+Go to the `User Management` tab of the account settings page:
-
+
-## 2. Add the details of the new user
+## 2. Create a new user
-Add all the details of the user to be created and hit the `Create` button.
+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
-The user is created and you will receive a confirmation modal.
+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.
+You will now be able to view the new user in the table in the `User Management` tab.
## Learn more
diff --git a/website/docs/user-guides/deactivate-user.md b/website/docs/user-guides/deactivate-user.md
index 78baf214..ecec52b9 100644
--- a/website/docs/user-guides/deactivate-user.md
+++ b/website/docs/user-guides/deactivate-user.md
@@ -12,19 +12,19 @@ The Account of a created user can be deactivated if required. Once the user is d
In the user management tab, locate the user account that you'd like to deactivate and click on the horizontal options icon.
-
+
-## 2. Confirm the user is deactivated
+## 2. Confirm the deactivation
-Once deactivated, the indicator next to the user's username in the usermanagement table will turn gray.
+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
diff --git a/website/docs/user-guides/delete-experiment.md b/website/docs/user-guides/delete-experiment.md
new file mode 100644
index 00000000..fce711f2
--- /dev/null
+++ b/website/docs/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/docs/user-guides/delete-resilience-probe.md b/website/docs/user-guides/delete-resilience-probe.md
new file mode 100644
index 00000000..65b2d602
--- /dev/null
+++ b/website/docs/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.
+
+
\ No newline at end of file
diff --git a/website/docs/user-guides/delete-workflow.md b/website/docs/user-guides/delete-workflow.md
deleted file mode 100644
index 66cb2d59..00000000
--- a/website/docs/user-guides/delete-workflow.md
+++ /dev/null
@@ -1,43 +0,0 @@
----
-id: delete-workflow
-title: Delete a Chaos Scenario
-sidebar_label: Delete Chaos Scenario
----
-
----
-
-If required, it is possible to delete a chaos scenario schedule that you no longer wish to run against your application.
-
-:::note
-This also means that all the runs corresponding to that chaos scenario will also be deleted.
-:::
-
-## Before you begin
-
-You can learn about the concept of chaos scenarios [here](../concepts/chaos-workflow.md) and how to schedule your first chaos scenario [here](schedule-workflow.md).
-
-## 1. Go to the chaos scenarios sections
-
-In the `Chaos Scenario` page, go to the `Schedules` tab and click on the options menu for the specific schedule you wish to delete:
-
-
-
-## 2. Click on the `Delete chaos scenario` option
-
-After opening the options menu and clicking on the `Delete chaos scenario` option, you'll see a prompt in order to confirm your action. Please ensure that you want to delete the selected chaos scenario and click the `Delete` button:
-
-
-
-## 3. The Chaos Scenario has been deleted
-
-You will observe that the chaos scenario no longer appears in the list of schedules and has been removed.
-
-
-
-As stated above, we observe that the runs have been removed as well.
-
-
-
-## Learn more
-
-- [schedule a chaos scenario](schedule-workflow.md)
diff --git a/website/docs/user-guides/download-workflow-manifest.md b/website/docs/user-guides/download-experiment-manifest.md
similarity index 84%
rename from website/docs/user-guides/download-workflow-manifest.md
rename to website/docs/user-guides/download-experiment-manifest.md
index ce53bd28..a2229dd0 100644
--- a/website/docs/user-guides/download-workflow-manifest.md
+++ b/website/docs/user-guides/download-experiment-manifest.md
@@ -1,5 +1,5 @@
---
-id: download-workflow-manifest
+id: download-experiment-manifest
title: Download Chaos Scenario Manifest
sidebar_label: Download Chaos Scenario Manifest
---
@@ -10,7 +10,7 @@ You can save a schedule configurations manifest as a `YAML`. This section goes o
## Before you begin
-You can learn how to schedule your first chaos scenario [here](schedule-workflow.md).
+You can learn how to schedule your first chaos scenario [here](schedule-experiment.md).
## 1. Go to the chaos scenarios sections
@@ -26,6 +26,6 @@ After opening the options menu, click on the `Download Manifest` option. Having
## Learn more
-- [Schedule a chaos scenario](schedule-workflow.md)
-- [Re-run a chaos scenario](re-run-workflow.md)
-- [Delete a chaos scenario](delete-workflow.md)
+- [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/docs/user-guides/edit-invite.md b/website/docs/user-guides/edit-invite.md
index 3fe415a4..3328bbcb 100644
--- a/website/docs/user-guides/edit-invite.md
+++ b/website/docs/user-guides/edit-invite.md
@@ -8,9 +8,9 @@ sidebar_label: Edit/Cancel invite
If you had a change of mind and you wanted to change the role of an invitation that has been already sent, we got you!
-Just go to the invited tab, change the role, and hit the `Resend` button. You can also cancel the invitation by just clicking on the `bin` icon.
+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
diff --git a/website/docs/user-guides/edit-resilience-probe.md b/website/docs/user-guides/edit-resilience-probe.md
new file mode 100644
index 00000000..e5f7abac
--- /dev/null
+++ b/website/docs/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.
+
+
\ No newline at end of file
diff --git a/website/docs/user-guides/edit-schedule.md b/website/docs/user-guides/edit-schedule.md
index b3c066e1..d30b8a32 100644
--- a/website/docs/user-guides/edit-schedule.md
+++ b/website/docs/user-guides/edit-schedule.md
@@ -1,22 +1,22 @@
---
id: edit-schedule
-title: Edit Chaos Scenario Schedule
-sidebar_label: Edit Chaos Scenario Schedule
+title: Edit Chaos Experiment Schedule
+sidebar_label: Edit Chaos Experiment Schedule
---
---
## Before you begin
-You must schedule a chaos scenario. To know more about scheduling chaos scenarios click [here](schedule-workflow.md)
+You must schedule a chaos experiment. To know more about scheduling chaos experiments click [here](schedule-experiment.md)
---
-After you have scheduled a chaos scenario, you might have a need of changing the schedule of a recurring chaos scenario. To edit the schedule follow these steps:
+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 `Schedules` tab of `Litmus Chaos Scenarios` page you can click on the triple dots of the schedule to access more options for it. From the menu select the `Edit Schedule` option.
+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.
@@ -25,16 +25,16 @@ In the `Schedules` tab of `Litmus Chaos Scenarios` page you can click on the tri
## 2. Click on edit button
-Now you'll be seeing the Summary of your chaos scenario and you can click on the `Edit` button to change the schedule.
+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 Scenario 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 `Verify` button.
+Here you can change the schedule to the required interval and click on the `Set schedule` button.
@@ -43,10 +43,10 @@ Here you can change the schedule to the required interval and click on the `Veri
## 4. Save the changes
-Click on the `Save Changes` button to commit the changes to your chaos scenario.
+Click the `Save` button to save the changes to the experiment chaos experiment.
## Learn more
-- [Observe Chaos Scenario](observe-workflow.md)
-- [Save Chaos Scenarios as a Template](save-as-template.md)
-- [Re-run a Chaos Scenario](re-run-workflow.md)
+- [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/docs/user-guides/gitops-configuration.md b/website/docs/user-guides/gitops-configuration.md
index 9a33bd53..794bae19 100644
--- a/website/docs/user-guides/gitops-configuration.md
+++ b/website/docs/user-guides/gitops-configuration.md
@@ -4,47 +4,54 @@ 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 scenarios and experiments, any changes made either to the artifacts stored in the configured git repository or the portal will be synced.
+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 Delegate
-- [Chaos Scenario](../concepts/chaos-workflow.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 scenarios in that repository.
+- 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` tab under `Settings`.
+- 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 `Git URL` text box.
-- Enter the branch where you want to sync your chaos scenarios.
+- 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, just copy the key and paste it in the`Deploy Keys` Tab inside `Settings` in your git - repository. Click on the allow write access checkbox, and then on the `Add key` button.
-- Go back to the portal and click on the update button. A modal will pop up showing, `Successfully updated GitOps!` message.
+- 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 scenario, it will automatically be pushed to your repository. And that repository will be the single source of truth.
+- 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 scenarios that are created and pushed to the git repository directly, after configuring GitOps. In this case, if the chaos scenario is a single run chaos scenario, then it starts executing as soon as it is pushed to the repository. Alternatively, if the chaos scenario is a scheduled chaos scenario, then it executes as per the defined schedule. On the other hand, updating an existing chaos scenario present in the git repository will not execute the chaos scenario but only sync the chaos scenario resource definition with the ChaosCenter, if applicable.
+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 scenario is pushed to your repository, you’ll notice every chaos scenario has a `workflow_id`. You can get this from the chaos scenario YAML file. You need to copy the id and annotate the target application so that if there’s any change in the application, gitops will sync the chaos scenario using this workflow_id and run it on your target application. You can use the following command:
+- 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/workflow=${workflow_id}
+kubectl annotate deploy/target-application litmuschaos.io/workflow=${experiment_id}
```
```
@@ -64,9 +71,9 @@ kubectl logs -f event-tracker-pod-name -n litmus
```
In the logs, you’ll notice that the event-tracker has started.
-If you make changes in the application the event tracker will trigger the chaos injection. If the policy conditions are met then the event tracker will inform the server to schedule a chaos scenario in that same target. For eg: if you have an Nginx app as your target application, you can just edit the deployment and change its image tag, this will trigger the chaos injection.
+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 scenario will be triggered if both conditions are met due to the `AND` condition type.
+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
@@ -96,13 +103,7 @@ Currently supported policy operators are:
- GreaterThanEqualTo
- LessThanEqualTo
-## Resources
-
-
-
-
-
## Learn More
-- [Schedule a chaos scenario](../user-guides/schedule-workflow.md)
-- [Observe a Chaos Scenario](../user-guides/observe-workflow.md)
+- [Schedule a chaos experiment](../user-guides/schedule-experiment.md)
+- [Observe a Chaos experiment](../user-guides/observe-experiment.md)
diff --git a/website/docs/user-guides/image-registry.md b/website/docs/user-guides/image-registry.md
index e626dec4..32bdaaa7 100644
--- a/website/docs/user-guides/image-registry.md
+++ b/website/docs/user-guides/image-registry.md
@@ -1,6 +1,6 @@
---
id: image-registry
-title: Using different Image Registries in a Chaos Scenario
+title: Using different Image Registries in a Chaos Experiments
sidebar_label: Using different Image Registries
---
@@ -8,38 +8,38 @@ sidebar_label: Using different Image Registries
A container image registry can be defined as a collection of repositories that store container image.
These can be either public or private. Few of the container image registries are Docker, Red Hat Quay, Google Container Registry.
-By default LitmusChaos uses DockerHub for managing the different images. These images are then used in Chaos Scenarios. Few images that are used in the Litmus chaos scenarios are `litmuschaos:k8s`, `litmuschaos:litmus-checker` etc.
-With ChaosCenter, you get the privilege to use your own/custom image registries for Chaos Scenarios.
+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 Scenario](../concepts/chaos-workflow.md) and the different image registries that are used in it.
+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 Scenario Image Registry
+## Steps to Update Chaos experiment Image Registry
-To updated the Chaos Scenario Image Registry, you can go to Settings in ChaosCenter. In settings, there will be tab named Image Registry. On clicking the Image Registry tab, you can see that the default Registry server is `docker.io`, Registry name is `litmuschaos` and it is a Public registry.
+To 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. Registry Server
-2. Registry Name
+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 and the namespace where the secret is present.
+If the Registry Type is `Private`, make sure to provide the secret.
-Once the details are provided, click on the `Save Changes` button and you can see the updated Image Registry changes.
+Once the details are provided, click on the `Save` button and you can see the updated Image Registry changes.
-
+
-Now while scheduling a chaos scenario, the image registry changes will be visible. Here's the code snippet from a Chaos Scenario after the image registry change.
+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
@@ -59,5 +59,5 @@ Now while scheduling a chaos scenario, the image registry changes will be visibl
## Learn More
-- [What is a Chaos Scenario](../concepts/chaos-workflow.md)
+- [What is a Chaos experiment](../concepts/chaos-workflow.md)
- [What is ChaosCenter](../getting-started/resources.md#chaoscenter)
diff --git a/website/docs/user-guides/invite-team-member.md b/website/docs/user-guides/invite-team-member.md
index de5f8a62..03f4f018 100644
--- a/website/docs/user-guides/invite-team-member.md
+++ b/website/docs/user-guides/invite-team-member.md
@@ -6,27 +6,23 @@ sidebar_label: Invite Team Member
---
-> In the `/settings` route (settings on the sidebar) the `Team` tab can be used to access the teaming feature by the `owner`. We recommend learning about the concept of [teaming](../concepts/teaming.md) before proceeding with the following user guides.
+> 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 `Invited` tab.
+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 `Invite new member` button as shown below:
+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/Editor) and hit the `Send Invite` button.
+From the list of all available members, choose the ones you want to collaborate on your chaos with and decide what project level access they should have to your project (Viewer/Editor) and hit the same button.
-
+
-## 3. Collaborate over the chaos!
-
-On successful invitation you will receive the confirmation dialog as shown below indicating selected members have been invited to your project.
-
-
+On successful acceptance of the invitation you will be able to collaborate over your project!
## Learn more
diff --git a/website/docs/user-guides/leave-project.md b/website/docs/user-guides/leave-project.md
index e84d23ba..293417fb 100644
--- a/website/docs/user-guides/leave-project.md
+++ b/website/docs/user-guides/leave-project.md
@@ -10,13 +10,15 @@ You can leave a project that you no longer wish to be a part of.
## 1. Identify the project you want to leave
-In the settings page, scroll to the very bottom of the `Team` tab. Here you will see a list of all the projects you are a part of, identify the project you’d like to leave and click on the `Leave Project` button:
+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
diff --git a/website/docs/user-guides/observe-experiment.md b/website/docs/user-guides/observe-experiment.md
new file mode 100644
index 00000000..9de1408e
--- /dev/null
+++ b/website/docs/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/docs/user-guides/observe-workflow.md b/website/docs/user-guides/observe-workflow.md
deleted file mode 100644
index a86fe9ce..00000000
--- a/website/docs/user-guides/observe-workflow.md
+++ /dev/null
@@ -1,112 +0,0 @@
----
-id: observe-workflow
-title: Observe Chaos Scenario
-sidebar_label: Observe Chaos Scenario
----
-
----
-
-## Before you begin
-
-You must schedule a chaos scenario. To know more about scheduling chaos scenarios click [here](schedule-workflow.md)
-
----
-
-After scheduling a chaos scenario, you can track the status of the chaos scenario run from the `Runs` tab in the `Litmus Chaos Scenario`. The status that is currently displayed are:
-
-- Failed
-- Running
-- Completed
-
-
-
-Chaos Scenario Runs Table showing a Running Chaos Scenario
-
-
----
-
-you can analyze a chaos scenario using two methods:
-
-## Visualize the chaos scenario run graph
-
-After scheduling a chaos scenario, you can click on the **Show the chaos scenario** option or click on the chaos scenario name to see the real-time graph of the chaos scenario.
-
-
-
-Graph of Podtato Head chaos scenario
-
-
-The graph consists of useful information such as :
-
-- Phase of individual nodes.
-- Total time taken for the nodes to execute.
-- Structure of the experiments (Serial or Parallel experiments).
-
-You can also visualize the non Chaos scenarios. The logs of individual nodes are also available here.
-
-
-
-Graph of a non Chaos Scenario
-
-
-## View logs of individual nodes
-
-you can click on the nodes to get the logs of that particular step. If the revert-chaos step is disabled, the complete logs are available which include the runner pod logs and the chaos logs.
-
-
-
-Podtato Head chaos scenario with Logs
-
-
-## View chaos results
-
-Once the experiment completes, the [Chaos Results](../concepts/chaos-result.md) are also available alongside the logs. The Chaos Results are directly fetched from the ChaosResult CRD.
-
-
-
-Podtato Head chaos scenario with chaos logs and chaos result of generic/pod-delete experiment
-
-
-## Resilience Score Calculation
-
-A Resilience Score is the measure of how resilient your chaos scenario run is considering all the chaos experiments and their individual result points. This calculation takes into account the individual experiment weights (from a range of 1-10) which are relative to each other.
-
-Once a weight has been assigned to the experiment, we look for the [Probe Success Percentage](../concepts/probes#probe-status--deriving-inferences) for that experiment itself (Post Chaos) and calculate the total resilience result for that experiment as a multiplication of the weight given and the probe success percentage returned after the Chaos Run.
-
-```doc
-Total Resilience for one single experiment = (Weight Given to that experiment * Probe Success Percentage)
-```
-
-> If an experiment doesn't have a probe in it, the probe success percentage returned can either be 0 or 100 based on the experiment verdict. If the experiment passed then it returns 100 else 0.
-
-The Final Resilience Score is calculated by dividing the total test result by the sum of all the weights of all the experiments combined in a single chaos scenario.
-
-For example, if we consider two experiments in a chaos scenario, here is what the calculation would look like.
-
-> Considering Probe Success Percentage is 100
-
-| Experiment | Weight | Probe Success Percentage | Total Test Result |
-| :--------- | :---------------------: | -----------------------: | -----------------------------------: |
-| exp1 | 3 | 100 | (3 \* 100) = 300 |
-| exp2 | 9 | 100 | (9 \* 100) = 900 |
-| | Weight Sum = 3 + 9 = 12 | | Total Test Result = 300 + 900 = 1200 |
-
-```
-Resilience Score = Total Test Result / Weight Sum
- = 1200 / 12
- = 100%
-```
-
-## Analytics from the runs tab
-
-Once the chaos scenario run execution completes, you can click the **Show the analytics** option in the `Runs` tab of `Litmus Chaos Scenarios` which opens up a [Chaos Scenario Dashboard](../user-guides/analyze-workflow.md) which can also be accessed from the Analytics section and is explained more [here](../user-guides/analyze-workflow.md). This analytics can be crucial to analyse the Cron Chaos Scenarios.
-
-## Resources
-
-
-
-## Learn more
-
-- [Edit Schedule](edit-schedule.md)
-- [Download Chaos Scenario Manifest](download-workflow-manifest.md)
-- [Re-run a Chaos Scenario](re-run-workflow.md)
diff --git a/website/docs/user-guides/overview.md b/website/docs/user-guides/overview.md
index c2626ffc..6eb1e37a 100644
--- a/website/docs/user-guides/overview.md
+++ b/website/docs/user-guides/overview.md
@@ -6,23 +6,19 @@ sidebar_label: Overview
---
-The User Guides section details Processes, User-flows and How-tos detailing all sorts of scenarios in various environments. Technical details and inner workings of the various components are explained in the [Concepts](../concepts/overview.md) section.
+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-cluster-scope-installation.md)
-Install ChaosCenter and Chaos Delegate in various environment configurations.
+Install ChaosCenter and Chaos Infrastructure in various environment configurations.
-### [Injecting Fault](schedule-workflow.md)
+### [Injecting Fault](schedule-experiment.md)
-Constructing, Scheduling, Editing and Observing chaos scenarios.
-
-### [Observing Chaos](observability-set-up.md)
-
-Set-up monitoring, Analyze and Compare various metrics that help you make reliable decisions regarding your application.
+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 scenarios with any changes in the resource spec.
+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)
@@ -40,10 +36,10 @@ Probes are pluggable checks that can be defined within the ChaosEngine for any C
Adding members to a project, Editing user-invite and Removing team members from a project.
-### [Using different Image Registries in a Chaos Scenario](image-registry.md)
+### [Using different Image Registries in a Chaos Experiment](image-registry.md)
-Using different Image Registries like Docker, Red Hat Quay, Google Container Registry in a Chaos Scenario.
+Using different Image Registries like Docker, Red Hat Quay, Google Container Registry in a Chaos Experiment.
### [Uninstalling Litmus](uninstall-litmus.md)
-Disconnecting Chaos Delegate and uninstalling ChaosCenter.
+Disconnecting Chaos Infrastructure and uninstalling ChaosCenter.
diff --git a/website/docs/user-guides/re-run-experiment.md b/website/docs/user-guides/re-run-experiment.md
new file mode 100644
index 00000000..93caf784
--- /dev/null
+++ b/website/docs/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/docs/user-guides/re-run-workflow.md b/website/docs/user-guides/re-run-workflow.md
deleted file mode 100644
index 327007d4..00000000
--- a/website/docs/user-guides/re-run-workflow.md
+++ /dev/null
@@ -1,30 +0,0 @@
----
-id: re-run-workflow
-title: Re-run a chaos scenario
-sidebar_label: Re-run chaos scenario
----
-
----
-
-You can re-run any **_non-recurring_** schedule should you wish to test your application against it at any point.
-
-## Before you begin
-
-You can learn how to schedule your first chaos scenario [here](schedule-workflow.md).
-
-## 1. Go to the chaos scenarios sections
-
-In the `Chaos Scenario` page, go to the `Schedules` tab and click on the options menu for the specific schedule you wish to re-run:
-
-
-
-## 2. Click on the `Rerun Schedule` option
-
-After opening the options menu, click on the `Rerun Schedule` option. Having re-run a particular schedule, you can switch to the `Runs` tab and see that it has started to re-run as per the schedule configurations:
-
-
-
-## Learn more
-
-- [Schedule a chaos scenario](schedule-workflow.md)
-- [Delete a chaos scenario](delete-workflow.md)
diff --git a/website/docs/user-guides/remove-team-member.md b/website/docs/user-guides/remove-team-member.md
index 1f02bf47..5fa2af38 100644
--- a/website/docs/user-guides/remove-team-member.md
+++ b/website/docs/user-guides/remove-team-member.md
@@ -12,12 +12,12 @@ If you are the project owner, you have the ability to remove any members from yo
### 1. Identify the member to remove
-In the `Team` tab in the settings page, scroll down to the `My project` table, here you will be able to see all the members who have their invitation status as `accepted` for your project collaboration invite. Here, identify the user to remove and click on the red `Remove` bin icon as shown.
+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` icon, you will be prompted to confirm the removal of the member, hit `Yes` to confirm and remove the member from your project.
+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/docs/user-guides/reset-password.md b/website/docs/user-guides/reset-password.md
index 5bb19cd8..45781ebb 100644
--- a/website/docs/user-guides/reset-password.md
+++ b/website/docs/user-guides/reset-password.md
@@ -10,15 +10,15 @@ The admin has the ability to reset the login password for any user in the portal
## 1. Locate the user
-Under the `User management` tab find the user who's password needs to be updated and click on the options icon to open a drop-down and select `Edit Profile` option
+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 `Login Details` section select the `New password` input field and type in the new password. Once done hit the `Save` button to update the password.
+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
diff --git a/website/docs/user-guides/save-as-template.md b/website/docs/user-guides/save-as-template.md
index c0218346..4d0237ea 100644
--- a/website/docs/user-guides/save-as-template.md
+++ b/website/docs/user-guides/save-as-template.md
@@ -10,7 +10,7 @@ You can save a schedule as a template for later usage in subsequent schedules. T
## Before you begin
-You can learn how to schedule your first chaos scenario [here](schedule-workflow.md).
+You can learn how to schedule your first chaos scenario [here](schedule-experiment.md).
## 1. Go to the chaos scenarios sections
@@ -38,6 +38,6 @@ You can now see your template under the `Create a new chaos scenario by cloning
## Learn more
-- [Schedule a chaos scenario](schedule-workflow.md)
-- [Re-run a chaos scenario](re-run-workflow.md)
-- [Delete a chaos scenario](delete-workflow.md)
+- [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/docs/user-guides/schedule-experiment.md b/website/docs/user-guides/schedule-experiment.md
new file mode 100644
index 00000000..dd3444b2
--- /dev/null
+++ b/website/docs/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.
+
+
+
+
+
+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.
+
+
+
+
+
+## 2. Choose target chaos infrastructure
+
+In **Select a Chaos Infrastructure**, select the infrastructure where the target resources reside, and then click **Apply**.
+
+
+
+
+
+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
+
+
+
+
+
+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.
+
+
+
+
+
+a. Select **Add**, then select each fault you want to add to the experiment individually.
+
+
+
+
+
+For each fault you select, you'll tune the fault's properties next.
+
+
+
+
+
+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.
+
+
+
+
+
+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.
+
+
+
+
+
+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.
+
+
+
+
+
+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:
+
+
+
+
+
+## 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.
+
+
+
+
+
+### 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.
+
+
+
+
+
+## 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/docs/user-guides/schedule-workflow.md b/website/docs/user-guides/schedule-workflow.md
deleted file mode 100644
index 058965e8..00000000
--- a/website/docs/user-guides/schedule-workflow.md
+++ /dev/null
@@ -1,155 +0,0 @@
----
-id: schedule-workflow
-title: Schedule a Chaos Scenario
-sidebar_label: Schedule Chaos Scenario
----
-
----
-
-## Before you begin
-
-You must connect an Chaos Delegate before scheduling a chaos scenario . There might be a default `Self Chaos Delegate` automatically created or you can [connect an external Chaos Delegate ](../litmusctl/installation.md).
-
----
-
-Click on the **Schedule a chaos scenario ** button on the home page or **Schedule chaos scenario ** button in Litmus Chaos Scenarios page to get started.
-
-
-
-Home Page
-
-
-It will take you to the **Schedule a new Litmus chaos scenario ** page where you can choose or design your own chaos scenario by doing the following steps:
-
-## 1. Choose targetchaos delegate
-
-This is the first step in chaos scenario creation. In this step, you can select a target chaos delegate where the chaos scenario will be scheduled. These chaos delegate consist of the CRDs and the required resources to run a chaos scenario .
-While installing the Litmus Portal, a default chaos delegate named **Self Chaos Delegate ** is created.
-
-
-
-Selecting a Chaos Delegate
-
-
-After Selecting the chaos delegate , you can continue by clicking on **Next** button.
-
-> Note: You may have to wait for the chaos delegate to be up and ready, after which you can move forward by again clicking on “Next” . Newly created users by the admin won't have any chaos delegate connected and thus won't be able to schedule a chaos scenario . As non-admin users, you will get a message ‘No Cluster Registered With Your Project ID, Please Wait…’ if you try to create a chaos scenario .
-
-## 2. Choose a chaos scenario
-
-
-
-Choosing a Chaos Scenario
-
-
-In this step, you can create a chaos scenario from different methods, these include:
-
-- **Create a new chaos scenario from one of the pre-defined chaos scenario s** : With this option, you can select a pre-defined chaos scenarios which are available in the connected ChaosHub.
-
-- **Create a new chaos scenario by using cloned template chaos scenario ** : With this option, you can create a new chaos scenario from an existing one [saved as a template](save-as-template.md). Choose on of the saved templates and tweak it according to your requirements.
-
-- **Create a new chaos scenario using experiments from MyHub** : With this option, you can create customized chaos scenarios from the one of your connected ChaosHubs. With this option you can add multiple experiments from that ChaosHub either serially or in parallel to construct your chaos scenario graphically.
-
-- **Import chaos scenario using YAML** : With this option, you can import a [hand-crafted/constructed chaos scenario ](construct-workflow.md) manifest and tune it according to the use-case. You can also import a basic Argo chaos scenario using this functionality.
- :::note
- For an uploaded chaos scenario , the tune chaos scenario functionality will not be available. The uploaded chaos scenario is completely user-dependent or user-specific.
-
-## 3. Chaos Scenario Settings
-
-In this section, you can change the name of the chaos scenario and also provide a description to the chaos scenario . This section also consists information regarding the namespace where the chaos scenario will be scheduled.
-
-
-
-Change name and description
-
-
-## 4. Tune the chaos scenario
-
-This section consists of all the information related to the chaos scenario .
-Some new and advanced features that are present in this section are :
-
-1. **Chaos Scenario Visualization** : This feature allows you to visualize the chaos scenario even before scheduling it.
- This gives a brief information related to the structure of chaos scenario i.e if the experiments are present in serial or parallel way.
-2. **Chaos Scenario Table** : This table contains the list of experiments present in the chaos scenario . It also consists of some valuable information related to the target applications.
-3. **Add Experiment** : If you have selected `Create a new chaos scenario using experiments from MyHub` in Choose a Chaos Scenario step, you can see a `Add a new experiment` button, this will allow you to add more experiments to the chaos scenario .
-4. **Edit Chaos Scenario ** : With this option, you can view and make changes in the chaos scenario manifest with a YAML editor.
-5. **Revert Chaos** : For custom chaos scenarios, you can now enable or disable the revert step from the portal.
- With revert step enabled, a new functionality called `podGC` is also added which deletes the chaos scenario pods after the completion of chaos scenario as part of the clean-up process.
-
-
-
-Tuning a Predefined Chaos Scenario (Podtato Head)
-
-
-
-
-Editing Experiment Sequence
-
-
-
-
-Adding Experiments to Chaos Scenario (Available after choosing a Hub in previous step)
-
-
-Some of the other features that are included with Litmus Portal 2.0 are :
-
-1. **Target Selection** : On the chaos scenario table, you can select an experiment to edit the engine configuration directly from the portal. You can change the `annotationCheck` and `jobCleanUpPolicy` according to the use-case.
- You can also target the application by selecting the namespace and the respective label of that application. We have added a functionality to fetch the live data from the selected chaos delegate like the available namespaces and resources that you can target.
-
-2. **Defining the steady state for the application** : With this step, you can add probes to your experiments. Probes are some additional checks that you can provide in your experiments. To know more about probes, you can visit [here](../concepts/probes.md).
-
-
-
-
-Target Selection
-
-
-## 5. Assign weights to experiments
-
-In this step, you can assign weights to the experiments present in the chaos scenario . These weights will be then used for the calculation of the resilience score after the chaos scenario completion. By default, 10 points are assigned to each experiment. This can be altered as per your use-case.
-
-
-
-Adjust Experiment Weights
-
-
-#### **The Importance of Weights in experiments**
-
-Giving a weightage to your experiment is a way of signifying/attaching the importance/priority of that experiment in your chaos scenario . The higher the weight, the more importance it holds.
-
-The weight priority is generally divided into three sections:
-
-- **0-3:** Low Priority
-- **4-6:** Medium Priority
-- **7-10:** High Priority
-
-## 6. Schedule
-
-In this step, you can schedule the chaos scenario in 2 ways:
-
-1. **Schedule now** : With this option, the chaos scenario will start as soon as you schedule it.
-2. **Recurring Schedule** : This option will allow you to schedule the chaos scenario in recurring ways. It converts a normal chaos scenario to `Cron` chaos scenario and a cron syntax is added in the chaos scenario manifest. The following methods are available to schedule a chaos scenario in recurring ways:
- 1. Every Hour
- 2. Every Day
- 3. Every Week
- 4. Every Month
-
-
-
-Scheduling a Cron Chaos Scenario
-
-
-## 7. Verify and commit
-
-This is the final step in chaos scenario creation process. In this step, you can validate all the changes related to the chaos scenario like the chaos scenario name, the experiment weights, chaos scenario description, chaos scenario manifest etc. Once you have verified all the changes, you can click the **Finish** button to start the schedule.
-
-
-
-View Summary and Commit
-
-
-## Learn more
-
-- [Observe Chaos Scenario ](observe-workflow.md)
-- [Edit Schedule](edit-schedule.md)
-- [Save Chaos Scenarios as a Template](save-as-template.md)
diff --git a/website/docs/user-guides/setup-datasource.md b/website/docs/user-guides/setup-datasource.md
index 3768e982..b40bc148 100644
--- a/website/docs/user-guides/setup-datasource.md
+++ b/website/docs/user-guides/setup-datasource.md
@@ -8,10 +8,6 @@ sidebar_label: Setup Data source
This guide provides sample scrape job to be used for Prometheus deployment’s scrape-configmap and service monitors to be used with Prometheus operator for the different architectural topologies for integrating Prometheus (connecting a data source link) with Chaos center.
-### Before you begin
-
-To setup a data source for a chaos center project, you must know about [open observability](../concepts/open-observability.md) and [data source considerations](../concepts/datasource.md) in Litmus 2.0
-
### Topologies
Listed below are three among many topologies in which a data source can be setup for collecting chaos delegate cluster's metrics along with chaos metrics for chaos center.
diff --git a/website/docs/user-guides/share-app-dashboard.md b/website/docs/user-guides/share-app-dashboard.md
index f718be11..93bf92c6 100644
--- a/website/docs/user-guides/share-app-dashboard.md
+++ b/website/docs/user-guides/share-app-dashboard.md
@@ -8,7 +8,7 @@ sidebar_label: Sharing Application Dashboards
## Uploading and downloading a dashboard
-- **Upload the JSON:** During the dashboard creation process, you can upload your JSON file having all the configurations of the dashboard. To read about the configurations and format of the JSON file for the application dashboard [click here](../concepts/app-infra-monitoring.md). To learn more about the schema of the dashboard JSON [click here](https://raw.githubusercontent.com/litmuschaos/litmus/master/monitoring/portal-dashboards/schema.json).
+- **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
diff --git a/website/docs/user-guides/view-probe-details.md b/website/docs/user-guides/view-probe-details.md
new file mode 100644
index 00000000..1268ef25
--- /dev/null
+++ b/website/docs/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:
+
+
\ No newline at end of file
diff --git a/website/docs/user-guides/view-user.md b/website/docs/user-guides/view-user.md
index 5de74eea..49d25e3d 100644
--- a/website/docs/user-guides/view-user.md
+++ b/website/docs/user-guides/view-user.md
@@ -6,11 +6,11 @@ sidebar_label: View users
---
-> In the `/settings` route (settings on the sidebar) the `User Management` tab can be used to access the user management feature by the admin. We recommend learning about the concept of [user management](../concepts/user-management.md) before proceeding with the following user guides.
+> 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.
+The admin can access the `User Management` tab to check the list of all users present in the portal.
diff --git a/website/package.json b/website/package.json
index d3005379..d19a37f6 100644
--- a/website/package.json
+++ b/website/package.json
@@ -7,6 +7,7 @@
"start": "docusaurus start",
"build": "docusaurus build",
"swizzle": "docusaurus swizzle",
+ "clear": "docusaurus clear",
"deploy": "docusaurus deploy",
"serve": "docusaurus serve",
"format": "prettier --write **/*.{js,jsx,ts,tsx}"
diff --git a/website/sidebars.js b/website/sidebars.js
index 3ed98afe..91d045c7 100644
--- a/website/sidebars.js
+++ b/website/sidebars.js
@@ -1,180 +1,108 @@
module.exports = {
- docs: [
- // Introduction
+ "docs": [
{
- Introduction: [
- 'introduction/what-is-litmus',
- 'introduction/features',
- 'introduction/usage',
- 'introduction/core-principles',
- 'introduction/community',
- 'introduction/other-links'
- ]
+ "Introduction": ["introduction/what-is-litmus", "introduction/features", "introduction/usage", "introduction/core-principles", "introduction/community", "introduction/other-links"]
},
-
- // Getting Started
{
- 'Getting Started': [
- 'getting-started/resources',
- 'getting-started/installation',
- 'getting-started/run-your-first-workflow'
+ "Getting Started": [
+ "getting-started/resources",
+ "getting-started/installation",
+ "getting-started/run-your-first-experiment",
+ "getting-started/create-your-first-custom-chaos-experiment"
]
},
-
- // Architecture
{
- Architecture: [
- 'architecture/overview',
- 'architecture/architecture-summary',
- 'architecture/chaos-control-plane',
- 'architecture/chaos-execution-plane',
- 'architecture/chaos-experiment-flow',
- {
- 'Chaos Observability Flow': [
- 'architecture/chaos-observability-flow-overview',
- 'architecture/chaos-observability-flow-visualization',
- 'architecture/chaos-observability-flow-logging',
- 'architecture/chaos-observability-flow-monitoring',
- 'architecture/chaos-observability-flow-summarisation',
- 'architecture/chaos-observability-flow-analytics'
- ]
- }
+ "Architecture": [
+ "architecture/overview",
+ "architecture/architecture-summary",
+ "architecture/chaos-control-plane",
+ "architecture/chaos-execution-plane",
+ "architecture/chaos-experiment-flow"
]
},
-
- // Concepts
{
- Concepts: [
- 'concepts/overview',
- 'concepts/chaos-experiment',
- 'concepts/probes',
- 'concepts/chaos-engine',
- 'concepts/chaos-result',
- 'concepts/chaoshub',
- {
- 'Chaos Scenario': ['concepts/chaos-workflow', 'concepts/visualize-workflow']
- },
- {
- Observability: [
- 'concepts/workflow-statistics',
- 'concepts/app-infra-monitoring',
- 'concepts/datasource',
- 'concepts/open-observability'
- ]
- },
- 'concepts/user-management',
- 'concepts/projects',
- 'concepts/teaming',
- 'concepts/gitops',
- 'concepts/oauth-dex-concept'
+ "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': [
- 'user-guides/overview',
+ "User Guides": [
+ "user-guides/overview",
{
- 'Advanced Installation': [
+ "Advanced Installation": [
{
- ChaosCenter: [
- 'user-guides/chaoscenter-oauth-dex-installation',
- 'user-guides/chaoscenter-cluster-scope-installation',
- 'user-guides/chaoscenter-namespace-scope-installation',
- 'user-guides/setup-without-ingress',
- 'user-guides/setup-with-ingress'
+ "ChaosCenter": [
+ "user-guides/chaoscenter-oauth-dex-installation",
+ "user-guides/chaoscenter-cluster-scope-installation",
+ "user-guides/chaoscenter-namespace-scope-installation",
+ "user-guides/setup-without-ingress",
+ "user-guides/setup-with-ingress"
]
},
- 'user-guides/chaosagents-installation'
+ "user-guides/chaos-infrastructure-installation"
]
},
- // To be added later
- // {
- // 'Running Litmus': ['user-guides/air-gapped']
- // },
{
- 'Injecting Fault': [
- 'user-guides/schedule-workflow',
- 'user-guides/observe-workflow',
- 'user-guides/edit-schedule',
- // 'user-guides/event-triggered-chaos',
- 'user-guides/save-as-template',
- 'user-guides/download-workflow-manifest',
- 'user-guides/re-run-workflow',
- 'user-guides/delete-workflow',
- 'user-guides/construct-workflow'
+ "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"
]
},
{
- 'Observing Chaos': [
- 'user-guides/observability-set-up',
- 'user-guides/analyze-workflow',
- 'user-guides/comparative-analysis',
- 'user-guides/setup-datasource',
- 'user-guides/configure-datasource',
- 'user-guides/manage-app-dashboard',
- 'user-guides/editing-queries-app-dashboard',
- 'user-guides/view-chaos-impact',
- 'user-guides/share-app-dashboard'
+ "Resilience Probes": [
+ "user-guides/create-resilience-probe",
+ "user-guides/delete-resilience-probe",
+ "user-guides/edit-resilience-probe",
+ "user-guides/view-resilience-probe"
]
},
- // 'user-guides/event-triggered-chaos',
- // To be added later
- // {
- // 'Litmus in CI/CD pipeline': [
- // 'user-guides/github-actions',
- // 'user-guides/gitlab-templates',
- // 'user-guides/keptn',
- // 'user-guides/spinnaker'
- // ]
- // },
- 'user-guides/account-settings',
+ "user-guides/account-settings",
{
- 'User Management': [
- 'user-guides/create-user',
- 'user-guides/view-user',
- 'user-guides/reset-password',
- 'user-guides/deactivate-user'
+ "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']
+ "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'
+ "Teaming": [
+ "user-guides/invite-team-member",
+ "user-guides/edit-invite",
+ "user-guides/accept-invite",
+ "user-guides/remove-team-member"
]
},
- 'user-guides/gitops-configuration',
- 'user-guides/image-registry',
- 'user-guides/uninstall-litmus',
- 'user-guides/upgrade'
+ "user-guides/gitops-configuration",
+ "user-guides/image-registry",
+ "user-guides/uninstall-litmus"
]
},
-
- // Litmusctl
{
- Litmusctl: [
- 'litmusctl/installation',
- {
- 'Connect Agent': ['litmusctl/usage-non-interactive-mode', 'litmusctl/usage-interactive-mode']
- },
- 'litmusctl/chaos-workflow-creation'
- ]
+ "Litmusctl": ["litmusctl/installation", "litmusctl/litmusctl-usage"]
},
-
- // Integrations
{
- Integrations: ['integrations/prometheus', 'integrations/grafana']
+ "Integrations": ["integrations/prometheus", "integrations/grafana"]
},
-
- // Troubleshooting
- 'troubleshooting',
-
- // FAQ
- 'faq'
+ "troubleshooting",
+ "glossary",
+ "faq"
]
}
diff --git a/website/versioned_sidebars/version-3.0.0-sidebars.json b/website/versioned_sidebars/version-3.0.0-sidebars.json
index 1502ca78..164818d1 100644
--- a/website/versioned_sidebars/version-3.0.0-sidebars.json
+++ b/website/versioned_sidebars/version-3.0.0-sidebars.json
@@ -80,7 +80,10 @@
]
},
{
- "Managing Projects": ["user-guides/change-project-name", "user-guides/leave-project"]
+ "Managing Projects": [
+ "user-guides/change-project-name",
+ "user-guides/leave-project"
+ ]
},
{
"Teaming": [
@@ -96,10 +99,16 @@
]
},
{
- "Litmusctl": ["litmusctl/installation", "litmusctl/litmusctl-usage"]
+ "Litmusctl": [
+ "litmusctl/installation",
+ "litmusctl/litmusctl-usage"
+ ]
},
{
- "Integrations": ["integrations/prometheus", "integrations/grafana"]
+ "Integrations": [
+ "integrations/prometheus",
+ "integrations/grafana"
+ ]
},
"troubleshooting",
"glossary",
.default})
-Data flow for application and infrastructure monitoring
-.default})
-JSON schema for monitoring dashboards
-.default})
+.default})
-### 2. View the Chaos-Experiments
+### 2. View the Chaos Faults
-Similarly, you can view the different charts and the experiment. These charts are sorted according to different categories like generic, aws, azure, kube-components etc.
+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.
.default})
-### 3. View the experiment details
+### 3. View the fault details
-You can select one of the chaos experiment and can examine the experiment details.
-The experiment page consists of all the important details like the description of the experiment, a tutorial video, the maintainer of the experiment etc.
-You can also find experiment yaml link, RBAC link and the ChaosEngine yaml link of the experiment.
-These yaml links are required for the creation of Custom Chaos Scenarios.
+You can select one of the chaos faults and can examine the fault details.
+The fault page consists of all the important details like the description of the fault, a tutorial video, the maintainer of the fault, etc.
+You can also find the fault yaml link, RBAC link, and the ChaosEngine yaml link of the fault.
+These yaml links are required for the creation of Custom Chaos Experiments.
.default})
@@ -92,13 +92,11 @@ To remove a ChaosHub from a project, you can select the **Disconnect Hub** optio
## Summary
-ChaosHubs are basically a collection of different clones of the Chaos-Charts repository, which consists of a variety of experiments and pre-defined chaos scenarios. You can use a ChaosHub to construct a custom chaos scenarios and tune it according to the use-case. These ChaosHubs can also be synced with the latest changes. New experiments and pre-defined chaos scenarios can also be added in the repository which can be directly used in the ChaosCenter.
-
-## Resources
-
-
+You can select one of the chaos faults and can examine the fault details.
+The fault page consists of all the important details like the description of the fault, a tutorial video, the maintainer of the fault, etc.
+You can also find the fault yaml link, RBAC link, and the ChaosEngine yaml link of the fault.
+These yaml links are required for the creation of Custom Chaos Experiments.
## Learn More
-- [What is a Chaos Scenario](chaos-workflow.md)
-- [Examine the ChaosResult](chaos-result.md)
+- [What is a Chaos Experiment](chaos-workflow.md)
diff --git a/website/docs/concepts/datasource.md b/website/docs/concepts/datasource.md
deleted file mode 100644
index 9faaf4b2..00000000
--- a/website/docs/concepts/datasource.md
+++ /dev/null
@@ -1,51 +0,0 @@
----
-id: datasource
-title: Manage Datasources
-sidebar_label: Datasource
----
-
----
-
-The primary stateful data store for litmus's chaos center is a mongoDB statefulset. It powers all the features in chaos center including authentication, chaos injection and analysis, chaos delegate connections etc. Apart from the primary data store, the portal provides a way to add Prometheus (TSDB) data sources for time series data visualization and monitoring. The principle of Open observability drives the chaos center and allows users to manage the data sources for a project in multiple topologies for chaos delegate specific and cross chaos delegate dashboards. The system allows to either have multiple data sources or a single data source scraping metrics and events from all target chaos delegates for monitoring chaos impact on
-application OR infrastructure.
-
-## Prerequisites
-
-The following should be required before knowing about managing data sources in chaos center:
-
-- [Running Chaos Scenarios](../getting-started/run-your-first-workflow.md)
-- [Prometheus TSDB](https://prometheus.io/)
-
-## Data flow architecture
-
-The chaos center provides the functionality to connect multiple prometheus data sources across projects to harness insights on application or system behavior during chaos manifested on real-time monitoring dashboards. Litmus follows an open observability model which enables users to plug metrics from any Prometheus exporter into the data source connected to a chaos center project to visualize the same on dashboards. Along with system and application metrics the metrics exposed by `chaos-exporter` service (a prometheus metrics exporter for chaos injection events and results or verdicts) on the execution plane or target chaos delegate's cluster is necessary to be ingested into the same data source to be connected to the project in order to facilitate chaos interleaving. Existing monitoring infrastructure for observing the target chaos delegate's cluster can also be used if it is prometheus based, plugging the metrics from `chaos-exporter` in such cases should be sufficient.
-
-.default})
-Data flow from data sources
-.default})
.default})
.default})
+
+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..default})
.default})
+.default})
+
+## 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/docs/concepts/visualize-workflow.md b/website/docs/concepts/visualize-workflow.md
deleted file mode 100644
index f6629d39..00000000
--- a/website/docs/concepts/visualize-workflow.md
+++ /dev/null
@@ -1,71 +0,0 @@
----
-id: visualize-workflow
-title: Visualize the Chaos Scenario Execution
-sidebar_label: Visualize Chaos Scenario
----
-
----
-
-Visualization is an important aspect while doing chaos engineering. It allows the user to discover and inspect different changes that occur during a Chaos Scenario execution. .default})
- .default})
-
-## Summary
-
-After scheduling a chaos scenario, a user can view the details of the running chaos scenario from the ChaosCenter. ChaosCenter provides a realtime graph that is used to visualise the chaos scenario and get the details of individual step of the chaos scenario. Important details like the logs and target applications can be viewed from ChaosCenter. These logs are also downloadable. User can view the details in 2 different ways i.e `Graph View` and `Table View`. Once the chaos scenario exection is completed, the resiliency score is calcualted and the ChaosResult for the ChaosEngine pods are available now.
-
-## Learn More
-
-- [Explore Probes](probes.md)
-- [What is a Chaos Scenario](chaos-workflow.md)
-- [Examine the ChaosResult](chaos-result.md)
diff --git a/website/docs/concepts/workflow-statistics.md b/website/docs/concepts/workflow-statistics.md
deleted file mode 100644
index 8ab4714e..00000000
--- a/website/docs/concepts/workflow-statistics.md
+++ /dev/null
@@ -1,50 +0,0 @@
----
-id: workflow-statistics
-title: Chaos Scenarios Statistics
-sidebar_label: Scenarios Statistics
----
-
----
-
-Chaos injections often tends to disrupt tightly coupled micro-services and processes. Visualizing the results and plotting analytical graphs prove to be useful under such circumstances. An analytical overview of chaos scenarios for an entire month or a year can help in benchmarking release cycles and building a viable cloud-native product. Also a comparative study over time or rather just being able to observe and plot resiliency scores across different types of chaos scenarios on different subsystems provide a conclusive summary of the reliability metrics for an application under test (AUT) and the supporting platform or infrastructure.
-
-## Prerequisites
-
-The following should be required before knowing about chaos scenario statistics:
-
-- [Chaos Scenarios](chaos-workflow.md)
-- [Visualize Chaos Scenarios](visualize-workflow.md)
-
-## Data flow architecture
-
-The chaos center automatically detects scheduled chaos scenario runs on all connected chaos delegates for a project and provides statistical graphs and visualizations. Data for chaos scenarios runs and chaos results from all the chaos delegates are stored in a mongoDB database which is then ingested into analytical pipelines in the control plane server to transform the raw data into meaningful insights for browsing and reporting.
-
-.default})
-Data flow for statistical analysis
-.default})
-## **Verify Successful Registration of the Self Chaos Delegate**
-
-Once the project is created, the cluster is automatically registered as a chaos target via installation of [Chaos Delegate](resources.md#chaosagents). This is represented as [Self Chaos Delegate](resources.md#types-of-chaosagents) in [ChaosCenter](resources.md#chaoscenter).
-
-```bash
-kubectl get pods -n litmus
-```
-
-```bash
-NAME READY STATUS RESTARTS AGE
-chaos-exporter-547b59d887-4dm58 1/1 Running 0 5m27s
-chaos-operator-ce-84ddc8f5d7-l8c6d 1/1 Running 0 5m27s
-event-tracker-5bc478cbd7-xlflb 1/1 Running 0 5m28s
-litmusportal-frontend-97c8bf86b-mx89w 1/1 Running 0 15m
-litmusportal-server-6fd57cc89-6w5pn 1/1 Running 0 15m
-litmusportal-auth-server-7b596fff9-5s6g5 1/1 Running 0 15m
-mongo-0 1/1 Running 0 15m
-subscriber-958948965-qbx29 1/1 Running 0 5m30s
-workflow-controller-78fc7b6c6-w82m7 1/1 Running 0 5m32s
-```
-
-## Resources
-
-
-
## Learn more
- [Install ChaosCenter in Namespace Scope](../user-guides/chaoscenter-namespace-scope-installation.md)
-- [Connect External Chaos Delegates to ChaosCenter](../user-guides/chaosagents-installation.md)
+- [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/docs/getting-started/run-your-first-workflow.md b/website/docs/getting-started/run-your-first-experiment.md
similarity index 99%
rename from website/docs/getting-started/run-your-first-workflow.md
rename to website/docs/getting-started/run-your-first-experiment.md
index 6f15b463..4af01a5d 100644
--- a/website/docs/getting-started/run-your-first-workflow.md
+++ b/website/docs/getting-started/run-your-first-experiment.md
@@ -1,5 +1,5 @@
---
-id: run-your-first-workflow
+id: run-your-first-experiment
title: Run your First Chaos Scenario in 5 minutes
sidebar_label: Run Your First Chaos Scenario
---
diff --git a/website/docs/glossary.md b/website/docs/glossary.md
index b69b8a12..4ac3a594 100644
--- a/website/docs/glossary.md
+++ b/website/docs/glossary.md
@@ -1,7 +1,59 @@
---
id: glossary
title: Glossary
-sidebar_label: glossary
+sidebar_label: Glossary
---
-## Coming Soon
+:::note
+Pleas 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.
+
+.default})
+.default})
+.default})
+.default})
+.default})
+.default})
+.default})
+.default})
### 2. Enter edit mode
-Click on either the text (demonstrated in this example as `admin’s project`) or on the edit icon next to it to enter the edit mode:
+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:
-.default})
+.default})
+.default})
+
+## 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)
+
+.default})
+
+## 3. Enter the details of the probe to create
+
+Enter the details of the probe such as name, description (optional), tags (optional)
+
+.default})
+
+## 4. Configure the probe properties
+
+Configure the properties for the probe you are creating, such as, Timeout, Interval, Retry, etc.
+
+.default})
+
+## 5. Configure the probe details
+
+Configure the details for the probe you are creating, once completed, click the `Setup Probe` button
+
+.default})
+
+The new probe will appear in the list as shown:
+
+.default})
\ No newline at end of file
diff --git a/website/docs/user-guides/create-user.md b/website/docs/user-guides/create-user.md
index 6613560b..3f8aa73d 100644
--- a/website/docs/user-guides/create-user.md
+++ b/website/docs/user-guides/create-user.md
@@ -8,25 +8,25 @@ sidebar_label: Create User
This feature enables the admin to create a new user by assigning a unique username and password for the user. In addition to this, the admin can also provide the name and email address of the new user which is optional.
-## 1. Create a new user
+## 1. Navigate to User Management
-Click the `Create new user` button as observed below:
+Go to the `User Management` tab of the account settings page:
-.default})
+.default})
+.default})
+.default})
+.default})
+.default})
+.default})
+
+## 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:
+
+.default})
+
+## 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.
+
+.default})
+
+As stated above, the runs have been removed as well.
+
+## Learn more
+
+- [schedule a chaos experiment](schedule-experiment.md)
diff --git a/website/docs/user-guides/delete-resilience-probe.md b/website/docs/user-guides/delete-resilience-probe.md
new file mode 100644
index 00000000..65b2d602
--- /dev/null
+++ b/website/docs/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:
+
+.default})
+
+## 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:
+
+.default})
+
+## 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.
+
+.default})
\ No newline at end of file
diff --git a/website/docs/user-guides/delete-workflow.md b/website/docs/user-guides/delete-workflow.md
deleted file mode 100644
index 66cb2d59..00000000
--- a/website/docs/user-guides/delete-workflow.md
+++ /dev/null
@@ -1,43 +0,0 @@
----
-id: delete-workflow
-title: Delete a Chaos Scenario
-sidebar_label: Delete Chaos Scenario
----
-
----
-
-If required, it is possible to delete a chaos scenario schedule that you no longer wish to run against your application.
-
-:::note
-This also means that all the runs corresponding to that chaos scenario will also be deleted.
-:::
-
-## Before you begin
-
-You can learn about the concept of chaos scenarios [here](../concepts/chaos-workflow.md) and how to schedule your first chaos scenario [here](schedule-workflow.md).
-
-## 1. Go to the chaos scenarios sections
-
-In the `Chaos Scenario` page, go to the `Schedules` tab and click on the options menu for the specific schedule you wish to delete:
-
-.default})
-
-## Learn more
-
-- [schedule a chaos scenario](schedule-workflow.md)
diff --git a/website/docs/user-guides/download-workflow-manifest.md b/website/docs/user-guides/download-experiment-manifest.md
similarity index 84%
rename from website/docs/user-guides/download-workflow-manifest.md
rename to website/docs/user-guides/download-experiment-manifest.md
index ce53bd28..a2229dd0 100644
--- a/website/docs/user-guides/download-workflow-manifest.md
+++ b/website/docs/user-guides/download-experiment-manifest.md
@@ -1,5 +1,5 @@
---
-id: download-workflow-manifest
+id: download-experiment-manifest
title: Download Chaos Scenario Manifest
sidebar_label: Download Chaos Scenario Manifest
---
@@ -10,7 +10,7 @@ You can save a schedule configurations manifest as a `YAML`. This section goes o
## Before you begin
-You can learn how to schedule your first chaos scenario [here](schedule-workflow.md).
+You can learn how to schedule your first chaos scenario [here](schedule-experiment.md).
## 1. Go to the chaos scenarios sections
@@ -26,6 +26,6 @@ After opening the options menu, click on the `Download Manifest` option. Having
## Learn more
-- [Schedule a chaos scenario](schedule-workflow.md)
-- [Re-run a chaos scenario](re-run-workflow.md)
-- [Delete a chaos scenario](delete-workflow.md)
+- [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/docs/user-guides/edit-invite.md b/website/docs/user-guides/edit-invite.md
index 3fe415a4..3328bbcb 100644
--- a/website/docs/user-guides/edit-invite.md
+++ b/website/docs/user-guides/edit-invite.md
@@ -8,9 +8,9 @@ sidebar_label: Edit/Cancel invite
If you had a change of mind and you wanted to change the role of an invitation that has been already sent, we got you!
-Just go to the invited tab, change the role, and hit the `Resend` button. You can also cancel the invitation by just clicking on the `bin` icon.
+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.
-.default})
+.default})
+
+## 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):
+
+.default})
+
+## 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.
+
+.default})
\ No newline at end of file
diff --git a/website/docs/user-guides/edit-schedule.md b/website/docs/user-guides/edit-schedule.md
index b3c066e1..d30b8a32 100644
--- a/website/docs/user-guides/edit-schedule.md
+++ b/website/docs/user-guides/edit-schedule.md
@@ -1,22 +1,22 @@
---
id: edit-schedule
-title: Edit Chaos Scenario Schedule
-sidebar_label: Edit Chaos Scenario Schedule
+title: Edit Chaos Experiment Schedule
+sidebar_label: Edit Chaos Experiment Schedule
---
---
## Before you begin
-You must schedule a chaos scenario. To know more about scheduling chaos scenarios click [here](schedule-workflow.md)
+You must schedule a chaos experiment. To know more about scheduling chaos experiments click [here](schedule-experiment.md)
---
-After you have scheduled a chaos scenario, you might have a need of changing the schedule of a recurring chaos scenario. To edit the schedule follow these steps:
+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 `Schedules` tab of `Litmus Chaos Scenarios` page you can click on the triple dots of the schedule to access more options for it. From the menu select the `Edit Schedule` option.
+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.
.default})
@@ -25,16 +25,16 @@ In the `Schedules` tab of `Litmus Chaos Scenarios` page you can click on the tri
## 2. Click on edit button
-Now you'll be seeing the Summary of your chaos scenario and you can click on the `Edit` button to change the schedule.
+Now you'll be seeing the pipeline diagram of your chaos experiment and you can click on the `Schedule` tab to change the schedule.
.default})
-Summary of the Chaos Scenario with Edit button
+.default})
@@ -43,10 +43,10 @@ Here you can change the schedule to the required interval and click on the `Veri
## 4. Save the changes
-Click on the `Save Changes` button to commit the changes to your chaos scenario.
+Click the `Save` button to save the changes to the experiment chaos experiment.
## Learn more
-- [Observe Chaos Scenario](observe-workflow.md)
-- [Save Chaos Scenarios as a Template](save-as-template.md)
-- [Re-run a Chaos Scenario](re-run-workflow.md)
+- [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/docs/user-guides/gitops-configuration.md b/website/docs/user-guides/gitops-configuration.md
index 9a33bd53..794bae19 100644
--- a/website/docs/user-guides/gitops-configuration.md
+++ b/website/docs/user-guides/gitops-configuration.md
@@ -4,47 +4,54 @@ title: Configuring GitOps
sidebar_label: Configuring GitOps
---
+:::note
+With the latest release of LitmusChaos 3.0.0:
+.default})
.default})
.default})
+.default})
+.default})
+.default})
+.default})
+.default})
+On successful acceptance of the invitation you will be able to collaborate over your project!
## Learn more
diff --git a/website/docs/user-guides/leave-project.md b/website/docs/user-guides/leave-project.md
index e84d23ba..293417fb 100644
--- a/website/docs/user-guides/leave-project.md
+++ b/website/docs/user-guides/leave-project.md
@@ -10,13 +10,15 @@ You can leave a project that you no longer wish to be a part of.
## 1. Identify the project you want to leave
-In the settings page, scroll to the very bottom of the `Team` tab. Here you will see a list of all the projects you are a part of, identify the project you’d like to leave and click on the `Leave Project` button:
+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:
-.default})
+.default})
+A confirmation dialog will pop up, click on the `Confirm` button to leave the project
+
+.default})
-Chaos Scenario Runs Table showing a Running Chaos Scenario
-.default})
-Graph of Podtato Head chaos scenario
-.default})
-Graph of a non Chaos Scenario
-.default})
-Podtato Head chaos scenario with Logs
-.default})
-Podtato Head chaos scenario with chaos logs and chaos result of generic/pod-delete experiment
-.default})
+
+## 2. Click on the `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:
+
+.default})
+
+## Learn more
+
+- [Schedule a chaos experiment](schedule-experiment.md)
+- [Delete a chaos experiment](delete-experiment.md)
diff --git a/website/docs/user-guides/re-run-workflow.md b/website/docs/user-guides/re-run-workflow.md
deleted file mode 100644
index 327007d4..00000000
--- a/website/docs/user-guides/re-run-workflow.md
+++ /dev/null
@@ -1,30 +0,0 @@
----
-id: re-run-workflow
-title: Re-run a chaos scenario
-sidebar_label: Re-run chaos scenario
----
-
----
-
-You can re-run any **_non-recurring_** schedule should you wish to test your application against it at any point.
-
-## Before you begin
-
-You can learn how to schedule your first chaos scenario [here](schedule-workflow.md).
-
-## 1. Go to the chaos scenarios sections
-
-In the `Chaos Scenario` page, go to the `Schedules` tab and click on the options menu for the specific schedule you wish to re-run:
-
-.default})
+.default})
+.default})
+.default})
+.default})
+.default})
+.default})
+.default})
+.default})
+.default})
+.default})
+.default})
+.default})
+.default})
+.default})
+.default})
+.default})
+.default})
-Home Page
-.default})
-Selecting a Chaos Delegate
-.default})
-Choosing a Chaos Scenario
-.default})
-Change name and description
-.default})
-Tuning a Predefined Chaos Scenario (Podtato Head)
-.default})
-Editing Experiment Sequence
-.default})
-Adding Experiments to Chaos Scenario (Available after choosing a Hub in previous step)
-.default})
-.default})
-Adjust Experiment Weights
-.default})
-Scheduling a Cron Chaos Scenario
-.default})
-View Summary and Commit
-.default})
+
+## 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:
+
+.default})
+
+## 3. View Probe configurations
+
+On the same page you can click on the `Probe Configuration` tab to see the configuration of the said probe:
+
+.default})
\ No newline at end of file
diff --git a/website/docs/user-guides/view-user.md b/website/docs/user-guides/view-user.md
index 5de74eea..49d25e3d 100644
--- a/website/docs/user-guides/view-user.md
+++ b/website/docs/user-guides/view-user.md
@@ -6,11 +6,11 @@ sidebar_label: View users
---
-> In the `/settings` route (settings on the sidebar) the `User Management` tab can be used to access the user management feature by the admin. We recommend learning about the concept of [user management](../concepts/user-management.md) before proceeding with the following user guides.
+> 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.
+The admin can access the `User Management` tab to check the list of all users present in the portal.
.default})
diff --git a/website/package.json b/website/package.json
index d3005379..d19a37f6 100644
--- a/website/package.json
+++ b/website/package.json
@@ -7,6 +7,7 @@
"start": "docusaurus start",
"build": "docusaurus build",
"swizzle": "docusaurus swizzle",
+ "clear": "docusaurus clear",
"deploy": "docusaurus deploy",
"serve": "docusaurus serve",
"format": "prettier --write **/*.{js,jsx,ts,tsx}"
diff --git a/website/sidebars.js b/website/sidebars.js
index 3ed98afe..91d045c7 100644
--- a/website/sidebars.js
+++ b/website/sidebars.js
@@ -1,180 +1,108 @@
module.exports = {
- docs: [
- // Introduction
+ "docs": [
{
- Introduction: [
- 'introduction/what-is-litmus',
- 'introduction/features',
- 'introduction/usage',
- 'introduction/core-principles',
- 'introduction/community',
- 'introduction/other-links'
- ]
+ "Introduction": ["introduction/what-is-litmus", "introduction/features", "introduction/usage", "introduction/core-principles", "introduction/community", "introduction/other-links"]
},
-
- // Getting Started
{
- 'Getting Started': [
- 'getting-started/resources',
- 'getting-started/installation',
- 'getting-started/run-your-first-workflow'
+ "Getting Started": [
+ "getting-started/resources",
+ "getting-started/installation",
+ "getting-started/run-your-first-experiment",
+ "getting-started/create-your-first-custom-chaos-experiment"
]
},
-
- // Architecture
{
- Architecture: [
- 'architecture/overview',
- 'architecture/architecture-summary',
- 'architecture/chaos-control-plane',
- 'architecture/chaos-execution-plane',
- 'architecture/chaos-experiment-flow',
- {
- 'Chaos Observability Flow': [
- 'architecture/chaos-observability-flow-overview',
- 'architecture/chaos-observability-flow-visualization',
- 'architecture/chaos-observability-flow-logging',
- 'architecture/chaos-observability-flow-monitoring',
- 'architecture/chaos-observability-flow-summarisation',
- 'architecture/chaos-observability-flow-analytics'
- ]
- }
+ "Architecture": [
+ "architecture/overview",
+ "architecture/architecture-summary",
+ "architecture/chaos-control-plane",
+ "architecture/chaos-execution-plane",
+ "architecture/chaos-experiment-flow"
]
},
-
- // Concepts
{
- Concepts: [
- 'concepts/overview',
- 'concepts/chaos-experiment',
- 'concepts/probes',
- 'concepts/chaos-engine',
- 'concepts/chaos-result',
- 'concepts/chaoshub',
- {
- 'Chaos Scenario': ['concepts/chaos-workflow', 'concepts/visualize-workflow']
- },
- {
- Observability: [
- 'concepts/workflow-statistics',
- 'concepts/app-infra-monitoring',
- 'concepts/datasource',
- 'concepts/open-observability'
- ]
- },
- 'concepts/user-management',
- 'concepts/projects',
- 'concepts/teaming',
- 'concepts/gitops',
- 'concepts/oauth-dex-concept'
+ "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': [
- 'user-guides/overview',
+ "User Guides": [
+ "user-guides/overview",
{
- 'Advanced Installation': [
+ "Advanced Installation": [
{
- ChaosCenter: [
- 'user-guides/chaoscenter-oauth-dex-installation',
- 'user-guides/chaoscenter-cluster-scope-installation',
- 'user-guides/chaoscenter-namespace-scope-installation',
- 'user-guides/setup-without-ingress',
- 'user-guides/setup-with-ingress'
+ "ChaosCenter": [
+ "user-guides/chaoscenter-oauth-dex-installation",
+ "user-guides/chaoscenter-cluster-scope-installation",
+ "user-guides/chaoscenter-namespace-scope-installation",
+ "user-guides/setup-without-ingress",
+ "user-guides/setup-with-ingress"
]
},
- 'user-guides/chaosagents-installation'
+ "user-guides/chaos-infrastructure-installation"
]
},
- // To be added later
- // {
- // 'Running Litmus': ['user-guides/air-gapped']
- // },
{
- 'Injecting Fault': [
- 'user-guides/schedule-workflow',
- 'user-guides/observe-workflow',
- 'user-guides/edit-schedule',
- // 'user-guides/event-triggered-chaos',
- 'user-guides/save-as-template',
- 'user-guides/download-workflow-manifest',
- 'user-guides/re-run-workflow',
- 'user-guides/delete-workflow',
- 'user-guides/construct-workflow'
+ "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"
]
},
{
- 'Observing Chaos': [
- 'user-guides/observability-set-up',
- 'user-guides/analyze-workflow',
- 'user-guides/comparative-analysis',
- 'user-guides/setup-datasource',
- 'user-guides/configure-datasource',
- 'user-guides/manage-app-dashboard',
- 'user-guides/editing-queries-app-dashboard',
- 'user-guides/view-chaos-impact',
- 'user-guides/share-app-dashboard'
+ "Resilience Probes": [
+ "user-guides/create-resilience-probe",
+ "user-guides/delete-resilience-probe",
+ "user-guides/edit-resilience-probe",
+ "user-guides/view-resilience-probe"
]
},
- // 'user-guides/event-triggered-chaos',
- // To be added later
- // {
- // 'Litmus in CI/CD pipeline': [
- // 'user-guides/github-actions',
- // 'user-guides/gitlab-templates',
- // 'user-guides/keptn',
- // 'user-guides/spinnaker'
- // ]
- // },
- 'user-guides/account-settings',
+ "user-guides/account-settings",
{
- 'User Management': [
- 'user-guides/create-user',
- 'user-guides/view-user',
- 'user-guides/reset-password',
- 'user-guides/deactivate-user'
+ "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']
+ "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'
+ "Teaming": [
+ "user-guides/invite-team-member",
+ "user-guides/edit-invite",
+ "user-guides/accept-invite",
+ "user-guides/remove-team-member"
]
},
- 'user-guides/gitops-configuration',
- 'user-guides/image-registry',
- 'user-guides/uninstall-litmus',
- 'user-guides/upgrade'
+ "user-guides/gitops-configuration",
+ "user-guides/image-registry",
+ "user-guides/uninstall-litmus"
]
},
-
- // Litmusctl
{
- Litmusctl: [
- 'litmusctl/installation',
- {
- 'Connect Agent': ['litmusctl/usage-non-interactive-mode', 'litmusctl/usage-interactive-mode']
- },
- 'litmusctl/chaos-workflow-creation'
- ]
+ "Litmusctl": ["litmusctl/installation", "litmusctl/litmusctl-usage"]
},
-
- // Integrations
{
- Integrations: ['integrations/prometheus', 'integrations/grafana']
+ "Integrations": ["integrations/prometheus", "integrations/grafana"]
},
-
- // Troubleshooting
- 'troubleshooting',
-
- // FAQ
- 'faq'
+ "troubleshooting",
+ "glossary",
+ "faq"
]
}
diff --git a/website/versioned_sidebars/version-3.0.0-sidebars.json b/website/versioned_sidebars/version-3.0.0-sidebars.json
index 1502ca78..164818d1 100644
--- a/website/versioned_sidebars/version-3.0.0-sidebars.json
+++ b/website/versioned_sidebars/version-3.0.0-sidebars.json
@@ -80,7 +80,10 @@
]
},
{
- "Managing Projects": ["user-guides/change-project-name", "user-guides/leave-project"]
+ "Managing Projects": [
+ "user-guides/change-project-name",
+ "user-guides/leave-project"
+ ]
},
{
"Teaming": [
@@ -96,10 +99,16 @@
]
},
{
- "Litmusctl": ["litmusctl/installation", "litmusctl/litmusctl-usage"]
+ "Litmusctl": [
+ "litmusctl/installation",
+ "litmusctl/litmusctl-usage"
+ ]
},
{
- "Integrations": ["integrations/prometheus", "integrations/grafana"]
+ "Integrations": [
+ "integrations/prometheus",
+ "integrations/grafana"
+ ]
},
"troubleshooting",
"glossary",