[ 
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)

Reply via email to