[
https://issues.apache.org/jira/browse/YARN-4719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15176644#comment-15176644
]
Karthik Kambatla commented on YARN-4719:
----------------------------------------
[~leftnoteasy] - thanks for chiming in, you make some valid points.
Since we are building a library for node tracking, I would like for us to
restrict access to the map/set of nodes tracked only through addNode and
removeNode so total_cluster_resources, total_inflated_cluster_resources (for
YARN-1011), max_cluster_resources are not affected by other scheduler code. Do
you think this is a reasonable goal? At least, as long as it doesn't hurt
performance?
If yes, we should decide on how to handle cases where the scheduler code needs
to iterate through the nodes: (1) we could provide a snapshot copy of the
map/set of nodes/nodeIds, or (2) provide a way to do the same with the right
locks by adding additional methods or an abstraction (similar to lambdas) that
applies to multiple methods.
Thoughts?
PS: By the way, thanks for pointing out the javadoc for values(). I will clean
that up based on the discussion output here.
> Add a helper library to maintain node state and allows common queries
> ---------------------------------------------------------------------
>
> Key: YARN-4719
> URL: https://issues.apache.org/jira/browse/YARN-4719
> Project: Hadoop YARN
> Issue Type: Improvement
> Components: scheduler
> Affects Versions: 2.8.0
> Reporter: Karthik Kambatla
> Assignee: Karthik Kambatla
> Attachments: yarn-4719-1.patch, yarn-4719-2.patch, yarn-4719-3.patch
>
>
> The scheduler could use a helper library to maintain node state and allowing
> matching/sorting queries. Several reasons for this:
> # Today, a lot of the node state management is done separately in each
> scheduler. Having a single library will take us that much closer to reducing
> duplication among schedulers.
> # Adding a filtering/matching API would simplify node labels and locality
> significantly.
> # An API that returns a sorted list for a custom comparator would help
> YARN-1011 where we want to sort by allocation and utilization for
> continuous/asynchronous and opportunistic scheduling respectively.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)