UPSTREAM: <carry>: OCPEDGE-807: add support for cpu limits into management workloads #1902
Conversation
openshift-ci-robot
added
the
backports/unvalidated-commits
openshift-ci
bot
added
the
do-not-merge/work-in-progress
openshift-ci-robot
added
the
jira/valid-reference
|
@eggfoobar: This pull request references OCPEDGE-807 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.16.0" version, but no target version was set. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
|
@eggfoobar: the contents of this pull request could not be automatically validated. The following commits could not be validated and must be approved by a top-level approver:
Comment |
eggfoobar
force-pushed
the
wrk-prt-support-cpu-limits
branch
from
bc0a3d9
to
5e5504b
Compare
|
@eggfoobar: the contents of this pull request could not be automatically validated. The following commits could not be validated and must be approved by a top-level approver:
Comment |
|
/retest-required |
eggfoobar
force-pushed
the
wrk-prt-support-cpu-limits
branch
from
5e5504b
to
f68d1aa
Compare
|
@eggfoobar: the contents of this pull request could not be automatically validated. The following commits could not be validated and must be approved by a top-level approver:
Comment |
eggfoobar
force-pushed
the
wrk-prt-support-cpu-limits
branch
from
f68d1aa
to
9e9a65a
Compare
|
@eggfoobar: the contents of this pull request could not be automatically validated. The following commits could not be validated and must be approved by a top-level approver:
Comment |
|
/retest-required |
eggfoobar
force-pushed
the
wrk-prt-support-cpu-limits
branch
from
9e9a65a
to
4180aa1
Compare
|
@eggfoobar: the contents of this pull request could not be automatically validated. The following commits could not be validated and must be approved by a top-level approver:
Comment |
eggfoobar
force-pushed
the
wrk-prt-support-cpu-limits
branch
from
4180aa1
to
e3403c4
Compare
|
@eggfoobar: the contents of this pull request could not be automatically validated. The following commits could not be validated and must be approved by a top-level approver:
Comment |
eggfoobar
changed the title
openshift-ci
bot
removed
the
do-not-merge/work-in-progress
|
/hold Holding for Crio Change to be merged in, cri-o/cri-o#7822 |
openshift-ci
bot
added
the
do-not-merge/hold
openshift-kube-apiserver/admission/autoscaling/managementcpusoverride/admission.go
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
this change seems to also modify how the code detects and manages the QoS class. Is part functional to the handling of the limits? If so, could you please explain why?
would it possible to move this logic change in its own commit, and is this part covered by existing tests?
| // and add a warning annotation | ||
| resourceAnnoString, err := json.Marshal(resourceAnno) | ||
| if err != nil { | ||
| podAnnotations[workloadAdmissionWarning] = fmt.Sprintf("failed to marshal cpu resources, using fallback: err: %s", err.Error()) |
There was a problem hiding this comment.
do we want to set a warning as annotation?
There was a problem hiding this comment.
Yeah wasn't 100% sure what to do here, I wanted to make it easy to identify if it cropped up in the wild, even though it's highly improbable, maybe a simple log would be good enough here, unless we feel firing off an event would be more appropriate.
There was a problem hiding this comment.
Just for clarity @ffromani , do you mean in general the use of annotations for warning in this webhook?
There was a problem hiding this comment.
I mean it feels weird to add warning data as annotation. Is the user supposed to look at annotations checking for warninga? Not sure there's a better alternative though, so this comment is not blocking.
|
@eggfoobar: This pull request references OCPEDGE-807 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.16.0" version, but no target version was set. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
|
@eggfoobar: This pull request references OCPEDGE-807 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.16.0" version, but no target version was set. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
1 similar comment
|
@eggfoobar: This pull request references OCPEDGE-807 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.16.0" version, but no target version was set. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
|
@eggfoobar: This pull request references OCPEDGE-807 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.16.0" version, but no target version was set. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
Great questions, I was hoping to simplify the code here and use the existing library code for computing QoS. The original reason for this code being here was because at the time there seemed to only be one for
Edit: After going through the code again, I realized one of the concerns brought up in the original comment on how the defaulter behaves was not accounted for in the new QoS package. I reverted that code and kept this commit to just the cpu limit change. |
|
/retest-required |
|
LGTM |
openshift-ci
bot
added
backports/validated-commits
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: eggfoobar, ffromani, soltysh The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
/retest-required |
2 similar comments
|
/retest-required |
|
/retest-required |
|
/retest-required |
3 similar comments
|
/retest-required |
|
/retest-required |
|
/retest-required |
|
/hold Revision c652a1d was retested 3 times: holding |
openshift-ci
bot
added
the
do-not-merge/hold
|
/unhold Both errors are due to quota slices |
openshift-ci
bot
removed
the
do-not-merge/hold
|
/retest-required Issue seems to have been resolved, retesting |
|
/retest-required |
|
@eggfoobar: all tests passed! Full PR test history. Your PR dashboard. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
Added support to allow workload partitioning to use the CPU limits for a container, to allow the runtime to make better decisions around workload cpu quotas we are passing down the cpu limit as part of the cpuLimitMilli value in the annotation. CRI-O will take that information and calculate the quota per node. This should support situations where workloads might have different cpu period overrides assigned.
Enhancement Proposal
OCPEDGE-57
What type of PR is this?
What this PR does / why we need it:
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?
Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.: