[
https://issues.apache.org/jira/browse/YARN-6593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16021836#comment-16021836
]
Konstantinos Karanasos commented on YARN-6593:
----------------------------------------------
[~leftnoteasy], what I am trying to say is that the scheduler does not need to
do any if.
It will handle internally one type of constraint that includes cardinality,
scope, and target. If one of them happens to be a default value (self for
target, 0 for min cardinality, inf for max cardinality), it does not change
anything from the scheduler's perspective. After all the scheduler has to deal
with the constraint that specifies all three fields (what we called operator
constraints in the doc), so it will just duplicate code if we have three ifs.
You see my point?
The end user API can still evolve, as long as it remains backwards compatible.
For instance, when we add the admin constraints, we can simply add an
additional builder utility method, without requiring changes in any other part
of the code. Similar when we do the string representation of the constraints.
If the scheduler does not need to do any if statement (as I explain above),
what is the advantage of having separate classes for each constraint type
(target, cardinality, and targetCardinality/admin)? Is there an implementation
concern?
> [API] Introduce Placement Constraint object
> -------------------------------------------
>
> Key: YARN-6593
> URL: https://issues.apache.org/jira/browse/YARN-6593
> Project: Hadoop YARN
> Issue Type: Sub-task
> Reporter: Konstantinos Karanasos
> Assignee: Konstantinos Karanasos
> Attachments: YARN-6593.001.patch, YARN-6593.002.patch
>
>
> This JIRA introduces an object for defining placement constraints.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
