Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1945258

Summary: [sig-arch] Managed cluster should ensure control plane pods do not run in best-effort QoS [Suite:openshift/conformance/parallel]
Product: OpenShift Container Platform Reporter: Tinashe Chipomho <tchipomh>
Component: Performance Addon OperatorAssignee: Martin Sivák <msivak>
Status: CLOSED DUPLICATE QA Contact: Gowrishankar Rajaiyan <grajaiya>
Severity: medium Docs Contact:
Priority: low    
Version: 4.7CC: aos-bugs, browsell, eparis, jokerman, mfojtik, mniranja, sscheink
Target Milestone: ---   
Target Release: ---   
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: 2021-06-10 10:28:45 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:
Embargoed:
Bug Depends On: 1957291    
Bug Blocks:    

Description Tinashe Chipomho 2021-03-31 14:42:04 UTC
Description of problem:
Running conformance tests on ocp4.7 with RAN DU profile results in 15 important pods found in best-effort QoS: 

Version-Release number of selected component (if applicable):

Client Version: 4.7.0-0.nightly-2021-03-14-223051
Server Version: 4.7.0-0.nightly-2021-03-14-223051
Kubernetes Version: v1.20.0+bafe72f

How reproducible:
Run origin-tests against an ipv6 only enabled cluster. 

Steps to Reproduce:
1. ./openshift-tests run openshift/conformance/parallel --junit-dir . --

Actual results:
fail [github.com/onsi/ginkgo.0-origin.0+incompatible/internal/leafnodes/runner.go:113]: Mar 29 09:15:24.140:
15 pods found in best-effort QoS:
openshift-machine-api/metal3-774c8bfd9b-ftmj4 is running in best-effort QoS
openshift-machine-api/metal3-image-cache-9gzt6 is running in best-effort QoS
openshift-machine-api/metal3-image-cache-drh82 is running in best-effort QoS
openshift-machine-api/metal3-image-cache-p5xpg is running in best-effort QoS
openshift-performance-addon-operator/performance-operator-78b87bff97-2x4d2 is running in best-effort QoS
openshift-ptp/ptp-operator-6dd69bd8b6-l6s2t is running in best-effort QoS
openshift-sriov-network-operator/network-resources-injector-4dnwd is running in best-effort QoS
openshift-sriov-network-operator/network-resources-injector-dswh9 is running in best-effort QoS
openshift-sriov-network-operator/network-resources-injector-vg8cc is running in best-effort QoS
openshift-sriov-network-operator/operator-webhook-5zkbt is running in best-effort QoS
openshift-sriov-network-operator/operator-webhook-mwzzh is running in best-effort QoS
openshift-sriov-network-operator/operator-webhook-qpmb5 is running in best-effort QoS
openshift-sriov-network-operator/sriov-network-config-daemon-bdgsf is running in best-effort QoS
openshift-sriov-network-operator/sriov-network-config-daemon-hq5q6 is running in best-effort QoS
openshift-sriov-network-operator/sriov-network-operator-d55f94ddc-m2kq4 is running in best-effort QoS

Expected results:
 [sig-arch] Managed cluster should ensure control plane pods do not run in best-effort QoS [Suite:openshift/conformance/parallel] should pass. 

Additional info:

Comment 1 Federico Paolinelli 2021-03-31 14:49:31 UTC
CNF Platform Validation is the component for bugs related to the CNF-Tests container image, that we ship to users.
Please use it only for bugs related to that compoment.

Comment 3 Tinashe Chipomho 2021-04-12 08:22:47 UTC
(In reply to Federico Paolinelli from comment #1)
> CNF Platform Validation is the component for bugs related to the CNF-Tests
> container image, that we ship to users.
> Please use it only for bugs related to that compoment.

Noted

Comment 5 Stefan Schimanski 2021-04-15 10:19:47 UTC
These are bugs of the respective operators. Please assign to them before opening a generic bug.

Comment 7 Tinashe Chipomho 2021-05-07 08:26:39 UTC
(In reply to Stefan Schimanski from comment #5)
> These are bugs of the respective operators. Please assign to them before
> opening a generic bug.

I have created 2 bugs for SR-IOV https://bugzilla.redhat.com/show_bug.cgi?id=1958107 and ptp https://bugzilla.redhat.com/show_bug.cgi?id=1958105. 

For openshift-machine-api/metal3-774c8bfd9b-ftmj4 is running in best-effort QoS which components should I select if you could assist on that?

Comment 8 Tinashe Chipomho 2021-05-07 08:31:09 UTC
(In reply to Stefan Schimanski from comment #5)
> These are bugs of the respective operators. Please assign to them before
> opening a generic bug.

I have created 2 bugs for SR-IOV https://bugzilla.redhat.com/show_bug.cgi?id=1958107 and ptp https://bugzilla.redhat.com/show_bug.cgi?id=1958105. 

For openshift-machine-api/metal3-774c8bfd9b-ftmj4 is running in best-effort QoS which components should I select if you could assist on that?

Comment 9 Martin Sivák 2021-05-07 10:12:15 UTC
I think I need a bit more context here.

- The test is reporting that PAO runs as best effort pod. And it is right.
- But I would like to base a fix on something more than just a test failure. Is there documentation related to how should infra pods be set up? Does the rule apply to optional operators?


Also - could this failure be related to us not setting the cpu requirements for the operator pod? In other words, is this a different symptom of https://bugzilla.redhat.com/1957291 ?

Comment 10 Tinashe Chipomho 2021-05-07 12:53:24 UTC
(In reply to Martin Sivák from comment #9)
> I think I need a bit more context here.
> 
> - The test is reporting that PAO runs as best effort pod. And it is right.
> - But I would like to base a fix on something more than just a test failure.
> Is there documentation related to how should infra pods be set up? Does the
> rule apply to optional operators?
> 
> 
> Also - could this failure be related to us not setting the cpu requirements
> for the operator pod? In other words, is this a different symptom of
> https://bugzilla.redhat.com/1957291 ?

You have raised valid points. So the work I was doing was conformance/validation work against RAN deployments in an IPv6 only cluster and to the best of my knowledge there is no infra doc for how pods should be deployed. 

Given that best effort QoS class occurs when the containers in the Pod do not have any memory or CPU limits or requests, dealing with https://bugzilla.redhat.com/1957291 could probably solve this test failure.

Comment 11 Martin Sivák 2021-06-10 10:28:45 UTC

*** This bug has been marked as a duplicate of bug 1957291 ***

Comment 13 Red Hat Bugzilla 2023-09-15 01:04:28 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 500 days