Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update probes.md - runProperties timing types #259

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
54 changes: 27 additions & 27 deletions website/docs/concepts/probes.md
Original file line number Diff line number Diff line change
Expand Up @@ -25,8 +25,8 @@ These probes can be used in isolation or in several combinations to achieve the

The probes can be set up to run in different modes:

- **SoT**: Executed at the Start of Test as a pre-chaos check
- **EoT**: Executed at the End of Test as a post-chaos check
- **SOT**: Executed at the Start of Test as a pre-chaos check
- **EOT**: Executed at the End of Test as a post-chaos check
- **Edge**: Executed both, before and after the chaos
- **Continuous**: The probe is executed continuously, with a specified polling interval during the chaos injection.
- **OnChaos**: The probe is executed continuously, with a specified polling interval strictly for chaos duration of chaos
Expand All @@ -37,7 +37,7 @@ Some common attributes shared between the Probes:
- **retry**: The number of times a check is re-run upon failure in the first attempt before declaring the probe status as failed.
- **interval**: The period between subsequent retries
- **probePollingInterval**: The time interval for which continuous probe should be sleep after each iteration
- **initialDelaySeconds**: Represents the initial waiting time interval for the probes.
- **initialDelay**: Represents the initial waiting time interval for the probes.
- **stopOnFailure**: It can be set to true/false to stop or continue the fault execution after probe fails

:::note
Expand Down Expand Up @@ -73,10 +73,10 @@ probe:
responseCode: '<response code>'
mode: 'Continuous'
runProperties:
probeTimeout: 5
interval: 5
probeTimeout: 5s
interval: 5s
retry: 1
probePollingInterval: 2
probePollingInterval: 2s
```

The `httpProbe` is better used in the Continuous mode of operation as a parallel liveness indicator of a target or downstream application. It uses the `probePollingInterval` property to specify the polling interval for the access checks.
Expand Down Expand Up @@ -104,10 +104,10 @@ probe:
hostNetwork: false
mode: 'Edge'
runProperties:
probeTimeout: 5
interval: 5
probeTimeout: 5s
interval: 5s
retry: 1
initialDelaySeconds: 5
initialDelay: 5s
```

> `source.hostNetwork` can be set to `true` to allow access to the node network namespace for the pod executing the probe
Expand Down Expand Up @@ -137,8 +137,8 @@ probe:
operation: 'present' # it can be present, absent, create, delete
mode: 'EOT'
runProperties:
probeTimeout: 5
interval: 5
probeTimeout: 5s
interval: 5s
retry: 1
```

Expand All @@ -162,8 +162,8 @@ probe:
value: '<value-for-criteria-match>'
mode: 'Edge'
runProperties:
probeTimeout: 5
interval: 5
probeTimeout: 5s
interval: 5s
retry: 1
```

Expand Down Expand Up @@ -247,8 +247,8 @@ probe:
source: 'inline'
mode: 'SOT'
runProperties:
probeTimeout: 5
interval: 5
probeTimeout: 5s
interval: 5s
retry: 1
- name: 'probe2'
type: 'cmdProbe'
Expand All @@ -262,8 +262,8 @@ probe:
source: 'inline'
mode: 'SOT'
runProperties:
probeTimeout: 5
interval: 5
probeTimeout: 5s
interval: 5s
retry: 1
```

Expand Down Expand Up @@ -921,11 +921,11 @@ This section describes the different fields of the litmus probes and the possibl
</tr>
<tr>
<th>Range</th>
<td>n/a <code>type: integer</code></td>
<td>n/a <code>type: string</code></td>
</tr>
<tr>
<th>Notes</th>
<td>The <code>.runProperties.probeTimeout</code> represents the time limit for the probe to execute the specified check and return the expected data</td>
<td>The <code>.runProperties.probeTimeout</code> represents the time limit for the probe to execute the specified check and return the expected data. Examples: <code>5s</code>, <code>5m</code>, <code>1h</code></td>
</tr>
</table>

Expand Down Expand Up @@ -967,11 +967,11 @@ This section describes the different fields of the litmus probes and the possibl
</tr>
<tr>
<th>Range</th>
<td>n/a <code>type: integer</code></td>
<td>n/a <code>type: string</code></td>
</tr>
<tr>
<th>Notes</th>
<td>The <code>.runProperties.interval</code> contains the interval for which probes waits between subsequent retries</td>
<td>The <code>.runProperties.interval</code> contains the interval for which probes waits between subsequent retries. Examples: <code>5s</code>, <code>5m</code>, <code>1h</code></td>
</tr>
</table>

Expand All @@ -990,18 +990,18 @@ This section describes the different fields of the litmus probes and the possibl
</tr>
<tr>
<th>Range</th>
<td>n/a <code>type: integer</code></td>
<td>n/a <code>type: string</code></td>
</tr>
<tr>
<th>Notes</th>
<td>The <code>.runProperties.probePollingInterval</code> contains the time interval for which continuous probe should be sleep after each iteration</td>
<td>The <code>.runProperties.probePollingInterval</code> contains the time interval for which continuous probe should be sleep after each iteration. Examples: <code>5s</code>, <code>5m</code>, <code>1h</code></td>
</tr>
</table>

<table>
<tr>
<th>Field</th>
<td><code>.runProperties.initialDelaySeconds</code></td>
<td><code>.runProperties.initialDelay</code></td>
</tr>
<tr>
<th>Description</th>
Expand All @@ -1013,11 +1013,11 @@ This section describes the different fields of the litmus probes and the possibl
</tr>
<tr>
<th>Range</th>
<td>n/a <code>type: integer</code></td>
<td>n/a <code>type: string</code></td>
</tr>
<tr>
<th>Notes</th>
<td>The <code>.runProperties.initialDelaySeconds</code> represents the initial waiting time interval for the probes.</td>
<td>The <code>.runProperties.initialDelaySeconds</code> represents the initial waiting time interval for the probes. Examples: <code>5s</code>, <code>5m</code>, <code>1h</code></td>
</tr>
</table>

Expand Down Expand Up @@ -1119,7 +1119,7 @@ This section describes the different fields of the litmus probes and the possibl

Probes are pluggable checks that can be defined within the ChaosEngine for any Chaos Experiment. There are four kinds of probes `httpProbe` (allows developers to specify a URL which the fault uses to gauge health/service availability as part of the entry/exit criteria), `cmdProbe` (allows developers to run shell commands and match the resulting output as part of the entry/exit criteria), `k8sProbe` (addresses verification of the desired resource state by allowing users to define the Kubernetes GVR with appropriate filters) and `promProbe` (allows users to run Prometheus queries and match the resulting output against specific conditions).

The different modes these probes can be used in are `SoT`, `EoT`, `Edge`, `Continuous` and `OnChaos`. The litmus chaos faults run the probes defined in the ChaosEngine and update their stage-wise success in the ChaosResult custom resource with `probeSuccessPercentage`. A `probeSuccessPercentage` is the ratio of successful checks v/s total probes.
The different modes these probes can be used in are `SOT`, `EOT`, `Edge`, `Continuous` and `OnChaos`. The litmus chaos faults run the probes defined in the ChaosEngine and update their stage-wise success in the ChaosResult custom resource with `probeSuccessPercentage`. A `probeSuccessPercentage` is the ratio of successful checks v/s total probes.

Probes can be Chained, Probe chaining enables reuse of probe, the order of execution of probes in the fault depends purely on the order in which they are defined in the ChaosEngine.

Expand Down