[ 
https://issues.apache.org/jira/browse/YUNIKORN-3148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Peter Bacsko updated YUNIKORN-3148:
-----------------------------------
    Description: 
 YUNIKORN-2794 introduced a bug in the Application code. We're no longer 
mutating the {{headRoom}} object in-place in 
{{{}Application.getOutstandingRequests(){}}}, instead, we re-assign its value 
to a new variable.

Before:
{noformat}
headRoom.SubOnlyExisting(request.GetAllocatedResource())
userHeadRoom.SubOnlyExisting(request.GetAllocatedResource()) {noformat}
After:
{noformat}
headRoom = resources.SubOnlyExisting(headRoom, request.GetAllocatedResource())
userHeadRoom = resources.SubOnlyExisting(userHeadRoom, 
request.GetAllocatedResource())  {noformat}
Problem is, this does not change the object pointed to outside the function, so 
every iteration in {{Queue.GetQueueOutstandingRequests()}} starts with the 
original {{headRoom}} value for every application. This leads to undesired 
behavior, because we'll end up collecting more asks than needed, which in turn 
triggers unnecessary cluster upscale.

  was:
 YUNIKORN-2794 introduced a bug in the Application code. We're no longer 
mutating the {{headRoom}} object in-place in 
{{{}Application.getOutstandingRequests(){}}}, instead, we re-assign its value 
to a new variable.

Before:
{noformat}
headRoom.SubOnlyExisting(request.GetAllocatedResource())
userHeadRoom.SubOnlyExisting(request.GetAllocatedResource()) {noformat}
After:
{noformat}
headRoom = resources.SubOnlyExisting(headRoom, request.GetAllocatedResource())
userHeadRoom = resources.SubOnlyExisting(userHeadRoom, 
request.GetAllocatedResource())
  {noformat}
Problem is, this does not change the object pointed to outside the function, so 
every iteration in {{Queue.GetQueueOutstandingRequests()}} starts with the 
original {{headRoom}} value for every application. This leads to undesired 
behavior, because we'll end up collecting more asks than needed, which in turn 
triggers unnecessary cluster upscale.


> Incorrect headroom calculation when collecting outstanding requests
> -------------------------------------------------------------------
>
>                 Key: YUNIKORN-3148
>                 URL: https://issues.apache.org/jira/browse/YUNIKORN-3148
>             Project: Apache YuniKorn
>          Issue Type: Improvement
>          Components: core - scheduler
>            Reporter: Peter Bacsko
>            Assignee: Peter Bacsko
>            Priority: Critical
>
>  YUNIKORN-2794 introduced a bug in the Application code. We're no longer 
> mutating the {{headRoom}} object in-place in 
> {{{}Application.getOutstandingRequests(){}}}, instead, we re-assign its value 
> to a new variable.
> Before:
> {noformat}
> headRoom.SubOnlyExisting(request.GetAllocatedResource())
> userHeadRoom.SubOnlyExisting(request.GetAllocatedResource()) {noformat}
> After:
> {noformat}
> headRoom = resources.SubOnlyExisting(headRoom, request.GetAllocatedResource())
> userHeadRoom = resources.SubOnlyExisting(userHeadRoom, 
> request.GetAllocatedResource())  {noformat}
> Problem is, this does not change the object pointed to outside the function, 
> so every iteration in {{Queue.GetQueueOutstandingRequests()}} starts with the 
> original {{headRoom}} value for every application. This leads to undesired 
> behavior, because we'll end up collecting more asks than needed, which in 
> turn triggers unnecessary cluster upscale.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to