[
https://issues.apache.org/jira/browse/YARN-7437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16238505#comment-16238505
]
Wangda Tan commented on YARN-7437:
----------------------------------
Thanks [~kkaranasos] for suggestions.
For your renaming suggestions:
bq. I think we should rename the SchedulingSet to something like
CandidateNodeSet, or anything that has NodeSet or NodeSetIterator in it.
I'm fine with CandidateNodeSet/NodeSet, I would prefer CandidateNodeSet over
NodeSet.
bq. For the SchedulingPlacementSet, I think we should have in the name
something about the App ..
I would prefer to have {{AppXYZPlacement}}, such as {{AppLocalityPlacement}}.
I'm fine with your points of removing Strategy from class name. And
AppSchedulingXYZ sounds too similar to AppSchedulingInfo, that's way I don't
prefer it.
For your "offtopic" comment:
bq. As in, you give it multiple nodes, and then it decides what is the right
one, based on its implementation. For example, you have locality placement, you
give it a bunch of nodes, then internally the SchedulingPlacementSet decides
which is the best of these nodes to use for each outstanding request.
So what you meant is, we will not explicitly call the
{{getPreferredNodeIterator}} from external, instead SchedulingPlacementSet
itself will cache the candidate and give ordering of preferred nodes based on
whatever it logics, correct?
I think your suggestion makes sense if we want to do multi-nodes look up
instead of single node since set of nodes available in the cluster won't change
rapidly. And we can keep internal cache of the pre-sorted results to be more
stable. The previous reason of invoking this from external is for back-ward
compatible to single-node cases.
I'm not sure what is the best API design to make sure both works. Probably we
can delay this once we start exploring multi-nodes allocations. (Hopefully we
can start soon if you guys also consider the SchedulingPlacementSet as an
option :)).
> Give SchedulingPlacementSet to a better name.
> ---------------------------------------------
>
> Key: YARN-7437
> URL: https://issues.apache.org/jira/browse/YARN-7437
> Project: Hadoop YARN
> Issue Type: Sub-task
> Reporter: Wangda Tan
> Assignee: Wangda Tan
> Priority: Major
>
> Currently, the SchedulingPlacementSet is very confusing. Here're its
> responsibilities:
> 1) Store ResourceRequests. (Or SchedulingRequest after YARN-6592).
> 2) Decide order of nodes to allocate when there're multiple node candidates.
> 3) Decide if we should reject node for given requests.
> 4) Store any states/cache can help make decision for #2/#3
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
