Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Add prioritization of conflicting constraints #293

Draft
wants to merge 2 commits into
base: master
Choose a base branch
from
+68 −32
Draft

Add prioritization of conflicting constraints #293

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
8eb4990
Add prioritization of conflicting constraints
Varsius Oct 22, 2024
003a27e
Remove pointless constraint unit tests
Varsius Nov 1, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
41 changes: 26 additions & 15 deletions internal/core/logic.go
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -121,17 +121,6 @@ func GetEligibleOperations(res ResourceLogic, asset AssetStatus) map[castellum.O
func checkReason(res ResourceLogic, asset AssetStatus, reason castellum.OperationReason) *uint64 {
// phase 1: generate global constraints
//
//NOTE: We only add MinimumSize as a constraint for downsizing. For upsizing,
// it's okay if the target is below MinimumSize. It just means we're inching
// closer *towards* the happy area. (And vice versa for MaximumSize.)
c := emptyConstraints()
if reason == castellum.OperationReasonLow && res.MinimumSize != nil {
c.forbidBelow(*res.MinimumSize)
}
if reason != castellum.OperationReasonLow && res.MaximumSize != nil {
c.forbidAbove(*res.MaximumSize)
}

// We have a bunch of constraints that can cause action if they are crossed:
//- On the Asset, StrictMinimumSize and StrictMaximumSize values describe
// technical constraints that the raw usage numbers cannot represent.
Expand All @@ -140,10 +129,23 @@ func checkReason(res ResourceLogic, asset AssetStatus, reason castellum.Operatio
//
// Because the logic for all of these is identical, we start out by merging
// them (strongest constraint wins).
// Priority 0: StrictMinimumSize, StrictMaximumSize
// Priority 1: MinimumFreeSize, MinimumSize, MaximumSize
c := emptyConstraints()

enforceableMaxSize := asset.StrictMaximumSize
if reason != castellum.OperationReasonLow && enforceableMaxSize != nil {
c.forbidAbove(*enforceableMaxSize)
}

enforceableMinSize := asset.StrictMinimumSize
if res.MinimumFreeSize != nil {
for _, metric := range res.UsageMetrics {
minSize := *res.MinimumFreeSize + uint64(math.Ceil(asset.Usage[metric]))
// Only apply MinimumFreeSize constraint if there is no conflict with strict constraints
if enforceableMaxSize != nil && *enforceableMaxSize < minSize {
continue
}
if enforceableMinSize == nil || *enforceableMinSize < minSize {
enforceableMinSize = &minSize
}
Expand All @@ -153,9 +155,18 @@ func checkReason(res ResourceLogic, asset AssetStatus, reason castellum.Operatio
c.forbidBelow(*enforceableMinSize)
}

enforceableMaxSize := asset.StrictMaximumSize
if reason != castellum.OperationReasonLow && enforceableMaxSize != nil {
c.forbidAbove(*enforceableMaxSize)
//NOTE: We only add MinimumSize as a constraint for downsizing. For upsizing,
// it's okay if the target is below MinimumSize. It just means we're inching
// closer *towards* the happy area. (And vice versa for MaximumSize.)
if reason == castellum.OperationReasonLow && res.MinimumSize != nil {
if asset.StrictMaximumSize == nil || *res.MinimumSize < *asset.StrictMaximumSize {
c.forbidBelow(*res.MinimumSize)
}
}
if reason != castellum.OperationReasonLow && res.MaximumSize != nil {
if asset.StrictMinimumSize == nil || *asset.StrictMinimumSize < *res.MaximumSize {
c.forbidAbove(*res.MaximumSize)
}
}

// do not allow downsize operations to cross above the high/critical thresholds
Expand Down Expand Up @@ -235,7 +246,7 @@ func checkReason(res ResourceLogic, asset AssetStatus, reason castellum.Operatio
}

if reason == enforcer {
a.AddAction(action{Min: *enforceableMinSize, Desired: *enforceableMinSize}, *c)
a.AddAction(action{Desired: *enforceableMinSize}, *c)
// We also let the rest of this method behave as if the `high` threshold
// was crossed. The percentage-step resizing may generate a larger
// target size than this action right now did, in which case it will
Expand Down
67 changes: 51 additions & 16 deletions internal/core/logic_test.go
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -333,31 +333,66 @@ func TestGetEligibleOperations(t *testing.T) {

// test conflicts between constraints
//
// Entirely conflicting constraints (max < min) shall paralyze Castellum and
// suppress all actions.
// Entirely conflicting constraints of equal priority shall paralyze Castellum and
// suppress all actions. Otherwise, the stronger constraint should be enforced.
// Priority 0: StrictMinimumSize, StrictMaximumSize
// Priority 1: MinimumFreeSize, MinimumSize, MaximumSize

check(
"low=20%, high=80%, crit=95%, step=200%, min=1000",
"size=1000, usage=500, smax=900",
"", "", // MinimumSize is upheld, but StrictMaximumSize is trying to get us to break it
"low=20%, high=80%, crit=95%, step=20%, max=900",
"size=1000, usage=500, smin=1100",
"high->1200", "high->1100", // StrictMinimumSize takes precedence over maximum constraint
)
check(
"low=20%, high=80%, crit=95%, step=200%, min=1000",
"size=900, usage=500, smax=800",
"", "", // MinimumSize is already broken, and StrictMaximumSize is trying to get us to break it further
"low=20%, high=80%, crit=95%, step=20%, min=900",
"size=1000, usage=100, smin=950",
"low->950", "low->950", // StrictMinimumSize takes precedence over minimum constraint
)
check(
"low=20%, high=80%, crit=95%, step=200%, max=1000",
"low=10%, high=80%, crit=95%, step=20%, min_free=550",
"size=1000, usage=500, smin=1100",
"", "", // MaximumSize is upheld, but StrictMinimumSize is trying to get us to break it
"high->1200", "high->1100", // StrictMinimumSize takes precedence over minimum free constraint
)
check(
"low=20%, high=80%, crit=95%, step=200%, max=1000",
"size=1100, usage=500, smin=1200",
"", "", // MaximumSize is already broken, and StrictMinimumSize is trying to get us to break it further
"low=20%, high=80%, crit=95%, step=20%, min_free=200",
"size=1000, usage=900, smax=1050",
"high->1050", "high->1050", // StrictMaximumSize takes precedence over minimum free constraint
)
check(
"low=20%, high=80%, crit=95%, step=20%, min_free=200",
"size=1000, usage=800, smax=900",
"low->900", "low->900", // StrictMaximumSize enforces downsizing over minimum free constraint
)
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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Suggested change
"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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

)
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
)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree.

check(
"low=20%, high=80%, crit=95%, step=20%, max=1050, min_free=600",
"size=1000, usage=500",
"high->1050", "high->1050", // Upsizing due to MinimumFreeSize should not exceed maximum constraint
)
check(
"low=20%, high=80%, crit=95%, step=20%",
"size=1000, usage=500, smin=1100, smax=900",
"", "", // Conflict of strict constrains should result in no action
)
check(
"low=20%, high=80%, crit=95%, step=20%, min=1100, max=900",
"size=1000, usage=990",
"", "", // Conflict of non-strict constrains should prevent upsizing
)
check(
"low=20%, high=80%, crit=95%, step=20%, min=1100, max=900",
"size=1000, usage=100",
"", "", // Conflict of non-strict constrains should prevent downsizing
)

//TODO: change the unit tests above to enforce proper precedence between limiting and enforceable constraints
// (paralysis shall only happen when the conflicting constraints are of equal rank, e.g. `smin > smax`)
}

// Builds a ResourceLogic from a compact string representation like "low=20%, high=80%, step=single, min=200".
Expand Down
Loading