Bug 1683100
| Summary: | system infrastructure component pod not set priorityclass field correctly | ||
|---|---|---|---|
| Product: | OpenShift Container Platform | Reporter: | MinLi <minmli> |
| Component: | Node | Assignee: | ravig <rgudimet> |
| Status: | CLOSED ERRATA | QA Contact: | Jianwei Hou <jhou> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 4.1.0 | CC: | aos-bugs, jokerman, minmli, mmccomas, rgudimet, sjenning |
| Target Milestone: | --- | ||
| Target Release: | 4.1.0 | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2019-06-04 10:44:39 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
MinLi
2019-02-26 09:21:32 UTC
Static pods (i.e. the kube-* control plane components) have a known issue with this atm.
However, the openshift-{apiserver|controller-manager} should have these set.
Ravi, could you open PRs against the listed components.
MinLi, is this the full list of components you expect to have critical priorities? Just want to set expectations so we can get all the changes in this one BZ.
Seems apiserver is already setting the priorityClass. #oc describe pod apiserver-2g9r8 -n openshift-apiserver | grep -i priority Priority: 2000001000 PriorityClassName: system-node-critical #oc describe pod kube-apiserver-ip-10-0-131-80.us-east-2.compute.internal -n openshift-kube-apiserver | grep -i priority Priority: 2000001000 PriorityClassName: system-node-critical #oc describe pod openshift-kube-scheduler-ip-10-0-131-80.us-east-2.compute.internal -n openshift-kube-scheduler | grep -i priority Priority: 2000001000 PriorityClassName: system-node-critical #oc describe pods kube-controller-manager-ip-10-0-131-80.us-east-2.compute.internal -n openshift-kube-controller-manager|grep -i priority Priority: 2000001000 PriorityClassName: system-node-critical We are not setting values for openshift-controller-manager. #oc describe pod controller-manager-7t97k -n openshift-controller-manager | grep -i priority Priority: 0 PriorityClassName: <none> Posted a PR for openshift-controller-manager: https://github.com/openshift/cluster-openshift-controller-manager-operator/pull/77 @Seth Jennings, @ ravig , according to my test, ns "openshift-machine-api" is not setting the priorityClass. And the sdn-controller-XXX pod of ns "openshift-sdn" is not setting either. @MinLi, I have created PRs ensure that particular priorityclasses. Following are PRs merged: https://github.com/openshift/cluster-autoscaler-operator/pull/57 https://github.com/openshift/machine-api-operator/pull/230 But for sdn-controller-XXX pod in openshift-sdn namespace, Dan thinks the cluster critical priorityClass is not needed. https://github.com/openshift/cluster-network-operator/pull/109 - Here is the PR that I closed since Dan thinks the critical priorityClasses are not needed. @ravigļ¼OK, I think you provide a reasonable explaination for why not add critical priorityClass to sdn-controller-XXX pod. And benefit a lot from you, thx! All PRs have merged @Seth Jennings, @ravig, the following PriorityClass not set: # oc describe pod controller-manager-7hvh6 -n openshift-controller-manager | grep -i priority Priority: 0 PriorityClassName: <none> # oc describe pod clusterapi-manager-controllers-957d78db5-zg225 -n openshift-machine-api | grep -i priority Priority: 0 PriorityClassName: <none> version info: 4.0.0-0.nightly-2019-03-04-234414 oc v4.0.0-0.182.0 kubernetes v1.12.4+4dd65df23d verified! 4.0.0-0.nightly-2019-03-13-233958 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/RHBA-2019:0758 |