Troubleshooting issues

You can find information about the issues or problems that you might encounter while working with Rational® Test Automation Server. Details about issues, their causes and the resolutions that you can apply to fix the issues are described.

The troubleshooting issues are presented to you in the following tables based on where or when you might encounter these issues on Rational® Test Automation Server.
Table 1. Troubleshooting issues: installation




When you are installing the server software and you encounter errors in the scripts that are running.

At times, scripts might not appear to be running due to any of the following reasons:
  • Slow connection speeds.
  • Insufficient CPU, memory, or disk resources.
  • A firewall that was configured incorrectly is already enabled.
You can complete any of the following tasks:
  • To identify the issue, you can perform a diagnostic check by running the following command:microk8s.inspect
  • Run the following command to see what is not running:kubectl get pods -ARun the following command to get details about the pods: kubectl describe pod
  • Follow the on-screen instructions to resolve the errors.
  • Some issues can be solved by re-running the following

The DNS is not working as expected.

You can change the nameservers by using the following command:kubectl edit cm coredns -n kube-system

The changes are applied when you restart the coredns pod.

If you are unsure of how to do this you can run the following script that helps you manage the DNS settings:

Table 2. Troubleshooting issues: server administration




Less recently patched versions of OpenShift can give errors when ever OpenShift performs internal checks.

For example, the following error is displayed:
ValidationError( missing required field "weight"

The errors are caused because OpenShift performs the internal checks that are invalid.

Apply the latest OpenShift patches when they become available.

If you do not want to apply the patches or cannot apply the patches, you can disable these checks in OpenShift by appending the following option to the helm command:


If your user-realm role is changed when you are logged in a session, the changed role is not applied immediately or even after the browser is refreshed.

You must log out of the session and log in again for the changed role to take effect.

Table 3. Troubleshooting issues: resource monitoring




You are not able to add a Prometheus server as a Resource Monitoring source.

The cause might be that you have not installed the Prometheus server at the time of server installation.

Verify that the Prometheus server was installed in Helm at the time of server installation. See Installing the server software on Ubuntu using microk8s. If not, consult your cluster administrator to get the Promethues server installed and configured.

Table 4. Troubleshooting issues: test or stub runs




When you run tests and you encounter any of the following issues:
  • Out of memory errors.
  • Observe that the test runs are slow with a high CPU usage.

The issue is seen when the memory that is used by the particular test during the test run exceeds the allocated default memory of 3 GB.

You can increase the memory usage for the test run in any of following ways:
  • Specifying a maximum heap size for the test run.
  • Specifying the container memory limit explicitly for the test run.
You can set the heap size or set the memory limit by performing the following steps when you configure the test run:
  1. Click Advanced in the Execute test asset dialog box.
  2. Enter any of the following arguments in the Java Arguments field:
    • -Xmx4g

      Configuring this argument enables the allotted 3 GB memory to be increased to 4 GB.

    • -Dexecution.resource.memory.limit=<custom_memory_value>Gi
      Note: You must enter the value for the memory limit that you want in <custom_memory_value>.

      For example, if you want to set the memory limit to 5 GB, the argument can be: -Dexecution.resource.memory.limit=5Gi. The argument enables the memory to be set to 5 GB and overrides the default memory size.

  3. Configure the other settings for the test run and run the test.
Important: The memory settings that you configure for a test run is persisted for the test when ever you run it. You must use this setting judiciously. Configuring all tests for an increased memory limit might affect subsequent test runs or cause other memory issues when tests run simultaneously.

You are not able to run the Istio stubs from the Execution page.

The cause might be that you have not enabled the service visualization via Istio at the time of server installation. The default configuration does not enable service virtualization via Istio.

Contact your cluster administrator or if you have the privileges, configure Helm as follows:

  • For Multi-tenant clusters

    If the cluster is shared and the product may only virtualize services running in specific namespaces then add the following parameter to the Helm install:

    --set execution.istio.enabled=true

    Then enable service virtualization in specific namespaces using this command:

    kubectl create rolebinding istio-virtualization-enabled -n {namespace} --clusterrole={my-ots}-execution-istio-test-system --serviceaccount=test-system:{my-ots}-execution
    Note: Uninstalling the chart does not clean up these manually created role bindings.
  • For Single-tenant clusters

    If the cluster is not shared and the product may virtualize any service running in the whole cluster then add the following parameters to the Helm install:

    --set execution.istio.enabled=true

    --set execution.istio.clusterRoleBinding.create=true

The cause might be that the fully qualified domain name is not specified in the Host field for the stub when it was created.

Verify and ensure to add the fully qualified domain name of the server in the Host field when the physical transport for the stub is configured in Rational® Integration Tester.

Table 5. Troubleshooting issues: test results and reports




You are not able to view the Jaeger traces for the tests you ran.

The cause can be as follows:
  • Might be that you have not installed Jaeger at the time of server installation.
  • The Jaeger trace is not supported for the particular test you ran.
Check for any of the following solutions: