Release notes - Guardium Insights Version 3.3.0

java.lang.StackOverflowError

Workaround: Connect to the MongoDB pod, select the relevant database, and run these commands:

db.system_data_versions.deleteOne({"_id": "risk-analytics-classification"}) 
db.classification_type.drop()

After issuing these commands, restart all risk-analytics-classification pods.

Could not create violation lead generator, an error occurred: Failed to load query to collect leads from violation.

Workaround: Connect to the MongoDB pod, select the relevant database, and run these commands:

db.system_data_versions.deleteOne( {"_id": "risk-analytics-engine"})
db.leads_configuration.drop()
db.leads_generators.drop()
db.leads_weights.drop()
db.features_configuration.drop()
db.queries.drop()

Workaround: Before upgrading, ensure that the length of the spec.guardiumInsightsGlobal.ingress.hostname value in your custom resource (CR) file is 58 characters or fewer.

Workaround: Choose one of these options:

• Delete the additional ReplicaSet that is creating the additional pod:
  1. Find the cp-serviceability replicasets:

     [root@bastion ~]# oc get replicasets | head -n 1
     NAME                                               DESIRED   CURRENT   READY   AGE
     [root@bastion ~]# oc get replicasets | grep cp-
     staging-cp-serviceability-645ddf7ffd               1         1         0       6d1h
     staging-cp-serviceability-9b7bb5684                1         1         1       6d1h

  2. Remove the replicaset that is marked as READY = 1. In the above example, this is staging-cp-serviceability-9b7bb5684:

     [root@bastion ~]# oc delete replicaset staging-cp-serviceability-9b7bb5684
     replicaset.apps "staging-cp-serviceability-9b7bb5684" deleted

  3. Wait until additional cp-serviceability pod is terminated:

     [root@bastion ~]# oc get pods | grep cp-
     staging-cp-serviceability-645ddf7ffd-7w4kl                        0/1     ContainerCreating   0              97m
     staging-cp-serviceability-9b7bb5684-n4nx7                         1/1     Terminating         0              100m
     
     [root@bastion ~]# oc get pods | grep cp-
     staging-cp-serviceability-645ddf7ffd-7w4kl                        1/1     Running     0              100m

  4. You will now be able to use the documented mustgather commands.
• When using mustgather commands that refer to a cp-serviceability pod, use the pod that is in the Running state. You can refer to https://www.ibm.com/support/pages/node/6832174. In this document, extra verification is required:
  • For step ii, check which pod is Running by issuing this command:

    oc get pods | grep cp-serviceability

  • For step v, use the pod in Running state to download files with oc cp commands.

Workaround: Go to the user management screen and add the user. Then return to the Refine alerts page to add the user to the list.

Workaround: Editing the connection will cause it to be healthy again.

Data mart unavailable Cannot load data mart statistics. Refresh the page to try again

Workaround: If the Data mart ingestion page displays this error, you can access the data mart ingestion information by opening the Data mart ingestion status report. This report includes data marts collected from both collectors and aggregators. To open the reports page, select Reports in the main menu. Open this menu by clicking the main menu icon ()

Workaround: To re-upload the files that have been preserved - and to resume ingestion - restart ssh-service.

Workaround: Keep group members for all compliance groups at 2000 members or fewer until future performance improvements can be made.

SQLCODE=-1803, SQLSTATE=57056, SQLERRMC=NULLID.SYSSN200 0X5359534C564C3031, DRIVER=4.26.14
SQLCODE=-901, SQLSTATE=58004, SQLERRMC=Plan/Environment mismatch!, DRIVER=4.26.14

Workaround: See Db2 errors for reports and risk services.