Troubleshooting
Problem
In Maximo Manage, configuring API keys for push notifications results in a persistent 'loading...' state without completion.
The issue is observed in an OpenShift cluster environment where the push notification service pod fails to create, and logs indicate errors related to 'Unable to generate kubeconfig' and missing '/tmp/kubeconfig' files.
Symptom
The configuration of API keys for push notifications remains in a 'loading...' state indefinitely.
The pod where you can check the error is named 'entitymgr-pushnotificationcfg'.
Cause
The issue was caused by a limitation where the Push Service pod fails to create due to a read-only root filesystem.
The problem is resolved by setting `readOnlyRootFilesystem` to `false` in the Suite configuration.
Environment
IBM Maximo Manage 9.0 and 9.1
Diagnosing The Problem
1. Inspect the 'entitymgr-pushnotificationcfg' pod logs to identify the errors, like below:
--------------------------- Ansible Task StdOut -------------------------------
TASK [Create PushNotificationCfg Operator reconcile configmap] ********************************
[0;31mfatal: [localhost]: FAILED! => {"changed": false, "msg": "Failed to create object: b'Unable to determine if virtual resource\\n'", "reason": "Internal Server Error"}[0m
-------------------------------------------------------------------------------
2. Check the CRD PushNotificationCfg, Instances, take "dev-push-notification-system" instance and opened its yaml.
I has the following status message at the end of the file:
status:
conditions:
- ansibleResult:
changed: 1
completion: '2026-03-11T14:08:07.469662'
failures: 1
ok: 19
skipped: 13
lastTransitionTime: '2026-03-11T14:08:08Z'
message: 'Failed to create object: b''Unable to determine if virtual resource\n'''
reason: Failed
status: 'True'
type: Failure
- lastTransitionTime: '2026-03-11T14:08:08Z'
message: ''
reason: ''
status: 'False'
type: Successful
- lastTransitionTime: '2026-03-13T20:34:10Z'
message: Running reconciliation
reason: Running
status: 'False'
Resolving The Problem
The issue was resolved by adjusting the 'readOnlyRootFilesystem' setting to 'false' in the OpenShift cluster's CustomResourceDefinitions for Suites.
This change allowed the creation of the 'push-notification-service' pod, which was previously blocked. The steps to resolve the issue are as follows:
1. Access the OpenShift cluster.
2. Navigate to Administration > CustomResourceDefinitions > Suites > Suite Details (Instance) > YAML.
3. Under 'spec > settings', set 'readOnlyRootFilesystem: false'.
4. Save the changes and verify that the 'push-notification-service' pod is created.
5. Reconfigure the API keys for push notifications and confirm that the configuration saves successfully.
Document Location
Worldwide
Product Synonym
Push Notification;Maximo Mobile
Was this topic helpful?
Document Information
Modified date:
03 April 2026
UID
ibm17268569