Probe review

Signed-off-by: Smriti S <smriti.satyanarayana@harness.io>

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 you to specify a URL that the experiment uses to gauge the health or service availability (or other custom conditions) as 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.
+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.
 
-The HTTP Get method sends a HTTP `GET` request to the provided URL. The response code received is matched  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>

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

@@ -3,15 +3,15 @@ title: Prometheus Probe
 sidebar_position: 6
 ---
 
-The Prometheus Probe 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. A PromQL query needs to be provided, whose outcome is then used for the probe validation.
+Prometheus probe 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. A PromQL query needs to be provided, whose outcome is then used for the probe validation.
 
-:::info YAML Only Feature
+:::info YAML only feature
 In 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](https://docs.litmuschaos.io/docs/concepts/chaos-engine) or the [ChaosExperiment](https://docs.litmuschaos.io/docs/concepts/chaos-experiment) CR. Also, `query` and `queryPath` attributes are mutually exclusive. Refer to the probe schema [here](https://docs.litmuschaos.io/docs/concepts/probes#promprobe).
 :::
 
-## 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
@@ -35,7 +35,7 @@ spec:
 
 ## Schema
 
-Probe schema for PROM Probe with common properties shared across all probes and properties unique to PROM probe.
+Listed below is the probe schema for the Prometheus probe, with properties shared across all the probes and properties unique to the Prometheus probe.
 
 <table>
   <tr>
@@ -126,8 +126,6 @@ Probe schema for PROM Probe with common properties shared across all probes and
 
 ### Comparator
 
-Comparator details for Prometheus Probe.
-
 <table>
   <tr>
    <td><strong>Field</strong>
@@ -179,9 +177,7 @@ Comparator details for Prometheus Probe.
   </tr>
 </table>
 
-### Run Properties
-
-Probe run properties for PROM Probe.
+### Run properties
 
 <table>
   <tr>