You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@yunikorn.apache.org by "Aditya Maheshwari (Jira)" <ji...@apache.org> on 2026/10/16 07:31:00 UTC

[jira] [Updated] (YUNIKORN-3284) Quota Preemption check quota preemption incorrect victim selection

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

Aditya Maheshwari updated YUNIKORN-3284:
----------------------------------------
    Description: 
Test steps -
 # Create a queue {{queue-a}} with max resource limit of 300 and submit an application {{app-a}} with 3 pods to this queue. All pods should come up fine.
 # Update quota of queue-a and set max resource to 250 now (from 300 earlier) with delay of 30 seconds and quotaPreemption enabled.
 # Before the delay expires, submit another application {{app-b}} with resource 50 to {{queue-a}} . As expected {{app-b}} becomes pending as the queue is full.
 # After delay expires, preemption triggers, but instead of pod of {{{}app-a{}}}, pod of {{app-b}} is chosen as victim, which is already in pending state. I think this is done because {{app-b}}

is of 50 and the resource went down by 50 (300->250) in step 2.

So step 4 is not working as expected.

In the end all 3 pods of app-a are running consuming 300, and in configs max resource limit is still 250 set from step 2. This is inconsistent step.

  was:
Test steps - # Create a queue {{queue-a}} with max resource limit of 300 and submit an application {{app-a}} with 3 pods to this queue. All pods should come up fine.
 # Update quota of queue-a and set max resource to 250 now (from 300 earlier) with delay of 30 seconds and quotaPreemption enabled.
 # Before the delay expires, submit another application {{app-b}} with resource 50 to {{queue-a}} . As expected {{app-b}} becomes pending as the queue is full.
 # After delay expires, preemption triggers, but instead of pod of {{{}app-a{}}}, pod of {{app-b}} is chosen as victim, which is already in pending state. I think this is done because {{app-b}}

is of 50 and the resource went down by 50 (300->250) in step 2.

So step 4 is not working as expected.

In the end all 3 pods of app-a are running consuming 300, and in configs max resource limit is still 250 set from step 2. This is inconsistent step.


> Quota Preemption check quota preemption incorrect victim selection
> ------------------------------------------------------------------
>
>                 Key: YUNIKORN-3284
>                 URL: https://issues.apache.org/jira/browse/YUNIKORN-3284
>             Project: Apache YuniKorn
>          Issue Type: Task
>            Reporter: Aditya Maheshwari
>            Assignee: Aditya Maheshwari
>            Priority: Major
>
> Test steps -
>  # Create a queue {{queue-a}} with max resource limit of 300 and submit an application {{app-a}} with 3 pods to this queue. All pods should come up fine.
>  # Update quota of queue-a and set max resource to 250 now (from 300 earlier) with delay of 30 seconds and quotaPreemption enabled.
>  # Before the delay expires, submit another application {{app-b}} with resource 50 to {{queue-a}} . As expected {{app-b}} becomes pending as the queue is full.
>  # After delay expires, preemption triggers, but instead of pod of {{{}app-a{}}}, pod of {{app-b}} is chosen as victim, which is already in pending state. I think this is done because {{app-b}}
> is of 50 and the resource went down by 50 (300->250) in step 2.
> So step 4 is not working as expected.
> In the end all 3 pods of app-a are running consuming 300, and in configs max resource limit is still 250 set from step 2. This is inconsistent step.



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

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@yunikorn.apache.org
For additional commands, e-mail: issues-help@yunikorn.apache.org