[ 
https://issues.apache.org/jira/browse/YARN-4902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15241673#comment-15241673
 ] 

Arun Suresh commented on YARN-4902:
-----------------------------------

It is somewhat similar, i agree...
But, I was hoping to decouple the ResourceRequest with the deployment scheme. 
The way I see it, establishment of an application/affinity/server group should 
be part of a deployment schema API separate from the ResourceRequest.

My fear is that coupling allocation-tags and target-allocation-tags with the 
resource request would lead to a far more complex implementation than 
necessary. For ex, One must now enforce an order in which ResourceRequests are 
made to ensure that applications/components/containers specified in 
target-allocation-tags exist / infact already been deployed.

Also having groups creates prior to the resource request is issued allows for 
easier/faster determination of whether a request is satisfiable in the first 
place.

I was thinking more along the lines of the *pods* concept in Kubernates.

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

Reply via email to