[
https://issues.apache.org/jira/browse/YUNIKORN-3319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18102781#comment-18102781
]
Po-Han Shih commented on YUNIKORN-3319:
---------------------------------------
I traced through {{TryPreemption()}} and found the bug: {{initWorkingState()}}
at preemption.go:593 returns the number of cancelled reservations, but the
caller discards it. That means the count from {{cancelMatchingReservations()}}
never reaches the partition-level reservation counter, on any of the six return
paths, including the success path.
I'd like to fix this the way you described in your comment: route the count
through {{{}Application.executeReservationReleasedCallback(){}}}, the callback
YUNIKORN-3321 already added. I also checked the approach from the description,
setting {{AllocationResult.CancelledReservations}} directly, and it runs into
an early return in the queue tree walk that would stop scheduling the rest of
the tree whenever preemption fails. The callback approach avoids that.
{{Test_PreemptForAppOnReservedNode}} in preemption_test.go already exercises
the success path. I'll extend it and add a failure-path test, since a
reservation can be released even when preemption itself doesn't succeed.
Can I get this assigned? I have a PR that is open at
[apache/yunikorn-core#1120|https://github.com/apache/yunikorn-core/issues/1120]
> Reservations released by preemption not tracked
> -----------------------------------------------
>
> Key: YUNIKORN-3319
> URL: https://issues.apache.org/jira/browse/YUNIKORN-3319
> Project: Apache YuniKorn
> Issue Type: Bug
> Components: core - scheduler
> Affects Versions: 1.8.0
> Reporter: Wilfred Spiegelenburg
> Priority: Critical
> Labels: newbie, pull-request-available
>
> During preemption we release old non node requires reservations. These
> releases are made even if we do not preempt. The number of released
> reservations is not accounted for at the partition level.
> TryPreemption needs to return the released reservations in all cases even if
> there is not preemption that happens. This could be an "empty" allocation
> result that just account for the released reservations.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
