Update to 4.19 via 6.8

.github/workflows/docs.yml

@@ -6,6 +6,7 @@ on:
       - "rhds"
       - "6.5"
       - "6.7"
+      - "6.8"
 env:
   SITE_DIR: "gh-pages"
 jobs:

documentation/modules/ROOT/pages/app-config.adoc

@@ -25,7 +25,7 @@ configuration files and command line arguments. These configuration artifacts
 should be externalized from the application and the container image content in
 order to keep the image portable across environments.
 
-OpenShift provides a mechanism called https://docs.openshift.com/container-platform/4.12/welcome/index.html[**ConfigMaps**^] 
+OpenShift provides a mechanism called https://docs.redhat.com/en/documentation/openshift_container_platform/4.19/html/nodes/working-with-pods#configmaps[**ConfigMaps**^] 
 in order to externalize configurations 
 from the applications deployed within containers and provide them to the containers 
 in a unified way as files and environment variables. OpenShift also offers a way to 
@@ -51,26 +51,27 @@ a persistent storage that survives the container itself. You can deploy database
 regardless of what happens to the container itself, the data is safe and can be used by the next 
 database container.
 
-Let's create a https://docs.openshift.com/container-platform/4.12/welcome/index.html[MariaDB database^] 
+Let's create a https://docs.redhat.com/en/documentation/openshift_container_platform/4.19/html/building_applications/creating-applications[MariaDB database^] 
 for the **Inventory Service** using the MariaDB template that is provided out-of-the-box:
 
 [TIP]
 ====
-https://docs.openshift.com/container-platform/4.12/openshift_images/using-templates.html[OpenShift Templates^] use YAML/JSON to compose 
+https://docs.redhat.com/en/documentation/openshift_container_platform/4.19/html/building_applications/creating-applications[OpenShift Templates^] use YAML/JSON to compose 
 multiple containers and their configurations as a list of objects to be created and deployed at once, 
 making it simple to re-create complex deployments by just deploying a single template. Templates can 
 be parameterized to get input for fields like service names and generate values for fields like passwords.
 ====
 
-In the OpenShift Web Console, `*click on '+Add' and select 'Database'*`
+In the OpenShift Web Console `*click on the 'Home' menu, and choose 'Software Catalog'*` 
+and then select `*Databases*` within the catalog.
 
-image::openshift-add-database.png[OpenShift - Add database, 700]
+image::openshift-add-database.png[OpenShift - Add database, 800]
 
 `*Select 'MariaDB (Ephemeral)' and click on 'Instantiate Template'*`
 
 Then, enter the following information:
 
-.Inventory Database
+.Inventory Database - MariaDB (Ephemeral)
 [%header,cols=2*]
 |===
 |Parameter 
@@ -109,12 +110,12 @@ Then, enter the following information:
 
 image::openshift-inventory-mariadb-topology.png[OpenShift - Inventory MariaDB, 700]
 
-`*Now click again on '+Add' and select 'Database', select 'PostgreSQL (Ephemeral)' and click on 'Instantiate Template'*` 
+Now select again from the `*'Software Catalog'*`, this time choose `*'PostgreSQL (Ephemeral)' and click on 'Instantiate Template'*` 
 to create the Catalog Database as follows:
 
 Then, enter the following information:
 
-.Catalog Database
+.Catalog Database - PostgreSQL (Ephemeral)
 [%header,cols=2*]
 |===
 |Parameter 
@@ -215,7 +216,7 @@ parameters unchanged. They will be overridden later.
 
 Now, let's create the Quarkus configuration content using the database credentials.
 
-In the OpenShift Web Console, from the **Developer view**,
+In the OpenShift Web Console from the `*Workloads*` menu
 `*click on 'Config Maps' then click on the 'Create Config Map' button*`.
 
 image::openshift-create-configmap.png[Che - OpenShift Create Config Map, 900]
@@ -317,7 +318,7 @@ configuration using an alternative **application.properties** backed by a config
 
 Let's create the Spring Boot configuration content using the database credentials and create the Config Map.
 
-In the OpenShift Web Console, from the **Developer view**,
+In the OpenShift Web Console, from the `*Workloads*` menu,
 `*click on 'Config Maps' then click on the 'Create Config Map' button*`.
 
 image::openshift-create-configmap.png[Che - OpenShift Create Config Map, 900]
@@ -429,7 +430,7 @@ credentials to simplify the steps; however, for production environments, you sho
 secure way to handle sensitive data.
 
 Fortunately, OpenShift already provides a secure mechanism for handling sensitive data which is 
-called https://docs.openshift.com/container-platform/4.12/welcome/index.html[**Secrets**^]. Secret objects act and are used 
+called https://docs.redhat.com/en/documentation/openshift_container_platform/4.19/html/nodes/working-with-pods#nodes-pods-secrets[**Secrets**^]. Secret objects act and are used 
 similarly to config maps however with the difference that they are encrypted as they travel over the wire 
 and also at rest when kept on a persistent disk. Like config maps, secrets can be injected into 
 containers as environment variables or files on the filesystem using a temporary file-storage 
@@ -471,9 +472,9 @@ This secret has three encrypted properties defined as **database-name**, **datab
 the PostgreSQL database name, username and password values. These values are injected in the PostgreSQL container as 
 environment variables and used to initialize the database.
 
-In the OpenShift Web Console, from the **Developer view**,
+In the {OPENSHIFT_CONSOLE_URL}[OpenShift Web Console^, role='params-link'], from the `*Workloads*` `*Topology*` menu,
 `*click on 'DC catalog-postgresql' -> 'DC catalog-postgresql' -> 'Environment'*`. Notice the values 
-from the secret are defined as env vars on the deployment:
+from the secret are defined as environment variables on the deployment:
 
 image::config-psql-secret.png[Secrets as Env Vars,900]
 
@@ -484,7 +485,7 @@ Having made all those changes with adding databases and the application configur
 test that the Coolstore application still works. Just like you did a couple of chapters ago you need to use the topology 
 display in the web console.
 
-In the OpenShift Web Console, from the **Developer view**,
+In the {OPENSHIFT_CONSOLE_URL}[OpenShift Web Console^, role='params-link'] from the `*Workloads*` `*Topology*` menu,
 `*click on the 'Open URL' icon of the Web Service*`
 
 image::openshift-web-topology.png[OpenShift - Web Topology, 700]

documentation/modules/ROOT/pages/app-health.adoc

@@ -26,7 +26,7 @@ Furthermore, there are of course a category of issues that can't be resolved by
 In those scenarios, OpenShift would remove the faulty container from the built-in load-balancer and send traffic 
 only to the healthy containers that remain.
 
-There are three types of health probes available in OpenShift: https://docs.openshift.com/container-platform/4.12/applications/application-health.html#application-health-about_application-health[startup, readiness and liveness probes^]. 
+There are three types of health probes available in OpenShift: https://docs.redhat.com/en/documentation/openshift_container_platform/4.19/html/building_applications/application-health[startup, readiness and liveness probes^]. 
 
 * **Startup probes** determine if the container in which it is scheduled is started
 * **Readiness probes** determine if the container in which it is scheduled is ready to service requests
@@ -38,7 +38,7 @@ order to remove downtime during deployments. A readiness health probe would sign
 traffic from the old version of the container to the new version so that the users don't get affected during 
 deployments.
 
-There are https://docs.openshift.com/container-platform/4.12/applications/application-health.html#application-health-about_types_application-health[three ways to define a health probe^] for a container:
+There are three ways to define a health probe for a container:
 
 * **HTTP Checks:** healthiness of the container is determined based on the response code of an HTTP 
 endpoint. Anything between 200 and 399 is considered success. A HTTP check is ideal for applications 
@@ -60,7 +60,7 @@ start listening until initialization is complete.
 By default Pods are designed to be resilient, if a pod dies it will get restarted. Let's see
 this happening.
 
-In the OpenShift Web Console, from the **Developer view**,
+In the OpenShift Web Console under the Workloads menu
 `*click on 'Topology' -> '(D) inventory-coolstore' -> 'Resources' -> 'P inventory-coolstore-x-xxxxx'*`
 
 image::openshift-inventory-pod.png[OpenShift Inventory Pod, 700]
@@ -129,7 +129,7 @@ image::che-inventory-traffic.png[Che - Catalog Traffic OK, 500]
 
 Now let's scale out your _Inventory Service_ to 2 instances. 
 
-In the OpenShift Web Console, from the **Developer view**,
+In the OpenShift Web Console under the Workloads menu,
 `*click on 'Topology' -> '(D) inventory-coolstore' -> 'Details' then click once on the up arrows 
 on the right side of the pod blue circle*`.
 
@@ -147,7 +147,7 @@ In order to prevent this behaviour, a **Readiness check** is needed. It determin
 If the readiness probe fails, the endpoints controller ensures the container has its IP address removed from the endpoints of all services. 
 A readiness probe can be used to signal to the endpoints controller that even though a container is running, it should not receive any traffic from a proxy.
 
-First, scale down your _Inventory Service_ to 1 instance. In the OpenShift Web Console, from the **Developer view**,
+First, scale down your _Inventory Service_ to 1 instance. In the OpenShift Web Console, under the Workloads menu,
 `*click on 'Topology' -> '(D) inventory-coolstore' -> 'Details' then click once on the down arrows 
 on the right side of the pod blue circle*`.
 
@@ -236,7 +236,7 @@ You should have the following output:
 }
 ----
 
-In the OpenShift Web Console, from the **Developer view**,
+In the In the OpenShift Web Console under the Workloads menu,
 `*click on 'Topology' -> '(D) inventory-coolstore' -> 'Add Health Checks'*`.
 
 image::openshift-inventory-add-health-check.png[Che - Inventory Add Health Check, 700]
@@ -330,8 +330,7 @@ Now repeat the same task for the *Inventory* service, but this time set the *Rea
 
 |===
 
-Finally `*click on the check icon and the 'Add' button*`. OpenShift automates deployments using 
-https://docs.openshift.com/container-platform/4.12/welcome/index.html[deployment triggers^] 
+Finally `*click on the check icon and the 'Add' button*`. OpenShift automates deployments using *deployment triggers* 
 that react to changes to the container image or configuration. 
 Therefore, as soon as you define the probe, OpenShift automatically redeploys the pod using the new configuration including the liveness probe.
 
@@ -378,7 +377,7 @@ You should have the following output:
 Liveness and Readiness health checks values have already been set for this service as part of the build and deploying 
 using Eclipse JKube in combination with the Spring Boot actuator. 
 
-You can check this in the OpenShift Web Console, from the **Developer view**,
+You can check this in the OpenShift Web Console, under the Workloads menu,
 `*click on 'Topology' -> '(D) catalog-coolstore' -> 'Actions' -> 'Edit Health Checks'*`.
 
 image::openshift-catalog-edit-health.png[Che - Catalog Add Health Check, 700]
@@ -490,18 +489,19 @@ gain visibility into how the application behaves and particularly in identifying
 
 OpenShift provides container metrics out-of-the-box and displays how much memory, cpu and network 
 each container has been consuming over time. 
+//
+//In the OpenShift Web Console
+//`*click on 'Observe' then select your 'my-project{USER_ID}' project*`.
+//
+//In the project overview, you can see the different **Resource Usage** sections. 
+//`*click on one graph to get more details*`.
+//
+//image::openshift-monitoring.png[OpenShift Monitoring,740]
+//
+From the Workloads menu, `*click on 'Topology' -> any Deployment (D) and click on the associated Pod (P)*`
+
+In the pod `*Metrics*` tab, you can see a more detailed view of the pod consumption.
 
-In the OpenShift Web Console, from the **Developer view**,
-`*click on 'Observe' then select your project*`.
-
-In the project overview, you can see the different **Resource Usage** sections. 
-`*click on one graph to get more details*`.
-
-image::openshift-monitoring.png[OpenShift Monitoring,740]
-
-From the **Developer view**, `*click on 'Topology' -> any Deployment (D) and click on the associated Pod (P)*`
-
-In the pod overview, you can see a more detailed view of the pod consumption.
 The graphs can be found under the Metrics heading, or Details in earlier versions of the OpenShift console.
 
 image::openshift-pod-details.png[OpenShift Pod Details,740]

documentation/modules/ROOT/pages/catalog-spring-boot.adoc

@@ -445,7 +445,7 @@ containers for the project.
 [#test_your_service]
 == Test your Service
 
-In the OpenShift Web Console, from the **Developer view**,
+In the OpenShift Web Console,
 `*click on the 'Open URL' icon of the Catalog Service*`
 
 image::openshift-catalog-topology.png[OpenShift - Catalog Topology, 700]

documentation/modules/ROOT/pages/developer-workspace.adoc

@@ -153,7 +153,7 @@ web proxies etc. If you are using a corporate device you may need to switch to a
 
 === I've been timed out or need to restart the workspace
 
-The workshop will take a few hours to complete all the way through, if you use the system continuosly throughout 
+The workshop will take a few hours to complete all the way through, if you use the system continously throughout 
 that period you will not see this issue.
 
 *Timed-out and wont reconnect*

documentation/modules/ROOT/pages/inventory-quarkus.adoc

@@ -471,7 +471,7 @@ it’s time to deploy your service on OpenShift using all that information in th
 we saw earlier.
 
 In this section you will locally build a .jar file, then *create* the OpenShift build and deployment components
-and *push* the .jar it to OpenShift. The OpenShift https://docs.openshift.com/container-platform/4.12/cicd/builds/understanding-image-builds.html[Source-to-Image (S2I)^] builder 
+and *push* the .jar it to OpenShift. The OpenShift https://docs.redhat.com/en/documentation/openshift_container_platform/4.19/html/builds_using_buildconfig/understanding-image-builds.html[Source-to-Image (S2I)^] builder 
 will then package the .jar file into a container and run it.
 
 [source,java,subs="{markup-in-source}"]
@@ -625,7 +625,7 @@ in one or more pods. A pod is the unit of runtime deployment and consists of the
 [#test_your_service]
 == Test your Service
 
-In the OpenShift Web Console, from the **Developer view**,
+In the OpenShift Web Console, 
 `*click on the 'Open URL' icon of the Inventory Service*`
 
 image::openshift-inventory-topology.png[OpenShift - Inventory Topology, 700]

documentation/modules/ROOT/pages/webui-deployment.adoc

@@ -39,16 +39,16 @@ The Web UI is built using Node.js for server-side JavaScript and AngularJS for c
 JavaScript. Let's deploy it on OpenShift using the certified Node.js container image available 
 in OpenShift. 
 
-In this lab, again you will use OpenShift https://docs.openshift.com/container-platform/4.12/cicd/builds/understanding-image-builds.html[Source-to-Image (S2I)^].
+In this lab, again you will use OpenShift https://docs.redhat.com/en/documentation/openshift_container_platform/4.19/html/builds_using_buildconfig/understanding-image-builds.html[Source-to-Image (S2I)^].
 OpenShift will obtain the application code directly from the source repository then build and deploy a 
 container image of it.
 
 For a change, rather than using the CLI option you will start this process from the web console.
 
-In the OpenShift Web Console, from the **Developer view**,
-`*click on '+Add' and select 'Import from Git'*`
+In the OpenShift Web Console,
+`*click on '(+)' and select 'Import from Git'*`
 
-image::openshift-add-from-git.png[OpenShift - Add from Git, 700]
+image::openshift-add-from-git.png[OpenShift - Add from Git, 800]
 
 Then, enter the following information:
 
@@ -100,7 +100,7 @@ the web application pod will not be ready until the blue ring goes dark blue.
 [#test_your_service]
 == Test your Service
 
-In the OpenShift Web Console, from the **Developer view**,
+In the OpenShift Web Console,
 `*click on the 'Open URL' icon of the Web Service*`
 
 image::openshift-web-topology.png[OpenShift - Web Topology, 700]

site.yml

@@ -10,7 +10,7 @@ content:
   sources:
     - url: git@github.com:redhat-scholars/inner-loop-guide.git
       tags: []
-      branches: ["rhds", "6.5", "6.7"]
+      branches: ["rhds", "6.5", "6.7", "6.8"]
       start_path: documentation
 
 asciidoc: