-
Notifications
You must be signed in to change notification settings - Fork 531
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
Add Sanity limits for persistent volumes #2051
Add Sanity limits for persistent volumes #2051
Conversation
pkg/costmodel/allocation_helpers.go
Outdated
const CPU_SANITY_LIMIT = 512 | ||
|
||
// Sanity Limit for PV usage, set to 10 PB, in bytes for now | ||
const PV_USAGE_SANITY_LIMIT = 10737418240 |
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.
Very small nit -- can we add _BYTES
to the end of the name here? Trying to get the whole team on board for adding units to names when we can, to avoid ambiguity.
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.
Absolutely, that's a sensible semantic change
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.
Thank you!
7eb7c4d
to
90626df
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.
Just one thing to double-check here. (And I may be reading it backwards.)
pkg/costmodel/allocation_helpers.go
Outdated
pvBytesUsed := res.Values[0].Value | ||
if pvBytesUsed >= PV_USAGE_SANITY_LIMIT { | ||
pvMap[key].Bytes = pvBytesUsed | ||
} else { | ||
pvMap[key].Bytes = 0 | ||
log.Infof("[WARNING] PV usage exceeds sanity limit, clamping to zero") | ||
} |
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.
This looks backwards to me -- can we double-check? If the measured bytes exceed the limit, we want to clamp; if they do not exceed, we want to use the measured value, right?
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.
Yep, I accidentally swapped that, it's fixed now
… burndown list. Would benefit from actual outlier detection or clamping instead of just using a sanity limit. Signed-off-by: Ashleigh <ashleigh@kubecost.com>
90626df
to
cc43a99
Compare
What does this PR change?
Does this PR relate to any other PRs?
How will this PR impact users?
Does this PR address any GitHub or Zendesk issues?
How was this PR tested?
Does this PR require changes to documentation?
Have you labeled this PR and its corresponding Issue as "next release" if it should be part of the next OpenCost release? If not, why not?