Health checks flow

applications/application-health.adoc

@@ -18,4 +18,14 @@ include::modules/application-health-about.adoc[leveloffset=+1]
 
 include::modules/application-health-configuring.adoc[leveloffset=+1]
 
+include::modules/odc-monitoring-application-health-using-developer-perspective.adoc[leveloffset=+1]
 
+include::modules/odc-adding-health-checks.adoc[leveloffset=+1]
+
+include::modules/odc-editing-health-checks.adoc[leveloffset=+1]
+
+include::modules/odc-monitoring-health-checks.adoc[leveloffset=+1]
+
+.Additional Resources
+* For details on switching to the *Developer* perspective in the web console, see xref:../web_console/odc-about-developer-perspective.adoc#odc-about-developer-perspective[About *Developer* perspective].
+* For details on adding health checks while creating and deploying an application, see *Advanced Options* in the xref:../applications/application_life_cycle_management/odc-creating-applications-using-developer-perspective.adoc#odc-creating-applications-using-developer-perspective[Creating applications using the Developer perspective] section.

modules/application-health-configuring.adoc

@@ -3,7 +3,7 @@
 // * nodes/application-health.adoc
 
 [id="application-health-configuring_{context}"]
-= Configuring health checks
+= Configuring health checks using the CLI
 
 To configure health checks, create a pod for each type of check you want.
 
@@ -57,7 +57,7 @@ Events:
 [NOTE]
 ====
 The `timeoutSeconds` parameter has no effect on the Readiness and Liveness
-probes for Container Execution Checks. You can implement a timeout 
+probes for Container Execution Checks. You can implement a timeout
 inside the probe itself, as {product-title} cannot time out on an exec call into
 the container. One way to implement a timeout in a probe is by using the `timeout` parameter to run your
 liveness or readiness probe:
@@ -122,7 +122,7 @@ spec:
 $ oc create -f <file-name>.yaml
 ----
 
-. Create an Readiness HTTP Check: 
+. Create an Readiness HTTP Check:
 
 .. Create a YAML file similar to the following:
 +
@@ -139,10 +139,10 @@ spec:
   - args:
     image: k8s.gcr.io/readiness <1>
     readinessProbe: <2>
-    httpGet:  
+    httpGet:
     # host: my-host <3>
     # scheme: HTTPS <4>
-      path: /healthz 
+      path: /healthz
       port: 8080
     initialDelaySeconds: 15  <5>
     timeoutSeconds: 1  <6>
@@ -152,7 +152,7 @@ spec:
 <3> Specify a host IP address. When `host` is not defined, the `PodIP` is used.
 <4> Specify `HTTP` or `HTTPS`. When `scheme` is not defined, the `HTTP` scheme is used.
 <5> Specify the number of seconds before performing the first probe after the container starts.
-<6> Specify the number of seconds between probes. 
+<6> Specify the number of seconds between probes.
 
 .. Create the check:
 +

modules/odc-adding-health-checks.adoc

@@ -0,0 +1,27 @@
+Pod// Module included in the following assemblies:
+//
+// applications/application-health
+
+[id="odc-adding-health-checks"]
+= Adding health checks using the Developer perspective
+
+You can use the *Topology* view to add health checks to your deployed application.
+
+.Prerequisites:
+* You have switched to the *Developer* perspective in the web console.
+* You have created and deployed an application on {product-title} using the *Developer* perspective.
+
+.Procedure
+. In the *Topology* view, click on the application node to see the side panel. If the container does not have health checks added to ensure the smooth running of your application, a *Health Checks* notification is displayed with a link to add health checks.
+. In the displayed notification, click the *Add Health Checks* link.
+. Alternatively, you can also click the *Actions* drop-down list and select *Add Health Checks*. Note that if the container already has health checks, you will see the *Edit Health Checks* option instead of the add option.
+. In the *Add Health Checks* form, if you have deployed multiple containers, use the *Container* drop-down list to ensure that the appropriate container is selected.
+. Click the required health probe links to add them to the container. Default data for the health checks is prepopulated. You can add the probes with the default data or further customize the values and then add them. For example, to add a Readiness probe that checks if your container is ready to handle requests:
+.. Click *Add Readiness Probe*, to see a form containing the parameters for the probe.
+.. Click the *Type* drop-down list to select the request type you want to add. For example, in this case, select *Container Command* to select the command that will be executed inside the container.
+.. In the *Command* field, add an argument `cat`, similarly, you can add multiple arguments for the check, for example, add another argument `/tmp/healthy`.
+.. Retain or modify the default values for the other parameters as required, and click the check mark at the bottom of the form. The *Readiness Probe Added* message is displayed.
+. Click *Add* to add the health check. You are redirected to the *Topology* view and the container is restarted.
+. In the side panel, verify that the probes have been added by clicking on the deployed Pod under the *Pods* section.
+. In the *Pod Details* page, click the listed container in the *Containers* section.
+. In the *Container Details* page, verify that the Readiness probe - *Exec Command* `cat` `/tmp/healthy` has been added to the container.

modules/odc-editing-health-checks.adoc

@@ -0,0 +1,32 @@
+// Module included in the following assemblies:
+//
+// applications/application-health
+
+[id="odc-editing-health-checks"]
+= Editing health checks using the Developer perspective
+
+You can use the *Topology* view to edit health checks added to your application, modify them, or add more health checks.
+
+.Prerequisites:
+* You have switched to the *Developer* perspective in the web console.
+* You have created and deployed an application on {product-title} using the *Developer* perspective.
+* You have added health checks to your application.
+
+.Procedure
+. In the *Topology* view, right-click your application and select *Edit Health Checks*. Alternatively, in the side panel, click the *Actions* drop-down list and select *Edit Health Checks*.
+. In the *Edit Health Checks* page:
+
+* To remove a previously added health probe, click the minus sign adjoining it.
+* To edit the parameters of an existing probe:
++
+.. Click the *Edit Probe* link next to a previously added probe to see the parameters for the probe.
+.. Modify the parameters as required, and click the check mark to save your changes.
++
+* To add a new health probe, in addition to existing health checks, click the add probe links. For example, to add a Liveness probe that checks if your container is running:
++
+.. Click *Add Liveness Probe*, to see a form containing the parameters for the probe.
+.. Edit the probe parameters as required, and click the check mark at the bottom of the form. The *Liveness Probe Added* message is displayed.
+. Click *Save* to save your modifications and add the additional probes to your container. You are redirected to the *Topology* view.
+. In the side panel, verify that the probes have been added by clicking on the deployed Pod under the *Pods* section.
+. In the *Pod Details* page, click the listed container in the *Containers* section.
+. In the *Container Details* page, verify that the Liveness probe - `HTTP Get 10.129.4.65:8080/` has been added to the container, in addition to the earlier existing probes.

modules/odc-importing-codebase-from-git-to-create-application.adoc

@@ -5,7 +5,7 @@
 [id="odc-importing-codebase-from-git-to-create-application_{context}"]
 = Importing a codebase from Git to create an application
 
-The following procedure walks you through the *Import from Git* option in the *Developer* perspective to create an application.
+The following procedure walks you through the *From Git* option in the *Developer* perspective to create an application.
 
 Create, build, and deploy an application on {product-title} using an existing codebase in GitHub as follows:
 
@@ -22,10 +22,11 @@ image::odc_import_from_git.png[Import from Git]
 * *Context Dir* to specify the subdirectory for the application source code you want to use to build the application.
 * *Source Secret* to create a *Secret Name* with credentials for pulling your source code from a private repository.
 
-. In the *Builder* section, after the URL is validated, an appropriate builder image is detected, indicated by a star, and automatically selected. For the `https://github.com/sclorg/nodejs-ex` Git URL, the Node.js builder image is selected by default. If required, you can change the version using the *Builder Image Version* drop-down list.
+. In the *Builder* section, after the URL is validated, an appropriate builder image is detected, indicated by a star, and automatically selected. For the `https://github.com/sclorg/nodejs-ex` Git URL, the Node.js builder image is selected by default. If a builder image is not auto-detected, select a builder image. If required, you can change the version using the *Builder Image Version* drop-down list.
+
 . In the *General* section:
 .. In the *Application* field, enter a unique name for the application grouping, for example, `myapp`. Ensure that the application name is unique in a namespace.
-.. The *Name* field to identify the resources created for this application is automatically populated based on the Git repository URL.
+.. The *Name* field to identify the resources created for this application is automatically populated based on the Git repository URL if there are no existing applications. If there are existing applications, you can choose to deploy the component within an existing application, create a new application, or keep the component unassigned.
 +
 [NOTE]
 ====
@@ -56,8 +57,22 @@ Click the *Routing* link to:
 +
 For serverless applications, the Knative Service manages all the routing options above. However, you can customize the target port for traffic, if required. If the target port is not specified, the default port of `8080` is used.
 
-Build and Deployment Configuration::
-Click the *Build Configuration* and *Deployment Configuration* links to see the respective configuration options. Some of the options are selected by default; you can customize them further by adding the necessary triggers and environment variables. For serverless applications, the *Deployment Configuration* option is not displayed as the Knative configuration resource maintains the desired state for your deployment instead of a DeploymentConfig.
+Health Checks::
+Click the *Health Checks* link to add Readiness, Liveness, and Startup probes to your application. All the probes have prepopulated default data; you can add the probes with the default data or customize it as required.
++
+To customize the health probes:
++
+* Click *Add Readiness Probe*, if required, modify the parameters to check if the container is ready to handle requests, and select the check mark to add the probe.
+* Click *Add Liveness Probe*, if required, modify the parameters to check if a container is still running, and select the check mark to add the probe.
+* Click *Add Startup Probe*, if required, modify the parameters to check if the application within the container has started, and select the check mark to add the probe.
++
+For each of the probes, you can specify the request type - *HTTP GET*, *Container Command*, or *TCP Socket*,  from the drop-down list. The form changes as per the selected request type. You can then modify the default values for the other parameters, such as the success and failure thresholds for the probe, number of seconds before performing the first probe after the container starts, frequency of the probe, and the timeout value.
+
+
+Build Configuration and Deployment::
+Click the *Build Configuration* and *Deployment* links to see the respective configuration options. Some options are selected by default; you can customize them further by adding the necessary triggers and environment variables.
++
+For serverless applications, the *Deployment* option is not displayed as the Knative configuration resource maintains the desired state for your deployment instead of a DeploymentConfig.
 
 Scaling::
 Click the *Scaling* link to define the number of Pods or instances of the application you want to deploy initially.

modules/odc-monitoring-application-health-using-developer-perspective.adoc

@@ -0,0 +1,14 @@
+// Module included in the following assemblies:
+//
+// applications/application-health
+
+[id="odc-monitoring-application-health-using-developer-perspective"]
+= Monitoring application health using the Developer perspective
+
+You can use the *Developer* perspective to add three types of health probes to your container to ensure that your application is healthy:
+
+* Use the Readiness probe to check if the container is ready to handle requests.
+* Use the Liveness probe to check if the container is running.
+* Use the Startup probe to check if the application within the container has started.
+
+You can add health checks either while creating and deploying an application, or after you have deployed an application.

modules/odc-monitoring-health-checks.adoc

@@ -0,0 +1,18 @@
+// Module included in the following assemblies:
+//
+// applications/application-health
+
+[id="odc-monitoring-health-checks"]
+= Monitoring health check failures using the Developer perspective
+
+In case an application health check fails, you can use the *Topology* view to monitor these health check violations.
+
+.Prerequisites:
+* You have switched to the *Developer* perspective in the web console.
+* You have created and deployed an application on {product-title} using the *Developer* perspective.
+* You have added health checks to your application.
+
+.Procedure
+. In the *Topology* view, click on the application node to see the side panel.
+. Click the *Monitoring* tab to see the health check failures in the *Events (Warning)* section.
+. Click the down arrow adjoining *Events (Warning)* to see the details of the health check failure.