[
https://issues.apache.org/jira/browse/YARN-6593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16021971#comment-16021971
]
Konstantinos Karanasos commented on YARN-6593:
----------------------------------------------
bq. If the scheduler can handle a single class efficiently, we don't need a
separate representation in scheduler side. However as I stated, we don't know
this yet.
We should then create subclasses (that will not be consistent with the
protobufs) only once we get convinced that they will lead to more efficient
implementation. Why add subclasses without knowing this is true?
The users will see different constraint types through the builder, as in
{{addTargetConstraint}}, {{addCardinalityConstraint}}. If we see that adding
them as subclasses is important for implementation, we can sure go ahead and
add them later. The API in the builders will not need to change.
> [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
