Known issues and limitations in Planning Analytics

After a service upgrade from version 5.x, the Planning Analytics service instance remains in Pending state

Applies to: 5.2.2

After you upgrade your Planning Analytics service from version 5.x to version 5.2.2, thePlanning Analytics service instance might remain in a Pending state.

This occurs if the bss pod remained in a Waiting state with a CrashLoopBackOff error after the upgrade.

Workaround

To resolve this issue, run the following commands to delete the bss pod:

OPERAND_NAMESPACE=<operand_namespace>
oc delete pods -l name=bss -n $OPERAND_NAMESPACE

After a service upgrade from version 4.8.7, the Planning Analytics service instance remains in Pending state

Applies to: 5.2.2

After you upgrade your Planning Analytics service from version 4.8.7 to version 5.2.2, thePlanning Analytics service instance might remain in a Pending state.

This occurs if the bss pod remained in a Waiting state with a CrashLoopBackOff error after the upgrade.

Workaround

To resolve this issue, run the following commands to patch the service instance:

OPERAND_NAMESPACE=<operand_namespace>
OPERATOR_NAMESPACE=<operator_namespace>
oc patch service mysql-server -n $OPERAND_NAMESPACE --type='json' \
  -p='[{"op": "remove", "path": "/spec/selector/lb"}]'
oc delete $(oc get po -l app.kubernetes.io/instance=ibm-planning-analytics-operator -o=name -n $OPERATOR_NAMESPACE) -n $OPERATOR_NAMESPACE

For upgrades, the Planning Analytics service instance display name cannot contain upper case letters

Applies to: 5.2.1

Fixed in: 5.2.2

Before you upgrade your Planning Analytics service to version 5.2.1, you must make sure that the service instance display name (zenServiceInstanceDisplayName) does not contain upper case letters.

Workaround

Verify and resolve this issue in the PAServiceInstance CR file:

1. Edit the PAServiceInstance CR file.
2. Navigate to the zenServiceInstanceDisplayName field and make sure that the letters are all lower case.

   In the following example, the display name of the service instance contains upper case letters:

   apiVersion: pa.cpd.ibm.com/v1
   kind: PAServiceInstance
   metadata:
     name: serviceinstancename
     namespace: namespacea
   ...
   spec:
     zenServiceInstanceId: <service_instance_id>
     zenServiceInstanceOwnerUID: <owner_uid>
     zenServiceInstanceDisplayName: serviceInstanceName
     ...

3. To resolve the issue, change the value of the zenServiceInstanceDisplayName field to contain only lower case letters.

   In the following example, the display name of the service instance is changed to contain only lower case characters:

   apiVersion: pa.cpd.ibm.com/v1
   kind: PAServiceInstance
   metadata:
     name: serviceinstancename
     namespace: namespacea
   ...
   spec:
     zenServiceInstanceId: <service_instance_id>
     zenServiceInstanceOwnerUID: <owner_uid>
     zenServiceInstanceDisplayName: serviceinstancename
     ...

4. Change the value of the version field to 5.2.1 to proceed with the upgrade.

   In the following example, the value of the version field is changed to 5.2.1:

   apiVersion: pa.cpd.ibm.com/v1
   kind: PAServiceInstance
   metadata:
     name: serviceinstancename
     namespace: namespacea
   ...
   spec:
     zenServiceInstanceId: <service_instance_id>
     zenServiceInstanceOwnerUID: <owner_uid>
     zenServiceInstanceDisplayName: serviceinstancename
     ...
     version: 5.2.1
     ...

After a service instance restore, TM1 databases appear in Down state

Applies to: 5.2.0 and 5.2.1

Fixed in: 5.2.2

After you restore a Planning Analytics service instance from a backup, the connected TM1 databases all have a status of Down.

Run the following commands to verify that the TM1 database is down because of an error with the TLS handshake:

1. Find the name of the TM1 database pod by running the oc get pods command.

   oc get pods -l "icpdsupport/module"="pa-tm1-databases"

   The name of the TM1 database pod is in the form of tm1-i-xxx-d-zzz-k-yy.

2. View the logs for the TM1 database pod that you identified.

   oc logs -f tm1-i-<xxx>-d-<zzz>-k-<yy>

3. Determine if the following log entry for an error with the TLS handshake is in the log, including the name of the TM1 database pod that you identified:

   {"level":"warn","date":"...","message":"Unable to establish connection to MongoDB, retrying...","error":"No suitable servers found: `serverSelectionTimeoutMS` expired: [TLS handshake failed: certificate verify failed (19): self signed certificate in certificate chain] [TLS handshake failed: certificate verify failed (19): self signed certificate in certificate chain] [TLS handshake failed: certificate verify failed (19): self signed certificate in certificate chain]. Topology type: ReplicaSetNoPrimary: generic server error","logSourceCRN":"DEFAULT","service":"tm1-i-<xxx>-d-<zzz>-k-<yy>","version":"12.5.1","logger":"serviceLogger"}

Workaround

If the TM1 database pod is down due to an error with the TLS handshake, restart the TM1 database to resolve this issue.

For the TM1 database pod that you identified, run the following command to restart the pod:

oc delete pod tm1-i-xxx-d-zzz-k-yy -n

The TM1 database appears in a Running state after the database pod restarts.