hadoop-yarn-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Zhijie Shen (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (YARN-1039) Add parameter for YARN resource requests to indicate "long lived"
Date Sun, 22 Jun 2014 00:51:25 GMT

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

Zhijie Shen commented on YARN-1039:

bq. An AM may wish to indicate that some containers are shortlife, others long-lived.

Container-level long-live flag is an interesting idea. Given any container of an app is long-lived,
the AM container is automatically going to be long-lived as well, right? Suppose AM should
last until the exit of the whole app. Shall we mark an app long-lived, and then allow long-lived
app to start a long-lived container?

bq. If the tag approach lets my AM add this request while running with the 2.4 JARs even though
the hint will be ignored I'm happy.

If the granularity is going to be container, the tag may not help, as it's an application-level

> 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

View raw message