Validated Patterns

Deploying the Emerging Disease Detection pattern


  1. An OpenShift cluster (Go to the OpenShift console). Cluster must have a dynamic StorageClass to provision PersistentVolumes.

  2. A GitHub account (and a token for it with repositories permissions, to read from and write to your forks)

For installation tooling dependencies, see Patterns quick start.

The use of this pattern depends on having a Red Hat OpenShift cluster. In this version of the validated pattern there is no dedicated Hub / Edge cluster for the Emerging Disease Detection pattern. This single node pattern can be extend as a managed cluster(s) to a central hub.

If you do not have a running Red Hat OpenShift cluster you can start one on a public or private cloud by using Red Hat’s cloud service.


A number of utilities have been built by the validated patterns team to lower the barrier to entry for using the community or Red Hat Validated Patterns. To use these utilities you will need to export some environment variables for your cloud provider:


  1. Fork the emerging-disease-detection repo on GitHub. It is necessary to fork because your fork will be updated as part of the GitOps and DevOps processes.

  2. Clone the forked copy of this repository.

    git clone<your-username>/emerging-disease-detection.git
  3. Create a local copy of the Helm secrets values file that can safely include credentials


    You do not want to push credentials to GitHub.

    cp values-secret.yaml.template ~/values-secret.yaml
    vi ~/values-secret.yaml

values-secret.yaml example

  - name: rhpam
    - global
    - name: rhpam_api_passwd
      value: kieserver
    - name: sso_siteadmin_password
      value: r3dh4t1!
    - name: kie_admin_password
      value: admin
    - name: kieserver_user_password
      value: kieserver
    - name: psql_passwd
      value: rhpam

  - name: fhir-psql-db
    - global
    - name: psql_credentials_secret
      value: psql_secret
    - name: psql_user_name
      value: fhir
    - name: psql_user_passwd
      value: fhir

When you edit the file you can make changes to the various DB and Grafana passwords if you wish.

  1. Customize the values-global.yaml for your deployment

    git checkout -b my-branch
    vi values-global.yaml

Replace instances of PROVIDE_ with your specific configuration

  pattern: emerging-disease-detection
  hubClusterDomain: "AUTO" # this is for test only This value is automatically fetched when Invoking against a cluster

    useCSV: false
    syncPolicy: Automatic
    installPlanApproval: Automatic

  clusterGroupName: hub
    operatorChannel: gitops-1.9
   git add values-global.yaml
   git commit values-global.yaml
   git push origin my-branch
  1. You can deploy the pattern using the validated pattern operator. If you do use the operator then skip to Validating the Environment below.

  2. Preview the changes that will be made to the Helm charts.

    ./ make show
  3. Login to your cluster using oc login or exporting the KUBECONFIG

    oc login
    or set KUBECONFIG to the path to your kubeconfig file. For example
    export KUBECONFIG=~/my-ocp-env/auth/kubeconfig

Check the values files before deployment

You can run a check before deployment to make sure that you have the required variables to deploy the Emerging Disease Detection Validated Pattern.

You can run make predeploy to check your values. This will allow you to review your values and changed them in the case there are typos or old values. The values files that should be reviewed prior to deploying the Emerging Disease Detection Validated Pattern are:

Values FileDescription

values-secret.yaml / values-secret-emerging-disease-detection.yaml

This is the values file that will include the rhpam and fhir-psql-db sections with all database et al secrets


File that is used to contain all the global values used by Helm


  1. Apply the changes to your cluster

    ./ make install

    If the install fails and you go back over the instructions and see what was missed and change it, then run make update to continue the installation.

  2. This takes some time. Especially for the OpenShift Data Foundation operator components to install and synchronize. The make install provides some progress updates during the install. It can take up to twenty minutes. Compare your make install run progress with the following video showing a successful install.

  3. Check that the operators have been installed in the UI.

    1. To verify, in the OpenShift Container Platform web console, navigate to Operators → Installed Operators page.

    2. Check that the Operator is installed in the openshift-operators namespace and its status is Succeeded.

Using OpenShift GitOps to check on Application progress

You can also check on the progress using OpenShift GitOps to check on the various applications deployed.

  1. Obtain the ArgoCD URLs and passwords.

    The URLs and login credentials for ArgoCD change depending on the pattern name and the site names they control. Follow the instructions below to find them, however you choose to deploy the pattern.

    Display the fully qualified domain names, and matching login credentials, for all ArgoCD instances:

    ARGO_CMD=`oc get secrets -A -o jsonpath='{range .items[*]}{"oc get -n "}{.metadata.namespace}{" routes; oc -n "}{.metadata.namespace}{" extract secrets/"}{}{" --to=-\\n"}{end}' | grep gitops-cluster`
    CMD=`echo $ARGO_CMD | sed 's|- oc|-;oc|g'`
    eval $CMD

    The result should look something like:

    NAME                       HOST/PORT                                                                                      PATH   SERVICES                   PORT    TERMINATION            WILDCARD
    hub-gitops-server          hub-gitops-server   https   passthrough/Redirect   None
    # admin.password
    NAME                      HOST/PORT                                                                         PATH   SERVICES                  PORT    TERMINATION            WILDCARD
    cluster                                   cluster                   8080    reencrypt/Allow        None
    kam                                           kam                       8443    passthrough/None       None
    openshift-gitops-server          openshift-gitops-server   https   passthrough/Redirect   None
    # admin.password

    The most important ArgoCD instance to examine at this point is emerging-disease-detection-hub. This is where all the applications for the pattern can be tracked.

  2. Check all applications are synchronised. There are thirteen different ArgoCD "applications" deployed as part of this pattern.

Viewing the Sepsis Detection dashboard

TO-DO: Describe how to examine the various parts of the Sepsis application

Using the Emerging Disease Detection pattern

The following steps describes how you can use this pattern in a demo.

Viewing the Sepsis Detection dashboard

TO-DO: Describe how to examine the various parts of the Sepsis application