hadoop-yarn-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carlo Curino (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (YARN-1039) Add parameter for YARN resource requests to indicate "long lived"
Date Sat, 07 Feb 2015 00:47:37 GMT

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

Carlo Curino commented on YARN-1039:

Tossing some fire back on duration. I read your concerns of applications ability to provide
good values, 
however, I'd rather have the app providing their best duration estimate (and the framework
rounding it 
or bucketing it), than the app providing a coarse grained tag-based version in the first place.

Changing cluster configurations and policies might turn what used to be a "short" task into
not that short, which we want to handle differently and so on. In a sense asking for "duration"
us to rely on what application will judge as "short/long" etc.. 

As another example, based on whatever mechanisms for log aggregation we will have in the future,

we can change our mind about what are the "cut-points" for short/long etc.. For example, because
new technique makes it very cheap and we want to provide much more frequent feedback to users.

Bottom line, I find duration a rather "neutral" thing to ask, vs something which is more "opinion-based",
and corner cases like never-ending services are easily handled with -1 or +inf values.

I also agree that there are many other use cases for tags, that emerged in the discussion,
which have
a clear value and are by no means covered by duration.

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