-
Bug
-
Resolution: Done
-
Critical
-
Logging 5.5.3, Logging 5.6.0
-
False
-
None
-
False
-
NEW
-
NEW
-
-
Log Collection - Sprint 226, Log Collection - Sprint 227
-
+
Description of problem:
The current value set in the openshift-logging PriorityClass is set to 1000000 which is fairly low and can depending on the environment cause that the collector pod can not run/be scheduled on a given OpenShift Container Platform 4 - Node.
Given that logs are a critical part of OpenShift Container Platform 4, we should ensure that collector is always able to run and therefore has a PriorityClass value close to the value of system-cluster-critical
Version-Release number of selected component (if applicable):
OpenShift Container Platform 4 - Cluster Logging 5.5
How reproducible:
Always
Steps to Reproduce:
- Install OpenShift Container Platform 4 - Cluster Logging 5.5
- Run workloads that use most of the available resources
- See how collector pod is failing to run/schedule on a heavily loaded Node
Actual results:
collector pod may not be able to run because other higher priority pods are using up the available resources. Considering that OpenShift Container Platform 4 - Cluster Logging is critical, openshift-logging PriorityClass should have a value that is close to system-cluster-critical PriorityClass.
Expected results:
collector able to run even when resources are thin and only bare minimum of components are able to run on the given Node. Here collector pod should be part of it, based on it's PriorityClass to secure log aggregation.
Additional info:
- is cloned by
-
LOG-3287 [release-5.5] Increase value of cluster-logging PriorityClass to move closer to system-cluster-critical value
- Closed
- links to
- mentioned on