Description of problem: When using Calico SDN, the kube-proxy daemonset is deployed. It makes no cpu or memory rquests, resulting in pods with a QoSClass of BestEffort. A cluster with this configuration always fail this e2e test: https://github.com/openshift/origin/blob/4d0922fb92f85f566cb22bbaaedf587e8a50aca4/test/extended/operators/qos.go#L20 Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Run e2e against a cluster running with Calico SDN Actual results: Test fails: [sig-arch] Managed cluster should ensure control plane pods do not run in best-effort QoS Expected results: Test succeeds Additional info:
hi, Cesar, could you help or which QE from Calico can help verified Calico related bug?
There are instructions here: https://docs.projectcalico.org/getting-started/openshift/installation I verified with 4.5.0-0.nightly-2020-04-29-173148: $ oc get pods -n kube-proxy NAME READY STATUS RESTARTS AGE openshift-kube-proxy-89h2b 1/1 Running 0 9m17s openshift-kube-proxy-frpzw 1/1 Running 0 9m17s openshift-kube-proxy-lbskh 1/1 Running 0 9m17s Then look at the qosClass in the status of one of the pods: $ oc get pod openshift-kube-proxy-89h2b -o jsonpath='{ .status.qosClass }' -n openshift-kube-proxy Burstable which means the bug is fixed. It was previously BestEffort, which was causing the e2e failure.
ok, thanks Cesar . then move this bug to verified.
Will this fix be cherry-picked to 4.3 and 4.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/RHBA-2020:2409