Chapter 5. Migration of Applications from JBoss EAP Imagestreams on OpenShift 4 to eap73 Imagestreams

Applications developed for the eap71 and eap72 imagestreams require changes to function correctly in the eap73 imagestream.

5.1. Updates to Liveness and Readiness Probe Configuration for eap73 Imagestreams

The YAML configuration of probes must be adjusted when migrating from the eap72 image running on OpenShift 3.11 to any eap73 image.

On the eap72 image, the default YAML configuration for a liveness probe is similar to the following code example:

Example YAML Configuration for eap72 Image on OpenShift 3.11 Liveness Probe

livenessProbe:
        exec:
          command:
            - /bin/bash
            - '-c'
            - /opt/eap/bin/livenessProbe.sh
        initialDelaySeconds: 60
        periodSeconds: 10
        successThreshold: 1
        failureThreshold: 3

In this example, the liveness probe is located at /opt/eap/bin/livenessProbe.sh within the JBoss EAP image. The probe is triggered the first time after a 60 second initial delay and then every 10 seconds after a pod is started on the JBoss EAP server.

After three unsuccessful probes, the container is deemed unhealthy and OpenShift restarts the container in its pod.

On the eap72 image, a single call lasts 5 seconds before it returns as a success or failure. The call is followed by a 10 second waiting period. This means that 3 calls last approximately 35 seconds before the container inside the pod is restarted if the JBoss EAP image is unhealthy.

On any eap73 image, a single call lasts less than 1 second. Three calls last approximately 23 seconds. The configuration of the probe for eap73 images should be adjusted in the YAML configuration as follows:

Example YAML Configuration for any eap73 Imagestream Liveness Probe

livenessProbe:
        exec:
          command:
            - /bin/bash
            - '-c'
            - /opt/eap/bin/livenessProbe.sh
        initialDelaySeconds: 60
        periodSeconds: 16
        successThreshold: 1
        failureThreshold: 3

In this example, periodSeconds has been increased by 6 seconds. Now the first call lasts 1 second, followed by a 16 second waiting period. Three calls would last approximately 34 seconds, which is nearly equivalent to the eap72 image behavior of the probe.

In the readiness probe, update periodSeconds in the YAML configuration with a similar value.

Example YAML Configuration for any eap73 Imagestream Readiness Probe

readinessProbe:
        exec:
          command:
            - /bin/bash
            - '-c'
            - /opt/eap/bin/readinessProbe.sh
        initialDelaySeconds: 10
        periodSeconds: 16
        successThreshold: 1
        failureThreshold: 3

Additional Resources

Monitoring Container Health on OpenShift 4

Liveness and Readiness Probes on OpenShift 3.11

5.2. Default Datasource Removed

In JBoss EAP 7.3, the default datasource is removed from JBoss EAP imagestreams.

If you developed custom applications that use the default datasource, you can include it when provisioning a server. Use the ENABLE_GENERATE_DEFAULT_DATASOURCE environment variable with a value of true. 

ENABLE_GENERATE_DEFAULT_DATASOURCE=true

5.3. Updates to standalone-openshift.xml when upgrading JBoss EAP 7.1 to JBoss EAP 7.3 on OpenShift

The configuration file standalone-openshift.xml installed with JBoss EAP 7.1 is not compatible with JBoss EAP 7.3 and later.

If you want to use the standalone-openshift.xml file after upgrading from JBoss EAP 7.1 to JBoss EAP 7.3, you must make the following changes to the file:

  • Update the version of the logging subsystem.

    Replace 

    <subsystem xmlns="urn:jboss:domain:logging:3.0">

    with 

    <subsystem xmlns="urn:jboss:domain:logging:8.0">

  • Update the log formatter in the logging subsystem configuration.

    Replace 

    <custom-formatter module="org.jboss.logmanager.ext" class="org.jboss.logmanager.ext.formatters.LogstashFormatter">
    <properties>
        <property name="metaData" value="log-handler=CONSOLE"/>
    </properties>
</custom-formatter>

    with 

    <json-formatter>
    <exception-output-type value="formatted"/>
    <key-overrides timestamp="@timestamp"/>
    <meta-data>
        <property name="@version" value="1"/>
    </meta-data>
</json-formatter>