hadoop-yarn-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vinod Kumar Vavilapalli (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (YARN-1039) Add parameter for YARN resource requests to indicate "long lived"
Date Tue, 24 Jun 2014 03:34:25 GMT

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

Vinod Kumar Vavilapalli commented on YARN-1039:
-----------------------------------------------

I am not against a container/resource level definition of whether that container is long lived
or not, but I think it is equally important to mark at the application level if _at least_
one container in the application is considered long lived. So, to summarize, how about
 - an app-level isLongRunning() that indicates _if at least one container of this application
will be long-running_ and
 - a resource-request level isLongRunning() that indicates _if this container is long running
or not_.

The app-level flag can help UIs, making very quick scheduling distinctions etc.

Thoughts?

> Add parameter for YARN resource requests to indicate "long lived"
> -----------------------------------------------------------------
>
>                 Key: YARN-1039
>                 URL: https://issues.apache.org/jira/browse/YARN-1039
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>          Components: resourcemanager
>    Affects Versions: 3.0.0, 2.1.1-beta
>            Reporter: Steve Loughran
>            Assignee: Craig Welch
>            Priority: Minor
>         Attachments: YARN-1039.1.patch, YARN-1039.2.patch, YARN-1039.3.patch
>
>
> A container request could support a new parameter "long-lived". This could be used by
a scheduler that would know not to host the service on a transient (cloud: spot priced) node.
> Schedulers could also decide whether or not to allocate multiple long-lived containers
on the same node



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Mime
View raw message