-
Notifications
You must be signed in to change notification settings - Fork 4k
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
Capacity prediction based on physical memory #1643
Conversation
/cc aleksandra-malinowska |
3017a20
to
4792a03
Compare
4792a03
to
be59105
Compare
3d35b87
to
d119e09
Compare
/hold |
56b1f93
to
d1231f1
Compare
d1231f1
to
b178b82
Compare
/lgtm How did you test it? |
b178b82
to
a54b581
Compare
40b3782
to
f054c53
Compare
Skimmed. Seems fine. |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: losipiuk 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 |
assert.False(t, found) | ||
|
||
// Invalidate part of cache in two different ways | ||
provider1.DeleteNodeGroup("ng1") |
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.
nit: doesn't the below call (nodeGroup.Delete()) also call this internally?
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.
It does, with small differences. Those two different way do delete a group test more those mocks than anything else. I think that it is still beneficial to leave it.
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.
Not sure I'm following - Delete() doesn't call DeleteNodeGroup() if and only if callback failed; we aren't checking any error in the below call, do we expect it to fail?
Regarding tests:
Separately, capacity and allocatable calculations were checked against many machine-types and GKE versions 1.11 and 1.12 |
/hold cancel |
/lgtm |
… capacity calculations
… capacity calculations
Cherry-pick of #1643: Capacity prediction based on physical memory
Cherry-pick of #1643: Capacity prediction based on physical memory
… capacity calculations
Cherry-pick of #1643: Capacity prediction based on physical memory
* [multikueue] Add garbage collector. * Fix after rebase * Review Remarks * Extend API description. * Make Origin a global config. * Review Remarks * Use GCInterval in config * Review remarks * Rename gc timeout default const * Review Remarks and UT scenario cleanup. * [config] Make multikueue Origin pointer * Review remarks
No description provided.