hadoop-yarn-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Arun Suresh (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (YARN-4902) [Umbrella] Generalized and unified scheduling-strategies in YARN
Date Thu, 14 Apr 2016 18:21:25 GMT

    [ 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

View raw message