ComputeClass request downscaling for overprovisioning (#2381) #2394
Conversation
keyallis
requested review from
thedadams,
njhale,
StrongMonkey,
sosodev,
iwilltry42,
g-linville and
tylerslaton
There was a problem hiding this comment.
This looks good, I'm trying to imagine a situation where we want to scale up above the defined memory such that 1.25 would be a valid scalar. The thing I'm imagining is where an admin wants to allocate more memory than the user defined. Is that something we'd want?
If not this is good to go in my mind.
| } | ||
|
|
||
| if computeClass != nil { | ||
| cpuQuantity, err := computeclasses.CalculateCPU(*computeClass, memDefault, memoryQuantity) | ||
| cpuQuantity, err := computeclasses.CalculateCPU(*computeClass, memDefault, memoryRequest) |
There was a problem hiding this comment.
Maybe we should also rename this to be cpuRequest as well?
|
I'm just now starting to look at the code, but one thing I am noticing is that |
Signed-off-by: Oscar Ward <[email protected]>
Signed-off-by: Oscar Ward <[email protected]>
#2381
Add support for scaling down memory requests for acorns in relation to memory limits. We handle ComputeClasses that do not have this field set (ie legacy ComputeClasses) as having a 1:1 mapping. This means all existing tests should continue to work and behave as expected, so all new tests are only used to cover the new field itself.
Checklist
This is a title (#1216). Here's an example