-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Split out step resource request management #1655
Conversation
2b86b0a
to
b247d4b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: vdemeester 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 |
Before this change, all steps' resource requests (*not* limits) were zeroed out unless that value for that metric represented the maximum across all steps. If step 2 requested the maximum memory of all steps, but not the max CPU, its memory request would persist but its CPU request would be zeroed out. After this change, the max request for each resource type (CPU, memory, ephermeral storage) is calculated, then applied to the *last* step's container. The effect is the same, unless Pods' resource requests are updated to account for exited containers (afaik they're not), and this is simpler to express and explain. And since all the code for this is in its own method and file, it's easier to test in isolation.
b247d4b
to
4ca967c
Compare
/test pull-tekton-pipeline-integration-tests |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
/test pull-tekton-pipeline-integration-tests |
1 similar comment
/test pull-tekton-pipeline-integration-tests |
Before this change, all steps' resource requests (not limits) were
zeroed out unless that value for that metric represented the maximum
across all steps. If step 2 requested the maximum memory of all steps,
but not the max CPU, its memory request would persist but its CPU
request would be zeroed out.
After this change, the max request for each resource type (CPU, memory,
ephermeral storage) is calculated, then applied to the last step's
container. The effect is the same, unless Pods' resource requests are
updated to account for exited containers (afaik they're not), and this
is simpler to express and explain. And since all the code for this is in
its own method and file, it's easier to test in isolation.
Fixes #1605
Submitter Checklist
These are the criteria that every PR should meet, please check them off as you
review them:
See the contribution guide for more details.