Add prioritization of conflicting constraints #293
Conversation
internal/core/logic_test.go
Outdated
| check( | ||
| "low=20%, high=80%, crit=95%, step=20%, min=1100", | ||
| "size=1000, usage=500, smax=900", | ||
| "low->800", "low->900", // StrictMaximumSize takes precedence over minimum constraint |
There was a problem hiding this comment.
I understand why percentage-step resizing goes to 800 here, but I feel weird about StrictMaximumSize = 900 causing a downsize to 800 here. If the downsize goes through, we will upsize back to 900 immediately afterwards (right?). So I would rather have it go to 900 in both cases.
| "low->800", "low->900", // StrictMaximumSize takes precedence over minimum constraint | |
| "low->900", "low->900", // StrictMaximumSize takes precedence over minimum constraint |
Having said that, if this turns out to be too difficult to do in this PR without making invasive changes, I'm fine with putting this down as a TODO for later. There are more things to do in the constraint engine soon anyway.
There was a problem hiding this comment.
In this particular case, there wouldn't be an immediate upsize afterwards, since the new usage would be 62,5% which is within all the thresholds.
check( "low=20%, high=80%, crit=95%, step=20%, min=1100", "size=1000, usage=800, smax=900", "low->900", "low->900", // StrictMaximumSize takes precedence over minimum constraint )
In the case that the forced downsize operation would cross the high threshold, the percentage step strategy will also downsize to 900.
internal/core/logic_test.go
Outdated
| check( | ||
| "low=20%, high=80%, crit=95%, step=20%, max=1100", | ||
| "size=1000, usage=990, smax=1050", | ||
| "critical->1050", "critical->1050", // StrictMaximumSize takes precedence over maximum constraint | ||
| ) |
There was a problem hiding this comment.
For what it's worth, this test does not establish that "StrictMaximumSize takes precedence over maximum constraint". In fact, two maximum constraints cannot really take precedence over each other. If there is no lower bound, the strongest upper bound will always win. So this testcase would have the same result if the values for max and smax were swapped.
No description provided.