-
Notifications
You must be signed in to change notification settings - Fork 151
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
feat: disruption controls by reason #991
feat: disruption controls by reason #991
Conversation
Skipping CI for Draft Pull Request. |
f7dea78
to
18c8dee
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.
Left some preliminary comments, but I anticipate this changing after a bit more comments on the RFC so I'll hold off for a bit
Pull Request Test Coverage Report for Build 9520161962Warning: This coverage report may be inaccurate.This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.
Details
💛 - Coveralls |
6e5bd23
to
04d9f95
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.
Overall, like the progress here.
My main concern is somewhat confusing difference between the default shared disruption budgets, and the non-shared budgets when multiple reasons are expressed for the same budget (same budget applies to all).
Both of those forms make logical sense on their own, and I would like to be able to create a budget to get mirrored by multiple reasons. However, I don't think the existing "Default" shared budget idea meshes well with that. Wondering if that could be rephased as something like MaxNodePoolDisruption, and always taken into account as an overall shared max disruption regardless of what the individual reasons disruptions were. I think this area need a bit more design to finalize.
Default now is just when its unspecified and meshes with the idea fine imo. I updated the design doc to explain this relationship a bit better. LMK if you have any strong opinions |
5458e56
to
6b06089
Compare
…isruption commands fix: ignoring emptiness candidates in the single node and multi-node disruption commands Revert "fix: ignoring emptiness candidates in the single node and multi-node disruption commands" This reverts commit b88efe7.
…i-node disruption commands" This reverts commit db8c8ab.
…lidation controllers
Co-authored-by: Nick Tran <10810510+njtran@users.noreply.github.com>
Co-authored-by: Nick Tran <10810510+njtran@users.noreply.github.com>
8e8ac29
to
da22d40
Compare
This reverts commit da22d40.
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.
Just one comment. The other nits should be fine. I'll approve after the last comment :)
Co-authored-by: Nick Tran <10810510+njtran@users.noreply.github.com>
Co-authored-by: Nick Tran <10810510+njtran@users.noreply.github.com>
…ingle and multi node consolidation
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
/approve
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: Bryce-Soghigian, njtran 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 |
🥂 |
Fixes #924
Description
This PR implements the design for disruption-controls-by-reason by introducing a new field
Reasons
into the v1beta1 Nodepool API. This change allows users to define lists of reasons alongside their node disruption budgets.These reasons that can be defined are "underutilized", "drifted", "emptied" and "expired" which all correlate with different disruption methods.
How was this change tested?
TODO
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.