We should not be specifying a CPU limit for infrastructure pods by default. Instead, we should be specifying a proper CPU request to ensure a pod is scheduled on a node where a minimum CPU resources are available.
Adding ref to 3.6 origin logging PR. Needed before ansible change. openshift/origin-aggregated-logging/pull/726
Commit pushed to master at https://github.com/openshift/openshift-ansible https://github.com/openshift/openshift-ansible/commit/578ac5b348fa3e9c7d0d05e3a0f579839ecd79dd Use "requests" for CPU resources instead of limits We now use a CPU request to ensure logging infrastructure pods are not capped by default for CPU usage. It is still important to ensure we have a minimum amount of CPU. We keep the use of the variables *_cpu_limit so that the existing behavior is maintained. Note that we don't want to cap an infra pod's CPU usage by default, since we want to be able to use the necessary resources to complete it's tasks. Bug 1501960 (https://bugzilla.redhat.com/show_bug.cgi?id=1501960)
Please change to ON_QA, issue is fixed Tested scenarios: 1. ops enabled cluster 2. mux client It uses "resources.requests.cpu" for CPU resources instead of "resources.limits.cpu" now But there is one defect: https://bugzilla.redhat.com/show_bug.cgi?id=1505683, this defect is not related to BZ 1501960, so close BZ 1501960. images: logging-kibana:v3.6.173.0.59-1 logging-elasticsearch:v3.6.173.0.59-1 logging-fluentd:v3.6.173.0.59-1 logging-auth-proxy:v3.6.173.0.59-1 logging-curator:v3.6.173.0.59-1 # rpm -qa | grep openshift-ansible openshift-ansible-filter-plugins-3.6.173.0.59-1.git.0.0e31372.el7.noarch openshift-ansible-docs-3.6.173.0.59-1.git.0.0e31372.el7.noarch openshift-ansible-lookup-plugins-3.6.173.0.59-1.git.0.0e31372.el7.noarch openshift-ansible-callback-plugins-3.6.173.0.59-1.git.0.0e31372.el7.noarch openshift-ansible-playbooks-3.6.173.0.59-1.git.0.0e31372.el7.noarch openshift-ansible-3.6.173.0.59-1.git.0.0e31372.el7.noarch openshift-ansible-roles-3.6.173.0.59-1.git.0.0e31372.el7.noarch
set it to VERIFIED as per Comment 4
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2017:3389