doc: provides descriptions of the volume, engine, and replica condition.

ref: longhorn/longhonr 8508

Signed-off-by: Jack Lin <jack.lin@suse.com>

content/docs/1.5.4/high-availability/recover-volume.md

@@ -27,7 +27,7 @@ The state of a volume can change to read-only when IO errors occur. IO errors ca
 - Network disconnection: Interrupted connection between the engine and replicas.
 - High disk latency: Significant delay in the transfer of data between a replica and the corresponding disk.
 
-Longhorn checks the state of the volume's global mount point every 10 seconds. When the volume's filesystem changes to read-only, Longhorn updates the condition to the volume's data engine. Longhorn then automatically attempts to remount the global mount point on the host to change the state back to read-write. Upon successful remounting, the workload pods continue functioning without disruption.
+Longhorn checks the state of the volume's global mount point every 10 seconds. When the volume's filesystem changes to read-only, Longhorn updates the condition to the volume's data engine. Longhorn then automatically attempts to remount the global mount point on the host to change the state back to read-write. Upon successful remounting, the workload pods continue functioning without disruption. However, if the mount point becomes write-protected and Longhorn fails to remount the mount point, you may still need to manually recreate the workload to force it reattach and remount the volume. 
 
 > **Note:**
 > This mechanism might not work in some situations. For example, when the volume's data engine crashes, Longhorn automatically detaches and reattaches the volume. The filesystem changes to read-only in this case. Longhorn will detect the read-only mode and update the state, but [Automatic Volume Remounting](#automatic-volume-remounting) cannot change it back to read-write because the device is now write-protected. In this case, you can only rely on the [Automatic Workload Pod Deletion](#automatic-workload-pod-deletion) mechanism, which enables volume remounting after the workload pod is recreated.

content/docs/1.5.5/high-availability/recover-volume.md

@@ -27,7 +27,7 @@ The state of a volume can change to read-only when IO errors occur. IO errors ca
 - Network disconnection: Interrupted connection between the engine and replicas.
 - High disk latency: Significant delay in the transfer of data between a replica and the corresponding disk.
 
-Longhorn checks the state of the volume's global mount point every 10 seconds. When the volume's filesystem changes to read-only, Longhorn updates the condition to the volume's data engine. Longhorn then automatically attempts to remount the global mount point on the host to change the state back to read-write. Upon successful remounting, the workload pods continue functioning without disruption.
+Longhorn checks the state of the volume's global mount point every 10 seconds. When the volume's filesystem changes to read-only, Longhorn updates the condition to the volume's data engine. Longhorn then automatically attempts to remount the global mount point on the host to change the state back to read-write. Upon successful remounting, the workload pods continue functioning without disruption. However, if the mount point becomes write-protected and Longhorn fails to remount the mount point, you may still need to manually recreate the workload to force it reattach and remount the volume. 
 
 > **Note:**
 > This mechanism might not work in some situations. For example, when the volume's data engine crashes, Longhorn automatically detaches and reattaches the volume. The filesystem changes to read-only in this case. Longhorn will detect the read-only mode and update the state, but [Automatic Volume Remounting](#automatic-volume-remounting) cannot change it back to read-write because the device is now write-protected. In this case, you can only rely on the [Automatic Workload Pod Deletion](#automatic-workload-pod-deletion) mechanism, which enables volume remounting after the workload pod is recreated.

content/docs/1.5.6/high-availability/recover-volume.md

@@ -27,7 +27,7 @@ The state of a volume can change to read-only when IO errors occur. IO errors ca
 - Network disconnection: Interrupted connection between the engine and replicas.
 - High disk latency: Significant delay in the transfer of data between a replica and the corresponding disk.
 
-Longhorn checks the state of the volume's global mount point every 10 seconds. When the volume's filesystem changes to read-only, Longhorn updates the condition to the volume's data engine. Longhorn then automatically attempts to remount the global mount point on the host to change the state back to read-write. Upon successful remounting, the workload pods continue functioning without disruption.
+Longhorn checks the state of the volume's global mount point every 10 seconds. When the volume's filesystem changes to read-only, Longhorn updates the condition to the volume's data engine. Longhorn then automatically attempts to remount the global mount point on the host to change the state back to read-write. Upon successful remounting, the workload pods continue functioning without disruption. However, if the mount point becomes write-protected and Longhorn fails to remount the mount point, you may still need to manually recreate the workload to force it reattach and remount the volume. 
 
 > **Note:**
 > This mechanism might not work in some situations. For example, when the volume's data engine crashes, Longhorn automatically detaches and reattaches the volume. The filesystem changes to read-only in this case. Longhorn will detect the read-only mode and update the state, but [Automatic Volume Remounting](#automatic-volume-remounting) cannot change it back to read-write because the device is now write-protected. In this case, you can only rely on the [Automatic Workload Pod Deletion](#automatic-workload-pod-deletion) mechanism, which enables volume remounting after the workload pod is recreated.

content/docs/1.6.0/high-availability/recover-volume.md

@@ -27,7 +27,7 @@ The state of a volume can change to read-only when IO errors occur. IO errors ca
 - Network disconnection: Interrupted connection between the engine and replicas.
 - High disk latency: Significant delay in the transfer of data between a replica and the corresponding disk.
 
-Longhorn checks the state of the volume's global mount point every 10 seconds. When the volume's filesystem changes to read-only, Longhorn updates the condition to the volume's data engine. Longhorn then automatically attempts to remount the global mount point on the host to change the state back to read-write. Upon successful remounting, the workload pods continue functioning without disruption.
+Longhorn checks the state of the volume's global mount point every 10 seconds. When the volume's filesystem changes to read-only, Longhorn updates the condition to the volume's data engine. Longhorn then automatically attempts to remount the global mount point on the host to change the state back to read-write. Upon successful remounting, the workload pods continue functioning without disruption. However, if the mount point becomes write-protected and Longhorn fails to remount the mount point, you may still need to manually recreate the workload to force it reattach and remount the volume. 
 
 > **Note:**
 > This mechanism might not work in some situations. For example, when the volume's data engine crashes, Longhorn automatically detaches and reattaches the volume. The filesystem changes to read-only in this case. Longhorn will detect the read-only mode and update the state, but [Automatic Volume Remounting](#automatic-volume-remounting) cannot change it back to read-write because the device is now write-protected. In this case, you can only rely on the [Automatic Workload Pod Deletion](#automatic-workload-pod-deletion) mechanism, which enables volume remounting after the workload pod is recreated.

content/docs/1.6.0/nodes-and-volumes/volumes/volume-conditions.md

@@ -0,0 +1,27 @@
+---
+title: Volume Conditions
+weight: 7
+---
+
+## Volume Conditions 
+
+Volume conditions describe the current status of a volume and potential issues that may occur.
+- `Scheduled`: All replicas were scheduled successfully. 
+    If Longhorn was unable to schedule any of the replicas, the condition is set to `false` and error messages are displayed. The condition is set to `true` when the setting [Allow Volume Creation With Degraded Availability](../../../references/settings#allow-volume-creation-with-degraded-availability) is enabled and at least one replica is scheduled.
+- `TooManySnapshots`: This specific volume has more than 100 snapshots.
+    Longhorn allows you to create a maximum of 250 snapshots for each volume. For more information about configuring the maximum snapshot count, see [Snapshot Space Management](../../../snapshots-and-backups/snapshot-space-management).
+- `Restore`: Longhorn is restoring the volume from a backup.
+- `WaitForBackingImage`: The replicas have not started because the backing images must first be synced with their disks.
+
+## Engine Conditions
+
+Engine conditions describe the current status of an engine and potential issues that may occur.
+`FilesystemReadOnly`: The state of the current volume mount point has changed to read-only. 
+This change may prevent workloads from writing data to the volume. For troubleshooting information, see [Volume Recovery](../../../high-availability/recover-volume).
+
+
+## Replica Conditions
+
+Replica conditions describe the current status of a replica and potential issues that may occur.
+- `RebuildFailed`: The replica failed to rebuild.
+- `WaitForBackingImage`: The replicas have not started because the backing images must first be synced with their disks.

content/docs/1.6.1/high-availability/recover-volume.md

@@ -27,7 +27,7 @@ The state of a volume can change to read-only when IO errors occur. IO errors ca
 - Network disconnection: Interrupted connection between the engine and replicas.
 - High disk latency: Significant delay in the transfer of data between a replica and the corresponding disk.
 
-Longhorn checks the state of the volume's global mount point every 10 seconds. When the volume's filesystem changes to read-only, Longhorn updates the condition to the volume's data engine. Longhorn then automatically attempts to remount the global mount point on the host to change the state back to read-write. Upon successful remounting, the workload pods continue functioning without disruption.
+Longhorn checks the state of the volume's global mount point every 10 seconds. When the volume's filesystem changes to read-only, Longhorn updates the condition to the volume's data engine. Longhorn then automatically attempts to remount the global mount point on the host to change the state back to read-write. Upon successful remounting, the workload pods continue functioning without disruption. However, if the mount point becomes write-protected and Longhorn fails to remount the mount point, you may still need to manually recreate the workload to force it reattach and remount the volume. 
 
 > **Note:**
 > This mechanism might not work in some situations. For example, when the volume's data engine crashes, Longhorn automatically detaches and reattaches the volume. The filesystem changes to read-only in this case. Longhorn will detect the read-only mode and update the state, but [Automatic Volume Remounting](#automatic-volume-remounting) cannot change it back to read-write because the device is now write-protected. In this case, you can only rely on the [Automatic Workload Pod Deletion](#automatic-workload-pod-deletion) mechanism, which enables volume remounting after the workload pod is recreated.

content/docs/1.6.1/nodes-and-volumes/volumes/volume-conditions.md

@@ -0,0 +1,27 @@
+---
+title: Volume Conditions
+weight: 7
+---
+
+## Volume Conditions 
+
+Volume conditions describe the current status of a volume and potential issues that may occur.
+- `Scheduled`: All replicas were scheduled successfully. 
+    If Longhorn was unable to schedule any of the replicas, the condition is set to `false` and error messages are displayed. The condition is set to `true` when the setting [Allow Volume Creation With Degraded Availability](../../../references/settings#allow-volume-creation-with-degraded-availability) is enabled and at least one replica is scheduled.
+- `TooManySnapshots`: This specific volume has more than 100 snapshots.
+    Longhorn allows you to create a maximum of 250 snapshots for each volume. For more information about configuring the maximum snapshot count, see [Snapshot Space Management](../../../snapshots-and-backups/snapshot-space-management).
+- `Restore`: Longhorn is restoring the volume from a backup.
+- `WaitForBackingImage`: The replicas have not started because the backing images must first be synced with their disks.
+
+## Engine Conditions
+
+Engine conditions describe the current status of an engine and potential issues that may occur.
+`FilesystemReadOnly`: The state of the current volume mount point has changed to read-only. 
+This change may prevent workloads from writing data to the volume. For troubleshooting information, see [Volume Recovery](../../../high-availability/recover-volume).
+
+
+## Replica Conditions
+
+Replica conditions describe the current status of a replica and potential issues that may occur.
+- `RebuildFailed`: The replica failed to rebuild.
+- `WaitForBackingImage`: The replicas have not started because the backing images must first be synced with their disks.

content/docs/1.6.2/high-availability/recover-volume.md

@@ -27,7 +27,7 @@ The state of a volume can change to read-only when IO errors occur. IO errors ca
 - Network disconnection: Interrupted connection between the engine and replicas.
 - High disk latency: Significant delay in the transfer of data between a replica and the corresponding disk.
 
-Longhorn checks the state of the volume's global mount point every 10 seconds. When the volume's filesystem changes to read-only, Longhorn updates the condition to the volume's data engine. Longhorn then automatically attempts to remount the global mount point on the host to change the state back to read-write. Upon successful remounting, the workload pods continue functioning without disruption.
+Longhorn checks the state of the volume's global mount point every 10 seconds. When the volume's filesystem changes to read-only, Longhorn updates the condition to the volume's data engine. Longhorn then automatically attempts to remount the global mount point on the host to change the state back to read-write. Upon successful remounting, the workload pods continue functioning without disruption. However, if the mount point becomes write-protected and Longhorn fails to remount the mount point, you may still need to manually recreate the workload to force it reattach and remount the volume. 
 
 > **Note:**
 > This mechanism might not work in some situations. For example, when the volume's data engine crashes, Longhorn automatically detaches and reattaches the volume. The filesystem changes to read-only in this case. Longhorn will detect the read-only mode and update the state, but [Automatic Volume Remounting](#automatic-volume-remounting) cannot change it back to read-write because the device is now write-protected. In this case, you can only rely on the [Automatic Workload Pod Deletion](#automatic-workload-pod-deletion) mechanism, which enables volume remounting after the workload pod is recreated.

content/docs/1.6.2/nodes-and-volumes/volumes/volume-conditions.md

@@ -0,0 +1,27 @@
+---
+title: Volume Conditions
+weight: 7
+---
+
+## Volume Conditions 
+
+Volume conditions describe the current status of a volume and potential issues that may occur.
+- `Scheduled`: All replicas were scheduled successfully. 
+    If Longhorn was unable to schedule any of the replicas, the condition is set to `false` and error messages are displayed. The condition is set to `true` when the setting [Allow Volume Creation With Degraded Availability](../../../references/settings#allow-volume-creation-with-degraded-availability) is enabled and at least one replica is scheduled.
+- `TooManySnapshots`: This specific volume has more than 100 snapshots.
+    Longhorn allows you to create a maximum of 250 snapshots for each volume. For more information about configuring the maximum snapshot count, see [Snapshot Space Management](../../../snapshots-and-backups/snapshot-space-management).
+- `Restore`: Longhorn is restoring the volume from a backup.
+- `WaitForBackingImage`: The replicas have not started because the backing images must first be synced with their disks.
+
+## Engine Conditions
+
+Engine conditions describe the current status of an engine and potential issues that may occur.
+`FilesystemReadOnly`: The state of the current volume mount point has changed to read-only. 
+This change may prevent workloads from writing data to the volume. For troubleshooting information, see [Volume Recovery](../../../high-availability/recover-volume).
+
+
+## Replica Conditions
+
+Replica conditions describe the current status of a replica and potential issues that may occur.
+- `RebuildFailed`: The replica failed to rebuild.
+- `WaitForBackingImage`: The replicas have not started because the backing images must first be synced with their disks.

content/docs/1.6.3/high-availability/recover-volume.md

@@ -27,7 +27,7 @@ The state of a volume can change to read-only when IO errors occur. IO errors ca
 - Network disconnection: Interrupted connection between the engine and replicas.
 - High disk latency: Significant delay in the transfer of data between a replica and the corresponding disk.
 
-Longhorn checks the state of the volume's global mount point every 10 seconds. When the volume's filesystem changes to read-only, Longhorn updates the condition to the volume's data engine. Longhorn then automatically attempts to remount the global mount point on the host to change the state back to read-write. Upon successful remounting, the workload pods continue functioning without disruption.
+Longhorn checks the state of the volume's global mount point every 10 seconds. When the volume's filesystem changes to read-only, Longhorn updates the condition to the volume's data engine. Longhorn then automatically attempts to remount the global mount point on the host to change the state back to read-write. Upon successful remounting, the workload pods continue functioning without disruption. However, if the mount point becomes write-protected and Longhorn fails to remount the mount point, you may still need to manually recreate the workload to force it reattach and remount the volume. 
 
 > **Note:**
 > This mechanism might not work in some situations. For example, when the volume's data engine crashes, Longhorn automatically detaches and reattaches the volume. The filesystem changes to read-only in this case. Longhorn will detect the read-only mode and update the state, but [Automatic Volume Remounting](#automatic-volume-remounting) cannot change it back to read-write because the device is now write-protected. In this case, you can only rely on the [Automatic Workload Pod Deletion](#automatic-workload-pod-deletion) mechanism, which enables volume remounting after the workload pod is recreated.