[
https://issues.apache.org/jira/browse/YARN-4902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15410252#comment-15410252
]
Wangda Tan commented on YARN-4902:
----------------------------------
[~kkaranasos],
Thanks for replying.
It's good to see that we're generally agree with the goal. LRA planning looks
like an implementation, I'm not sure how you plan to do that, we can discuss
more once you get prototype ready for that.
For cardinality, could you share a more detailed use case for that? For
example, why limit #hbase-master within a rack, since different hbase instances
will be used by different applications. If this is to reduce resource
contention (like network resource), we may need to consider solving it by
resource profile (YARN-3926) plus network isolation.
It seems to me that cardinality is a special case of anti-affinity. Typically
anti-affinity kicks in when #container >= 1, if we can set the criteria from 1
to N (N > 1), it is cardinality. If using syntax from our design doc, it looks
like:
{code}
placement_strategy:{
NOT{
placement_set_type:rack,
allocation_tag: hbase_master
maximum-number-container: 10
}
}
{code}
> [Umbrella] Generalized and unified scheduling-strategies in YARN
> ----------------------------------------------------------------
>
> Key: YARN-4902
> URL: https://issues.apache.org/jira/browse/YARN-4902
> Project: Hadoop YARN
> Issue Type: New Feature
> Reporter: Vinod Kumar Vavilapalli
> Assignee: Wangda Tan
> Attachments: Generalized and unified scheduling-strategies in YARN
> -v0.pdf, LRA-scheduling-design.v0.pdf, YARN-5468.prototype.patch
>
>
> Apache Hadoop YARN's ResourceRequest mechanism is the core part of the YARN's
> scheduling API for applications to use. The ResourceRequest mechanism is a
> powerful API for applications (specifically ApplicationMasters) to indicate
> to YARN what size of containers are needed, and where in the cluster etc.
> However a host of new feature requirements are making the API increasingly
> more and more complex and difficult to understand by users and making it very
> complicated to implement within the code-base.
> This JIRA aims to generalize and unify all such scheduling-strategies in YARN.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
