[
https://issues.apache.org/jira/browse/YARN-6594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16081225#comment-16081225
]
Arun Suresh commented on YARN-6594:
-----------------------------------
I agree.. AMRMClient is starting to get very heavy.
But fundamentally, I guess the biggest reason for the code bloat is:
# AMRMClient has to handle transformation of a ContainerRequest to the
corresponding ResourceRequests (the node/rack and ANY reqs) - I currently don't
know how we can do this transparantly to the end application. I propose we make
ContainerRequest a first class YARN API and deprecate the ResourceRequest
object.
# On RM failover etc, the AMRMClient ensures that the AM re-registers and it
also ensures that outstanding requests are resent.
[~subru] and I were discussing issues related to failover in a federated setup
- and we were thinking the same thing: deprecate AMRMClient
> [API] Introduce SchedulingRequest object
> ----------------------------------------
>
> Key: YARN-6594
> URL: https://issues.apache.org/jira/browse/YARN-6594
> Project: Hadoop YARN
> Issue Type: Sub-task
> Reporter: Konstantinos Karanasos
> Assignee: Konstantinos Karanasos
> Attachments: YARN-6594.001.patch
>
>
> This JIRA introduces a new SchedulingRequest object.
> It will be part of the {{AllocateRequest}} and will be used to define sizing
> (e.g., number of allocations, size of allocations) and placement constraints
> for allocations.
> Applications can use either this new object (when rich placement constraints
> are required) or the existing {{ResourceRequest}} object.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
