IBM Storage Fusion Data Cataloging known issues

List of all troubleshooting and known issues exist in version 2.1 of Data Cataloging.

Known issues in version 2.1

The following known issues exist in version 2.1 of Data Cataloging, with workarounds included wherever possible. If you come across an issue that cannot be solved by using these instructions, contact IBM support .

COS connection reporting scan aborted due to inactivity

If a COS connection scan fails with the error “Scan aborted because of a long period of inactivity”, it can be resolved by editing the settings file connections/cos/scan/scanner-settings.json within the data PV and choosing a higher value for notifier_timeout than the default value of 120 seconds. The change will be picked on the next scan. No pod restart is required.

Database connection issue after reboot

If an unexpected cluster update or node reboot causes database connection issues, it might be necessary to check the following:
  • All storage is mounted correctly on the compute nodes for system data and remount/reconnect if necessary.
  • System is connected to database and normal system operations such as create connection, scan, view connections, policies are working.
  • If the operations cannot be carried out, check the state of the db2whrest pod, and restart pod to reestablish the database connection if necessary by deleting the pod:
    oc delete pod -l app=spectrum-discover-db2whrest

Image pull error due to authentication failure

The OCP login token expires occasionally, and as this is the container image registry password, this breaks the service account access to the registry. If a pod is failing to pull an image from the registry with an authentication error, then re-create the image-registry-pull-secret and relink the service accounts to the new secret:
oc delete secret image-registry-pull-secret
HOST=$(oc get route default-route -n openshift-image-registry --template='{{ .spec.host }}')
oc create secret docker-registry image-registry-pull-secret \
    --docker-server="${HOST}" \
    --docker-username=kubeadmin \
    --docker-password="$(oc whoami -t)"
for account in spectrum-discover-operator strimzi-cluster-operator spectrum-discover-ssl-
zookepper spectrum-discover-sasl-zookeeper; do oc secrets link $account image-registry-pull-
secret --for=pull; done

Visual query builder search terms overrides SQL search when going into individual mode

If a search is started in the query builder, then changed to SQL mode, the initial group search is as expected but if expanded to individual records it uses the query builder terms as the base. A workaround is to clear the visual query before changing to SQL query.

LDAPS configuration failing if dollar sign is in password

Currently, the dollar sign is not supported on passwords for ldaps configuration. A workaround is to create a password without the dollar sign in it.

Content search policy missing files

If there are issues with the incorrect expected data count while running a policy, you must verify that the connection is active, and rescan to get the latest data ingested to Data Cataloging. After successful upgrade of Data Cataloging, a rescan of existing connections is recommended.

REST API returns token with unprintable characters

It is a noted issue that a carriage return (\r) is included at the end of HTTP response headers due to an issue with curl. This has been known to occasionally break scripts that use an auth token from the Data Cataloging appliance as shown here:
$ curl -k -H "Authorization: Bearer ${TOKEN}" https://$SDHOST/policyengine/v1/tags
curl: (92) HTTP/2 stream 0 was not closed cleanly: PROTOCOL_ERROR (err 1)
As such, it is recommended to filter out the \r character. If you have a line like the following in bash:
`TOKEN=$(curl -i -k https://$SDHOST/auth/v1/token -u "$SDUSER:$SDPSWD" | grep -i x-auth-token |
awk '{print $2}')`
Simply add a | tr -d ‘\r’ at the end to avoid running into this issue:
`TOKEN=$(curl -i -k https://$SDHOST/auth/v1/token -u "$SDUSER:$SDPSWD" | grep -i x-auth-token |
awk '{print $2}' | tr -d '\r')`

Querying available applications on Docker Hub is not working

When you retrieve the list of available applications on Docker Hub by using the public registry endpoint, the query retrieves an empty response:
$ tcurl https://${OVA}/api/application/appcatalog/publicregistry | jq
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100    78  100    78    0     0    135      0 --:--:-- --:--:-- --:--:--   135
{
  "success": "false",
  "message": "Could not retrieve available applications."
}

To avoid this issue, you need to open a browser and access the following URL:Docker Documentation.

The above link retrieves the list of Data Cataloging applications available in the public registry. The image name of the application that is selected from the query output can be used to create a JSON file with the information that is needed to run the application, as shown in the following: Spectrum Discover Documentation.

Running applications from the catalog

Querying and running available applications from the catalog. Currently, the REST API public registry endpoint to retrieve the list of available applications from the DockerHub is not working. For that reason, the Data Cataloging application catalog is only available in the following repository:Spectrum Discover App Catalog

Scale Live Events do not get populated due to the timestamp field value being invalid

Live events for IBM Spectrum Scale connections do not work as expected. After the initial scan of an IBM Spectrum Scale connection, only file deletions will result in a live update of the files that were discovered by the scan. If a file is modified or added, the live update will fail, and there will be no change reflected in the Data Cataloging product. This error is recorded by the DB2 product and can be surfaced by extracting the bad updates and the corresponding log files from one of the db2 pods. The following script executed within one of the db2 pods would extract these errors for analysis.
cd /mnt/blumeta0/home/bluadmin
sudo ls *.bad > /tmp/output.bad
sed 's/bad/log/'  /tmp/output.bad > /tmp/output.log
sudo zip /tmp/output.zip -r . -i@/tmp/output.bad -i@/tmp/output.log
rm /tmp/output.bad
rm /tmp/output.log
cd /tmp

The workaround is to perform schedule scans of the IBM Spectrum Scale connections so that all file changes are up to date.

Data Cataloging login page stuck in loading

Discover GUI is inaccessible after nodes put in maintenance node and moved back to ready state for short period in OpenShift® Container Platform, but service status remains healthy.

Workaround:
  1. Edit the isd-ui-backend deployment to change OCPAPI_SERVER envvar current value to use the new value.
    https://kubernetes.default.svc.cluster.local
  2. Wait for OpenShift to create a pod with the new deployment and delete the current one.
  3. Review whether the changes are applied in the Environment tab.
  4. Open the Data Cataloging service, clean the cookies, and reload the user interface.