openshift/openshift-docs
1
0
Fork 0
mirror of https://github.com/openshift/openshift-docs.git synced 2026-02-05 12:46:18 +01:00
Code Issues Releases Activity

Merge pull request #83526 from openshift-cherrypick-robot/cherry-pick-83377-to-enterprise-4.18

Browse Source 
[enterprise-4.18] OSDOCS-11274:changing uppercase to lowercase for Greenboot
This commit is contained in:
Shauna Diaz
2024-10-15 11:13:01 -04:00
committed by GitHub
parent 61b620239b 5cd5850674
commit 46e24cc3e4
6 changed files with 21 additions and 21 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
microshift_configuring/microshift-greenboot-checking-status.adoc
View File

@@ -1,13 +1,13 @@
:_mod-docs-content-type: ASSEMBLY
[id="microshift-greenboot-checking-status"]
= Checking Greenboot scripts status
= Checking greenboot scripts status
include::_attributes/attributes-microshift.adoc[]
:context: microshift-greenboot-script-status
toc::[]
To deploy applications or make other changes through the {microshift-short} API with tools other than `kustomize` manifests, you must wait until the Greenboot health checks have finished. This ensures that your changes are not lost if Greenboot rolls your `rpm-ostree` system back to an earlier state.
To deploy applications or make other changes through the {microshift-short} API with tools other than `kustomize` manifests, you must wait until the greenboot health checks have finished. This ensures that your changes are not lost if greenboot rolls your `rpm-ostree` system back to an earlier state.
The `greenboot-healthcheck` service runs one time and then exits. After Greenboot has exited and the system is in a healthy state, you can proceed with configuration changes and deployments.
The `greenboot-healthcheck` service runs one time and then exits. After greenboot has exited and the system is in a healthy state, you can proceed with configuration changes and deployments.
include::modules/microshift-greenboot-check-status.adoc[leveloffset=+1]

2
microshift_running_apps/microshift-greenboot-workload-scripts.adoc
View File

@@ -21,5 +21,5 @@ include::modules/microshift-greenboot-testing-workload-script.adoc[leveloffset=+
[id="additional-resources_microshift-greenboot-workload-scripts_{context}"]
[role="_additional-resources"]
== Additional resources
* xref:../microshift_install_get_ready/microshift-greenboot.adoc#microshift-greenboot[The Greenboot health check]
* xref:../microshift_install_get_ready/microshift-greenboot.adoc#microshift-greenboot[The greenboot health check]
* xref:../microshift_running_apps/microshift-applications.adoc#microshift-applying-manifests-example_applications-microshift[Auto applying manifests]

8
modules/microshift-greenboot-check-status.adoc
View File

@@ -4,9 +4,9 @@
:_mod-docs-content-type: PROCEDURE
[id="microshift-greenboot-check-status_{context}"]
= Checking the status of Greenboot health checks
= Checking the status of greenboot health checks
Check the status of Greenboot health checks before making changes to the system or during troubleshooting. You can use any of the following commands to help you ensure that Greenboot scripts have finished running.
Check the status of greenboot health checks before making changes to the system or during troubleshooting. You can use any of the following commands to help you ensure that greenboot scripts have finished running.
.Procedure
@@ -17,8 +17,8 @@ Check the status of Greenboot health checks before making changes to the system
$ systemctl show --property=SubState --value greenboot-healthcheck.service
----
+
** An output of `start` means that Greenboot checks are still running.
** An output of `exited` means that checks have passed and Greenboot has exited. Greenboot runs the scripts in the `green.d` directory when the system is a healthy state.
** An output of `start` means that greenboot checks are still running.
** An output of `exited` means that checks have passed and greenboot has exited. Greenboot runs the scripts in the `green.d` directory when the system is a healthy state.
** An output of `failed` means that checks have not passed. Greenboot runs the scripts in `red.d` directory when the system is in this state and might restart the system.
* To see a report showing the numerical exit code of the service where `0` means success and non-zero values mean a failure occurred, use the following command:

4
modules/microshift-greenboot-create-health-check-script.adoc
View File

@@ -7,7 +7,7 @@
[id="microshift-greenboot-app-health-check-script_{context}"]
= How to create a health check script for your application
You can create workload or application health check scripts in the text editor of your choice using the example in this documentation. Save the scripts in the `/etc/greenboot/check/required.d` directory. When a script in the `/etc/greenboot/check/required.d` directory exits with an error, Greenboot triggers a reboot in an attempt to heal the system.
You can create workload or application health check scripts in the text editor of your choice using the example in this documentation. Save the scripts in the `/etc/greenboot/check/required.d` directory. When a script in the `/etc/greenboot/check/required.d` directory exits with an error, greenboot triggers a reboot in an attempt to heal the system.
[NOTE]
====
@@ -55,7 +55,7 @@ PODS_NS_LIST=(<user_workload_namespace1> <user_workload_namespace2>)
PODS_CT_LIST=(<user_workload_namespace1_pod_count> <user_workload_namespace2_pod_count>)
# Update these two lines with at least one namespace and the pod counts that are specific to your workloads. Use the kubernetes <namespace> where your workload is deployed.
# Set Greenboot to read and execute the workload health check functions library.
# Set greenboot to read and execute the workload health check functions library.
source /usr/share/microshift/functions/greenboot.sh
# Set the exit handler to log the exit status.

18
modules/microshift-greenboot-dir-structure.adoc
View File

@@ -4,15 +4,15 @@
:_mod-docs-content-type: CONCEPT
[id="microshift-greenboot-dir-structure_{context}"]
= How Greenboot uses directories to run scripts
= How greenboot uses directories to run scripts
Health check scripts run from four `/etc/greenboot` directories. These scripts run in alphabetical order. Keep this in mind when you configure the scripts for your workloads.
When the system starts, Greenboot runs the scripts in the `required.d` and `wanted.d` directories. Depending on the outcome of those scripts, Greenboot continues the startup or attempts a rollback as follows:
When the system starts, greenboot runs the scripts in the `required.d` and `wanted.d` directories. Depending on the outcome of those scripts, greenboot continues the startup or attempts a rollback as follows:
. System as expected: When all of the scripts in the `required.d` directory are successfully run, Greenboot runs any scripts present in the `/etc/greenboot/green.d` directory.
. System as expected: When all of the scripts in the `required.d` directory are successfully run, greenboot runs any scripts present in the `/etc/greenboot/green.d` directory.
. System trouble: If any of the scripts in the `required.d` directory fail, Greenboot runs any prerollback scripts present in the `red.d` directory, then restarts the system.
. System trouble: If any of the scripts in the `required.d` directory fail, greenboot runs any prerollback scripts present in the `red.d` directory, then restarts the system.
[NOTE]
====
@@ -26,19 +26,19 @@ Returning a nonzero exit code from any script means that script has failed. Gree
* `/etc/greenboot/check/required.d` contains the health checks that must not fail.
** If the scripts fail, Greenboot retries them three times by default. You can configure the number of retries in the `/etc/greenboot/greenboot.conf` file by setting the `GREENBOOT_MAX_BOOTS` parameter to the desired number of retries.
** If the scripts fail, greenboot retries them three times by default. You can configure the number of retries in the `/etc/greenboot/greenboot.conf` file by setting the `GREENBOOT_MAX_BOOTS` parameter to the desired number of retries.
** After all retries fail, Greenboot automatically initiates a rollback if one is available. If a rollback is not available, the system log output shows that manual intervention is required.
** After all retries fail, greenboot automatically initiates a rollback if one is available. If a rollback is not available, the system log output shows that manual intervention is required.
** The `40_microshift_running_check.sh` health check script for {microshift-short} is installed into this directory.
* `/etc/greenboot/check/wanted.d` contains health scripts that are allowed to fail without causing the system to be rolled back.
** If any of these scripts fail, Greenboot logs the failure but does not initiate a rollback.
** If any of these scripts fail, greenboot logs the failure but does not initiate a rollback.
* `/etc/greenboot/green.d` contains scripts that run after Greenboot has declared the start successful.
* `/etc/greenboot/green.d` contains scripts that run after greenboot has declared the start successful.
* `/etc/greenboot/red.d` contains scripts that run after Greenboot has declared the startup as failed, including the `40_microshift_pre_rollback.sh` prerollback script. This script is executed right before a system rollback. The script performs {microshift-short} pod and OVN-Kubernetes cleanup to avoid potential conflicts after the system is rolled back to a previous version.
* `/etc/greenboot/red.d` contains scripts that run after greenboot has declared the startup as failed, including the `40_microshift_pre_rollback.sh` prerollback script. This script is executed right before a system rollback. The script performs {microshift-short} pod and OVN-Kubernetes cleanup to avoid potential conflicts after the system is rolled back to a previous version.
[IMPORTANT]
====

4
modules/microshift-greenboot-testing-workload-script.adoc
View File

@@ -15,14 +15,14 @@
.Procedure
. To test that Greenboot is running a health check script file, reboot the host by running the following command:
. To test that greenboot is running a health check script file, reboot the host by running the following command:
+
[source,terminal]
----
$ sudo reboot
----
. Examine the output of Greenboot health checks by running the following command:
. Examine the output of greenboot health checks by running the following command:
+
[source,terminal]
----