Known issues and limitations for OpenPages

The following known issues and limitations apply to OpenPages.

Known Issues

Old namespace search pod fails with a different namespace
Provisioning fails with a RabbitMQ error
The Roles By User and Roles By Domain reports do not run
Some reporting fragments might fail
The Risk Management for ESG dashboards fail to run
Net Promoter Score (NPS) survey capability
OpenPages StatefulSet replicas do not scale down automatically
Generating reports through Cognos Analytics causes page module error
After upgrading, RabbitMQ pod is stuck in CrashLoopBackOff state

Limitations

Functional differences
Long strings
Timestamps use Coordinated Universal Time

Known issues

Old namespace search pod fails with a different namespace

Applies to: 5.4

If you have the original old namespace and the new namespace in the same cluster, the old namespace search pod fails when it tries to connect to the namespace. The search pod is connecting to the new namespace instead since they both have the same instance ID.

Workaround

To avoid the issue of the old namespace search pod failing, complete the following steps for the workaround. Manual Admin search URL is required to update from the OpenPages UI console. Update the search URL to the correct namespace and then save it.

Set /Applications/Common/Configuration/Show Hidden Settings to True.
Update the search URL /Platform/Search/Admin/Search Server Administration URL with the value https://op-{Instance_ID}-search-svc.{<NAMESPACE>}.svc.cluster.local:8985.
Set the correct namespace in the URL for both Index and Request:
- Key: /Platform/Search/Index/Search Server URL
- Value: https://op-{Instance_ID}-search-svc.{<NAMESPACE>}.svc.cluster.local:8983
- Key: /Platform/Search/Request/Search Server URL
- Value: https://op-{Instance_ID}-search-svc.{<NAMESPACE>}.svc.cluster.local:8983

Provisioning fails with a RabbitMQ error

Fixed in: 5.1.3

When you provision an OpenPages instance, the instance is in an InstallError state and you see the following error:

Failed to gather information about RabbitMQCluster(s) even after waiting for 300 seconds
openpagesinstance role has failed. See earlier output for exact error.

When you view the RabbitMQ cluster details, you see an error about Helm annotations.

$ oc describe rabbitmqcluster openpages-<instance_name>-<instance_id>
...
message: 'failed to install release: rendered manifests contain a resource that
  already exists. Unable to continue with install: ServiceAccount "openpages-<instance_name>-<instance_id>-ibm-rabbitmq"
  in namespace "<namespace>" exists and cannot be imported into the current release:
  invalid ownership metadata; label validation error: missing key "app.kubernetes.io/managed-by":
  must be set to "Helm"; annotation validation error: missing key "meta.helm.sh/release-name":
  must be set to "openpages-<instance_name>-<instance_id>"; annotation validation error:
  missing key "meta.helm.sh/release-namespace": must be set to "<namespace>"'

To resolve the issue, do the following steps:

View the ServiceAccount by running the following command:

oc get sa openpages-<instance_name>-<instance_id>-ibm-rabbitmq -o yaml

Verify that Helm is missing from the annotations.

Delete the ServiceAccount by running the following command:

oc delete sa openpages-<instance_name>-<instance_id>-ibm-rabbitmq

After a few minutes, the RabbitMQ cluster starts and the provisioning process completes.

The Roles By User and Roles By Domain reports do not run

Applies to: 5.1.0

Fixed in: 5.1.1

The following Cognos reports do not work and return an error:

Roles By User
Roles By Domain

Some reporting fragments might fail

Applies to: 5.0.0 and later

When you run reporting fragments that use a DQM reporting framework package with prompts, the process fails.

In OpenPages, you see the following message:

OP-12013 The computation encountered an error.

In the Cognos logs, you see the following message:

XQE-PLN-0537 The inverted parameter &apos;<PROMPT_VARBLE>&apos; can only be 
used in the context of an IN or IN_RANGE operator. Context is 
&apos;<QUERY_SUBLECT> = ?<PROMPT_VARBLE>?&apos;

For a workaround, see Running Reporting Fragment fails with OP-12013 The computation encountered an error exception.

The Risk Management for ESG dashboards fail to run

Applies to: 5.0.0 and later

When you open the ESG Compliance Dashboard or the Objective Dashboard, you get the following message:

We can't load the Visualization, because its associated data set 'ESG Reporting' isn't available.

Or, you might see:

Data source adapter error:com.ibm.db2.jcc.am.SqlException: 
Application raised error or warning with diagnostic text: "No_DATA_FOUND"

For a workaround, see ESG dashboards do not display.

Net Promoter Score (NPS) survey capability

Applies to: 5.0.0 and later

The OpenPages Net Promoter Score (NPS) survey capability is temporarily unavailable during the transition to a new NPS survey platform.

Net Promoter Score (NPS) survey functionality will not be available until the transition to the new NPS survey platform is complete and a later OpenPages release becomes available that supports the new NPS survey platform.

OpenPages StatefulSet replicas do not scale down automatically

Applies to: 5.0.0 and later

The application server replicas that Horizontal Pod Autoscaler (HPA) initiates are not scaled down by HPA when the application is not in use.

Workaround

Run the following command to scale down the replicas manually. Replace <instance_name> with the OpenPages instance name and <number_of_replicas_needed> with a number greater than or equal to 1:

oc scale sts openpages-<instance_name>-sts --replicas=<number_of_replicas_needed> -n ${OPENPAGES_INSTANCE_NAMESPACE}

Generating reports through Cognos Analytics causes page module error

Applies to: 5.0.x.

After integrating OpenPages with Cognos Analytics on the IAM cluster, you get the following error when generating reports:

Page module error
scripterror: ../v1/ext/OpenPages/PageModule

Workaround

Download the OpenPages module extension zip file from the container that shipped with the product.

If using Oracle database:

podman cp $(podman create --rm cp.stg.icr.io/cp/hub/openpages-cpd-opappdata:9.0.0.3.2-61):/opt/cognos-artifacts/ORACLE/OpenPages.zip .

If using Db2 database:

podman cp $(podman create --rm cp.stg.icr.io/cp/hub/openpages-cpd-opappdata:9.0.0.3.2-61):/opt/cognos-artifacts/OpenPages.zip .

Import the zip file to Cognos Analytics:
1. Navigate to Cognos Analytics UI > Manage > customizations.
2. Upload the zip file.

After upgrading, RabbitMQ pod is stuck in CrashLoopBackOff state

Applies to: 5.1.0, 5.1.1

Fixed in: 5.1.2

After you upgrade OpenPages on Cloud Pak for Data from version 5.0.x to 5.1, the CPD-CLI*.log file contains an error similar to that in the following example:

CPD-CLI-<timestamp>.log:time=<timestamp> level=error msg=failed to wait for statefulset openpages--78c5-ib-12ce in namespace <cpd_instance_ns>: 
timed out waiting for the condition func=cpdbr-oadp/pkg/kube.waitForStatefulSetPods file=/a/workspace/oadp-upload/pkg/kube/statefulset.go:173

To confirm that a pod is in the CrashLoopBackOff state, run the following command:

oc get pods -n ${PROJECT_CPD_INST_OPERANDS} | grep openpages

Example output:

openpages--78c5-ib-12ce-0                                1/1     Running                 0                 23h
openpages--78c5-ib-12ce-1                                0/1     CrashLoopBackOff        248 (3m57s ago)   23h
openpages-openpagesinstance-cr-sts-0                     1/2     Running                 91 (12m ago)      23h
openpages-openpagesinstance-cr-sts-1                     1/2     Running                 91 (12m ago)      23h

Workaround

To work around the problem, do the following steps:

Log in to Red Hat® OpenShift® Container Platform as a cluster administrator.
```
${OC_LOGIN}
```
Remember: OC_LOGIN is an alias for the oc login command.

Check the OpenPages logs for the following error in the second RabbitMQ pod:

===========
Exception during startup:

exit:{boot_failed,{exit_status,1}}

    peer:start_it/2, line 639
    rabbit_peer_discovery:query_node_props/1, line 408
    rabbit_peer_discovery:sync_desired_cluster/3, line 189
    rabbit_db:init/0, line 65
    rabbit_boot_steps:-run_step/2-lc$^0/1-0-/2, line 51
    rabbit_boot_steps:run_step/2, line 58
    rabbit_boot_steps:-run_boot_steps/1-lc$^0/1-0-/1, line 22
    rabbit_boot_steps:run_boot_steps/1, line 23

If you see this error, check the Erlang cookie value at the top of the OpenPages logs. For example, run the following command:

oc logs -n ${PROJECT_CPD_INST_OPERANDS} openpages--78c5-ib-12ce-1

Example output:

Defaulted container "openpages-openpagesinstance-cr-<instance_id>-ibm-rabbitmq" out of: openpages-openpagesinstance-cr-<instance_id>-ibm-rabbitmq, copy-rabbitmq-config (init)
----------------------
+FkpbwejzK2RXfmPLQAnITroiieu3uGa3vkRA2k6t+8=
----------------------
<timestamp> [warning] <0.156.0> Overriding Erlang cookie using the value set in the environment

The plus sign (+) at the beginning of the cookie value is the source of the problem.

Regenerate a new token:

openssl rand -base64 32 | tr -d '\\n' | base64 | tr -d '\\n'

Decode from Base64 format, and make sure that the cookie value does not begin with a plus sign (+).
Replace the cookie value in the auth secret.
1. Edit the auth secret:
```
oc -n ${PROJECT_CPD_INST_OPERANDS} edit secret openpages-openpagesinstance-cr-<instance_id>-rabbitmq-auth-secret
```
2. Replace the rabbitmq-erlang-cookie value with the new value.

Delete the StatefulSet, or scale down and then scale up to get all the pods to pick up the new cookie.

To identify the StatefulSet, run the following command:

oc -n ${PROJECT_CPD_INST_OPERANDS} get sts -licpdsupport/addOnId=openpages,icpdsupport/app=rabbitmq-server

Example output:

NAME                        READY      AGE
openpages--1e83-ib-12ce     3/3        28h

Limitations

Functional differences

The following OpenPages features are not supported in OpenPages for IBM® Software Hub

Field level encryption is not supported.
The ability to shorten the OpenPages application URL is not supported.

Long strings

If you're using an internal database, long string fields (string fields that contain more than 4000 bytes) have the following limitations:

Filtering on long string fields in views, dashboards, workflows, and calculations is not supported.
Creating public filters or personal filters that are based on long string fields is not supported.
Querying long string fields with the REST API is not supported.

Timestamps use Coordinated Universal Time

Timestamps use Coordinated Universal Time (Coordinated Universal Time). For example, when you run jobs in the Scheduler, the execution timestamp is in Coordinated Universal Time, rather than in local time.