[DOC-2814] Bugs Bash [WIP]

docs/chaos-engineering/configure-chaos-experiments/probes/configure-and-add-probe.md

@@ -1,9 +1,11 @@
 ---
-title: Configure and Add Probes
+title: Configure and Add Probe(s)
 sidebar_position: 2
 ---
 
-A probe explores the behavior of a system in a chaotic or unpredictable manner and helps validate the declarative hypothesis set by the user. The goal of a chaos probe is to understand the underlying patterns and laws that govern the behavior of these systems, and to use that understanding to predict or control their behavior.
+A probe explores the behavior of a [system that is in a chaotic or unpredictable state](../../technical-reference/chaos-faults) and helps validate the [declarative hypothesis](../../technical-reference/probes/overview.md) set by the user. The goal of a chaos probe is to understand the underlying patterns and laws that govern the behavior of these systems, and use this understanding to predict or control their behavior.
+
+This section walks you step-by-step through how to configure and add probes to a chaos experiment.
 
 ## Before you begin
 
@@ -12,18 +14,16 @@ A probe explores the behavior of a system in a chaotic or unpredictable manner a
 
 ## Prerequisites
 
-- To configure and setup a probe inside a fault there should be an active chaos infrastructure to schedule the chaos experiment in.
+- To configure and setup a probe inside a fault, you should have an active chaos infrastructure where you can schedule the chaos experiment.
 - Enterprise Hub connectivity status should be active
+- Probe requires the read/write access to the chaos experiment to schedule or navigate to the probe addition user interface.
+- Probe requires read access to the chaos infrastructure to select a chaos infrastructure when creating an experiment.
+- Probe requires read access to the chaos hub to select faults from the chaos hub while creating an experiment.
 
-## Requirements
-
-- Probe requires the Chaos Experiment Read/Write access to be able to schedule/navigate to the probe addition UI.
-- Probe requires at least the Chaos Infra Read access to be able to select a Chaos Infrastructure while creating an experiment.
-- Probe requires at least the Chaos Hub Read access to be able to select faults from Chaos Hub while creating an experiment.
-
-## Step 1: Navigate to chaos experiment creation
+Once the prerequisites are fulfilled, you can configure and add a probe to your experiment using the following steps. 
 
-Navigate to the Create Experiment View by clicking the `+ New Experiment` button and provide a name, description and tag for your experiment.
+## Step 1: Navigate to the chaos experiment creation
+Navigate to the **Create Experiment View** by clicking `+ New Experiment` button. Provide a name, description and tag for your experiment. The description and tag are optional fields. 
 
 Choose the active chaos infrastructure on which this experiment would be scheduled. This step is required so that we can proceed to the fault selection step where probes can be configured.
 
@@ -35,32 +35,33 @@ And then click on `Start with blank canvas` once you see the start off drawer po
 
 ## Step 2: Select a fault
 
-Click on the `+` icon to open the fault selection drawer and choose the fault which you would like to execute in your chaos experiment based on the hypothesis decided.
+Click on the `+` icon to open the fault selection drawer and choose the fault to execute in your chaos experiment based on the hypothesis decided.
 
-Once a fault is clicked a Tuning drawer opens up with the fault name as a title, navigate to the last tab which says `Probes`. A default health check command probe should already be present. You can either add or replace the existing probe with a new one by clicking on the `+ Deploy new Probe` button.
+Once you click on a fault, a **Tuning drawer** opens up. Navigate to the last tab `Probes`. A default health check command probe will already be present. You can either add or replace the existing probe with a new one by clicking `+ Deploy new Probe` button.
 
 ![Step 2](./static/configure-and-add-probe/step2.png)
 
 ## Step 3: Add a probe
 
-Once the `Add Probe` modal opens up, provide a name for your probe, the type of the probe from a selection of HTTP, Command, Kuberentes and Prometheus Probe followed by the mode in which the probe will run.
+Once the `Add Probe` screen opens up, provide a name, the type of the probe (HTTP or Command or Kubernetes or Prometheus) and the mode in which you want to run the probe.
 
 ![Step 3.1](./static/configure-and-add-probe/step3.1.png)
 
-Provide the necessary probe attributes, since we chose HTTP Probe, we can see attributes related to HTTP, like URL, Method, Criteria, etc along with the common probe properties.
-
+Now, the screen shows common probe properties, such as `Probe timeout`, `Retry`, `Interval`, and so on. Enter relevant values, and click `Continue`.
 ![Step 3.2](./static/configure-and-add-probe/step3.2.png)
+
+Provide the required probe attributes. In this case, you have chosen HTTP probe, which shows attributes associated with it, such as `URL`, `Method`, `Criteria`, and so on. Enter relevant values, and click `Setup the probe`.
 ![Step 3.3](./static/configure-and-add-probe/step3.3.png)
 
 ## Step 4: Save the probe
 
-Once done, click on `Setup the Probe >` and your newly configured probe should be saved and appended to the manifest already. To view the configurations just saved, hover over `View` of the respective section.
+Once you have added the parameters for the probe, click `Setup the Probe >`. The newly configured probe will be saved and appended to the manifest. To view the configurations that you saved, hover over `View` of the respective probe.
 
 ![Step 4](./static/configure-and-add-probe/step4.png)
 
 ## Using YAML
 
-The entire manifest is available as YAML also, which can be accessed by switching over to the YAML view in Chaos Studio.
+The entire manifest is available as a YAML file, which can be accessed by switching over to the YAML view in chaos studio. Below is a sample manifest for the pod delete fault.
 
 ```yaml
 kind: Workflow

docs/chaos-engineering/get-started/powered-by-litmus.md

@@ -2,13 +2,13 @@
 sidebar_position: 3
 title: Powered by LitmusChaos
 ---
-# Harness Chaos Engineering powered by LitmusChaos
+# Harness Chaos Engineering (HCE) powered by LitmusChaos
 
 The chaos engineering module in the Harness platform is powered by the open source CNCF chaos engineering project [LitmusChaos](https://github.com/litmuschaos/litmus). Harness module adds additional features to make the practice of chaos engineering for enterprises easy.
 
 ![Harness Chaos Engineering Module](./static/overview/HCE-image.png)
 
-## Common capabilities with LitmusChaos
+## Common capabilities of HCE and LitmusChaos
 Following are the common features between Litmus and Harness Chaos Engineering:
 
 1. Scalable Platform

docs/chaos-engineering/technical-reference/probes/cmd-probe.md

@@ -3,15 +3,15 @@ title: Command Probe
 sidebar_position: 4
 ---
 
-The Command Probe allows developers to run Bash 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, you can 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.
+Command probe allows you to run Bash commands and match the output as a part of the entry or exit criteria. The intent behind this probe is to implement a non-standard and imperative way to express the hypothesis. For example, you can check for specific data within a database, parse the value out of a JSON blob that is dumped into a certain path, or check for the existence of a particular string in the service logs.
 
-:::info YAML Only Feature
-By default, the probe can only be defined in inline mode from the UI where the command is run from within the experiment image. However, it can also be run in 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. Refer to the probe schema [here](https://docs.litmuschaos.io/docs/concepts/probes#cmdprobe).
+:::info YAML only feature
+By default, this probe can be defined in inline mode from the user interface, where the command is run from within the experiment image. It can also be run in source mode, where the command execution is carried out from within a new pod whose image is specified. Inline mode is preferred for simple shell commands, and source mode is preferred when application-specific binaries are required. For more information, go to [probe schema](https://docs.litmuschaos.io/docs/concepts/probes#cmdprobe).
 :::
 
-## Where to define
+## Defining the probe
 
-The probes can be defined at **.spec.experiments[].spec.probe** path inside Chaos Engine.
+You can define the probe at **.spec.experiments[].spec.probe** path inside the chaos engine.
 
 ```yaml
 kind: Workflow
@@ -35,7 +35,7 @@ spec:
 
 ## Schema
 
-Probe schema for CMD Probe with common properties shared across all probes and properties unique to CMD probe.
+Listed below is the probe schema for the command probe, with properties shared across all the probes and properties unique to the command probe.
 
 <table>
   <tr>
@@ -53,13 +53,13 @@ Probe schema for CMD Probe with common properties shared across all probes and p
   <tr>
    <td>name
    </td>
-   <td>Flag to hold the name of the probe
+   <td>Flag that holds the name of the probe
    </td>
    <td>Mandatory
    </td>
    <td>N/A <code>type: string</code>
    </td>
-   <td>The <code>name</code> holds the name of the probe. It can be set based on the usecase
+   <td>The <code>name</code> holds the name of the probe. Set based on the use case.
    </td>
   </tr>
   <tr>
@@ -126,8 +126,6 @@ Probe schema for CMD Probe with common properties shared across all probes and p
 
 ### Source
 
-Source details for Command Probe.
-
 <table>
   <tr>
    <td><strong>Field</strong>
@@ -169,8 +167,6 @@ Source details for Command Probe.
 
 ### Comparator
 
-Comparator details for Command Probe.
-
 <table>
   <tr>
    <td><strong>Field</strong>
@@ -222,9 +218,7 @@ Comparator details for Command Probe.
   </tr>
 </table>
 
-### Run Properties
-
-Probe run properties for CMD Probe.
+### Run properties
 
 <table>
   <tr>

docs/chaos-engineering/technical-reference/probes/http-probe.md

@@ -3,19 +3,19 @@ title: HTTP Probe
 sidebar_position: 3
 ---
 
-The HTTP Probe 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](https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/GET) and [Post](https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/POST) methods.
+HTTP probe allows you to specify a URL that the experiment uses to determine the health or service availability (or other custom conditions) that is a part of the entry or exit criteria. The status code received is mapped against an expected status. It supports HTTP [GET](https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/GET) and [POST](https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/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`).
+The HTTP GET method sends a GET request to the specified URL. The response code received is matched with the response code based on the given criteria (`==`, `!=`, `oneOf`).
 
-In HTTP Post method it sends a http `POST` request to the provided url.
+HTTP POST method sends a `POST` request to the provided URL.
 
-:::info YAML Only Feature
-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](https://docs.litmuschaos.io/docs/concepts/chaos-engine) or the [ChaosExperiment](https://docs.litmuschaos.io/docs/concepts/chaos-experiment) CR. It can be defined at `.spec.experiments[].spec.probe` inside ChaosEngine. Also, `body` and `bodyPath` attributes are mutually exclusive. Refer to the probe schema [here](https://docs.litmuschaos.io/docs/concepts/probes#httpprobe).
+:::info YAML only feature
+In the case of a complex `POST` request in which the body spans multiple lines, the `bodyPath` attribute is used to specify the path to a file consisting of the same. This file is available to the experiment pod through a ConfigMap resource, wherein the ConfigMap name is defined in the [chaos engine](https://docs.litmuschaos.io/docs/concepts/chaos-engine) or the [chaos experiment](https://docs.litmuschaos.io/docs/concepts/chaos-experiment) CR. The `body` and `bodyPath` attributes are mutually exclusive. Go to the [probe schema](https://docs.litmuschaos.io/docs/concepts/probes#httpprobe) to learn more.
 :::
 
-## Where to define
+## Defining the probe
 
-The probes can be defined at **.spec.experiments[].spec.probe** path inside Chaos Engine.
+You can define the probes at **.spec.experiments[].spec.probe** path inside the chaos engine.
 
 ```yaml
 kind: Workflow
@@ -39,7 +39,7 @@ spec:
 
 ## Schema
 
-Probe schema for HTTP Probe with common properties shared across all probes and properties unique to HTTP probe.
+Listed below is the probe schema for HTTP Probe with common properties shared across all probes and properties unique to HTTP probe.
 
 <table>
   <tr>
@@ -130,9 +130,7 @@ Probe schema for HTTP Probe with common properties shared across all probes and
 
 ### Method
 
-Probe properties for method GET and POST.
-
-#### GET
+#### GET method properties
 
 <table>
   <tr>
@@ -173,7 +171,7 @@ Probe properties for method GET and POST.
   </tr>
 </table>
 
-#### POST
+#### POST method properties
 
 <table>
   <tr>
@@ -250,9 +248,7 @@ Probe properties for method GET and POST.
   </tr>
 </table>
 
-### Run Properties
-
-Probe run properties for HTTP Probe.
+### Run properties
 
 <table>
   <tr>

docs/chaos-engineering/technical-reference/probes/k8s-probe.md

@@ -10,9 +10,9 @@ With the proliferation of custom resources & operators, especially in the case o
 - **present:** It checks for the presence of kubernetes resource based on GVR and filters (field selectors/label selectors).
 - **absent:** It checks for the absence of kubernetes resource based on GVR and filters (field selectors/label selectors).
 
-## Where to define
+## Defining the probe
 
-The probes can be defined at **.spec.experiments[].spec.probe** path inside Chaos Engine.
+You can define the probes at **.spec.experiments[].spec.probe** path inside the chaos engine.
 
 ```yaml
 kind: Workflow
@@ -36,7 +36,7 @@ spec:
 
 ## Schema
 
-Probe schema for K8s Probe with common properties shared across all probes and properties unique to K8s probe.
+Listed below is the probe schema for the Kubernetes probe, with properties shared across all the probes and properties unique to the Kubernetes probe.
 
 <table>
   <tr>
@@ -137,9 +137,7 @@ Probe schema for K8s Probe with common properties shared across all probes and p
   </tr>
 </table>
 
-### Run Properties
-
-Probe run properties for K8s Probe.
+### Run properties
 
 <table>
   <tr>