[
https://issues.apache.org/jira/browse/YUNIKORN-1603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17706770#comment-17706770
]
Manikandan R commented on YUNIKORN-1603:
----------------------------------------
Hi [~zhuqi],
Did we handle the below case? If config has wildcard group limit then there
must be one more limit setting for group with specific name defined in the
config. If not, Can we please file a jira for this?
*Specifying a wildcard for the group limit sets a cumulative limit for all
users in that queue. If there is no specific group mentioned the wildcard group
limit would thus be the same as the queue limit. For that reason we do not
allow specifying only one group limit that is using the wildcard. There must be
at least one limit with a group name defined.*
> Configuration processing to support limit new wildcard interpretation syntax
> checking
> -------------------------------------------------------------------------------------
>
> Key: YUNIKORN-1603
> URL: https://issues.apache.org/jira/browse/YUNIKORN-1603
> Project: Apache YuniKorn
> Issue Type: Sub-task
> Reporter: Qi Zhu
> Assignee: Qi Zhu
> Priority: Major
> Labels: pull-request-available
>
> h3. Wildcard interpretation
> Wildcard can only be used as the only entry in the limit object according to
> the documentation. There can be multiple limit objects in the overall limits
> for a queue. As part of this design the interpretation of the wildcard needs
> to be defined. Wildcards interpretation is related to the ordering of the
> limit objects in the overall limits object. The usage and interpretation will
> be different for users and groups.
> In general terms: allowing a wildcard in the user or group list only as part
> of the last entry of the limits list. After the wildcard has been added for
> either the user or group list we do not allow a user or group list with a non
> wildcard entry. This is especially important for the group resolution. It
> does allow specifying a user _and_ group wildcard with different limits set.
> In all cases, there will only be a match using the wildcard if none of the
> earlier limit entries match.
> As part of the already existing queue configuration processing the syntax for
> the configuration is checked. This check is triggered also for a reload of
> the file, via the config map. Rudimentary limit object checking is
> implemented as part of the config check.
>
> The above described changes around the wildcards and what is allowed is not
> part of the configuration validation and must be added.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
