[
https://issues.apache.org/jira/browse/YUNIKORN-1929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17757849#comment-17757849
]
Manikandan R edited comment on YUNIKORN-1929 at 8/23/23 7:02 AM:
-----------------------------------------------------------------
{quote}> 4. If we increase resource usage again, the system will pass. However,
at this moment, the real resource usage is 100 memory/vocres and it's more than
the wildcard limit.
{quote}
Once config has been changed for the removal of "group2", we remove the usage
completely. After the config change and usage increase (after 4th step),
"group2" usage should be memory: 50, vcores: 50. In the next increase,
"group2" usage won't be increased further and it throws an error saying "unable
to run.." etc because of wild card group limit settings.
IMO, just because wild card is there during the removal of existing group
"group2" doesn't mean that we should that consider the past usage of that group
before the config change for future decision making process. These kind of
covering edge cases increases the code complexity given the benefit we would be
getting from this change.
[~wilfreds] Can you please share your thoughts?
was (Author: mani):
{quote}> 4. If we increase resource usage again, the system will pass. However,
at this moment, the real resource usage is 100 memory/vocres and it's more than
the wildcard limit.
{quote}
Once config has been changed for the removal of "group2", we remove the usage
completely. After the config change and usage increase (after 4th step),
"group2" usage should be memory: 50, vcores: 50. In the next increase,
"group2" usage won't be increased further and it throws an error saying "unable
to run.." etc because of wild card group limit settings.
IMO, just because wild card is there during the removal of existing group
"group2" doesn't mean that we should that consider the past usage of that group
before the config change for future decision making process. These kind of
covering edge cases increases the code complexity given the benefit we would be
getting from this change.
@wilfreds Can you please share your thoughts?
> Keep group tracker if it's from a specific limit to wildcard limit
> ------------------------------------------------------------------
>
> Key: YUNIKORN-1929
> URL: https://issues.apache.org/jira/browse/YUNIKORN-1929
> Project: Apache YuniKorn
> Issue Type: Sub-task
> Components: core - scheduler
> Reporter: PoAn Yang
> Assignee: PoAn Yang
> Priority: Major
> Fix For: 1.4.0
>
>
> Currently, the user/group manager can't pass the following case:
> 1. Create a queue with the following limits:
>
> {noformat}
> limits:
> - limit: "specific groups"
> groups:
> - group1
> - group2
> maxresources:
> memory: 100
> vcores: 100
> maxapplications: 2
> - limit: "wildcard"
> groups:
> - *
> maxresources:
> memory: 50
> vcores: 50
> maxapplications: 1{noformat}
> 2. Increase resource usage (memory: 50, vcores: 50) for group1 and group2.
> 3. Remove "group2" from the "specific groups" limit and update the config.
> The "group2" tracker will be removed.
> 4. If we increase resource usage again, the system will pass. However, at
> this moment, the real resource usage is 100 memory/vocres and it's more than
> the wildcard limit.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
