-
Bug
-
Resolution: Done
-
Major
-
7.13.1.GA
-
False
-
None
-
False
-
-
-
-
-
-
-
-
---
-
---
-
-
-
2023 Week 09-11 (from Feb 27), 2023 Week 12-14 (from Mar 20), 2023 Week 15-17 (from Apr 10)
Sometimes RHPAM Kogito Operator 7.x installation gets stuck in the "installing" state. The reason behind this is rhpam-kogito-operator-controller-manager pod with default memory limits is being OOMKilled and is stuck in a CrashLoopBackOff.
oc get pods -n openshift-operators | grep rhpam
NAME READY STATUS RESTARTS AGE
rhpam-kogito-operator-controller-manager-xxxxxxxx-xxxxx 1/2 CrashLoopBackOff 262 (4m14s ago) 24h
oc describe pod rhpam-kogito-operator-controller-manager-xxxxxxxx-xxxxx
[...]
State: Waiting
Reason: CrashLoopBackOff
Last State: Terminated
Reason: OOMKilled
Exit Code: 137
Started: Tue, 20 Dec 2022 19:13:48 +0530
Finished: Tue, 20 Dec 2022 19:14:16 +0530
Ready: False
Restart Count: 262
[...]
The default memory limit (i.e., 200mi) that was set on the rhpam-kogito-operator-controller-manager pod was not sufficient. After increasing the memory limit, the pod came up running.
On checking the memory consumption of rhpam-kogito-operator-controller-manager pod after increasing the memory limit, I found that the memory consumption is more that the default limit:
oc adm top pod | grep rhpam
NAME CPU(cores) MEMORY(bytes)
rhpam-kogito-operator-controller-manager-xxxxxxxxx-xxxxx 2m 250Mi <-----
Increasing the default memory limit is as workaround for this issue and I am creating a KCS solution to address it.
https://access.redhat.com/solutions/6991378
I am creating this bug ticket to get your views on increasing the default memory limit to ensure successful operator installation. Please let me know if more information is needed.