Demonstrating Industrial Edge example applications

Background

Up until now the Industrial Edge 2.0 validated patterns has focused primarily on successfully deploying the architectural pattern. Now it is time to see GitOps and DevOps in action as we go through a number of demonstrations to change both configuration information and the applications that we are deploying.

If you have already deployed the data center and optionally a factory (edge) cluster, then you have already seen several applications deployed in the OpenShift GitOps console.

Prerequisite preparation

OpenShift Cluster

Make sure you have the kubeadmin administrator login for the data center cluster. Use this or the kubeconfig (export the path) to provide administrator access to your data center and factory/edge clusters.

Configuration changes with GitOps

There will may be times where you need to change the configuration of some of the edge devices in one or more of your factories. In our example, we have various sensors at the factory. Modification can be made to these sensors using ConfigMaps.

In this demonstration we will turn on a temperature sensor for sensor #2. We will first do this in the data center because this will demonstrate the power of GitOps without having to involve the edge/factory. However if you do have an factory joined using Advanced Cluster Management, then the changes will make their way out to the factory. But it is not necessary for the demo as we have a complete test environment on the data center.

Make sure you are able to see the dashboard application in a tab on your browser. You can find the URL for the dashboard application by looking at the following in your OpenShift console.

Select Networking->Routes on the left-hand side of the console. Using the Projects pull-down, select manuela-tst-all. Click on the URL under the Location column for the route Name line-dashboard. this will launch the line-dashboard monitoring application in a browser tab. The URL will look like:

line-dashboard-manuela-tst-all.apps.*cluster-name*.*domain*

Once the the application is open in your browser, click on the “Realtime Data” Navigation on the left and wait a bit. Data should be visualized as received. Note that there is only vibration data shown! If you wait a bit more (usually every 2-3 minutes), you will see an anomaly and alert on it.

Now let’s turn on the temperature sensor. Go to the gitea link on the nine box login using the gitea_admin user and the autogenerated password that can be found in the secret called gitea-admin-secret in the vp-gitea namespace:

You can run the following command to obtain the gitea user’s password automatically:

oc extract -n vp-gitea secret/gitea-admin-secret --to=- --keys=password 2>/dev/null

In the industrial-edge repository, edit the file called charts/datacenter/manuela-tst/templates/machine-sensor/machine-sensor-2-configmap.yaml and change SENSOR_TEMPERATURE_ENABLED: "false" to SENSOR_TEMPERATURE_ENABLED: "true".

Then change and commit this to your git repository so that the change will be picked up by OpenShift GitOps (ArgoCD).

You can track the progress of this commit/push in your OpenShift GitOps console in the manuela-test-all application. You will notice components regarding machine-sensor-2 getting sync-ed. You can speed this up by manually pressing the Refresh button.

The dashboard app should pickup the change automatically, once data from the temperature sensor is received. Sometimes a page/tab refreshed is needed for the change to be picked up.

Application changes using DevOps

The line-dashboard application has temperature sensors. In this demonstration we are going to make a simple change to that application, rebuild and redeploy it. In the manuela-dev repository there is a file components/iot-frontend/src/app/app.component.html. Let’s change the <ion-title>IoT Dashboard</ion-title> to something else, say, <ion-title>IoT Dashboard - DEVOPS was here!</ion-title>. We do this in the gitea web interface directly clicking on the editing icon for the file:

We can now kick off the pipeline called build-and-test-iot-frontend that will do the following:

1. Rebuild the image from the manuela-dev code
2. Push the change on the hub datacenter in the manuela-tst-all namespace
3. Create a PR in gitea

To start the pipeline run we can just run the following command from our terminal:

make build-and-test-iot-frontend

The pipeline will look a bit like the following:

After the pipeline completed the manuela-test application in Argo will eventually refresh and push the changes to the cluster and the line dash board route in the manuela-tst-all namespace will have picked up the changes:

The pipeline will also have created a PR in gitea, like the following one:

Now an operator can verify that the change is correct on the datacenter in the manuela-tst-all line dashboard and if deemed correct, he can merge the PR in gitea which will roll out the change to the production factory!

Application AI model changes with DevOps

On the OpenShift console click on the nine-box and choose Red Hat OpenShift AI. You’ll be taken to the AI console which will look like the following:

Click on Data Science Projects on the left sidebar and choose the ml-development project. You’ll be taken to the project which will contain a couple of workbenches and a model:

Clicking on the JupyterLab workbench you’ll be taken to the notebook where data analysis for this pattern is being done. The manuela-dev code will be preloaded in the notebook and you can click on the left file browser on manuela-dev/ml-models/anomaly-detection/1-preprocessing.ipynb:

After opening the notebook successfully, walk through the demonstration by pressing play and iterating through the commands in the playbook. Jupyter playbooks are interactive and you may make changes and also save those changes.

Running through all the six notebooks will automatically regenerate the anomaly model, prepare the data for the training and push the changes to the internal gitea so the inference service can pick up the new model.