Uploaded image for project: 'OpenShift Logging'
  1. OpenShift Logging
  2. LOG-3225

Increase value of cluster-logging PriorityClass to move closer to system-cluster-critical value

XMLWordPrintable

    • False
    • None
    • False
    • NEW
    • NEW
    • Hide
      Before this update, the priority class value associated with the logging deployment was too small given the critical nature of log collection. This update changes the value so that logging now uses system-cluster-critical.
      Show
      Before this update, the priority class value associated with the logging deployment was too small given the critical nature of log collection. This update changes the value so that logging now uses system-cluster-critical.
    • 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:

      1. Install OpenShift Container Platform 4 - Cluster Logging 5.5
      2. Run workloads that use most of the available resources
      3. 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:

              jcantril@redhat.com Jeffrey Cantrill
              rhn-support-sreber Simon Reber
              Anping Li Anping Li
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Created:
                Updated:
                Resolved: