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

Konstantinos Karanasos commented on YARN-2882:
----------------------------------------------

[~leftnoteasy], I see queueable containers as a way to keep a backlog of tasks 
that can start execution immediately when resources get available in the NM 
where they are queued. 
So currently there is no actual overcommitment of resources. However, given the 
existence of the queue, we can indeed easily support overcommitment if there is 
a way to monitor the actual resource consumption of the currently running 
containers (as the one proposed in YARN-1011).
I do agree that they are similar to the opportunistic containers of YARN-1011 
in that they can be killed by guaranteed containers.

That said, we could use the naming "opportunistic" for both cases, but we will 
need an extra flag that determines whether overcommitment is enabled.
Would that be a better solution?

> Add ExecutionType to denote if a container execution is GUARANTEED or 
> QUEUEABLE
> -------------------------------------------------------------------------------
>
>                 Key: YARN-2882
>                 URL: https://issues.apache.org/jira/browse/YARN-2882
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>          Components: nodemanager, resourcemanager
>            Reporter: Konstantinos Karanasos
>            Assignee: Konstantinos Karanasos
>         Attachments: YARN-2882-yarn-2877.001.patch, 
> YARN-2882-yarn-2877.002.patch, YARN-2882-yarn-2877.003.patch, yarn-2882.patch
>
>
> This JIRA introduces the notion of container types.
> We propose two initial types of containers: guaranteed-start and queueable 
> containers.
> Guaranteed-start are the existing containers, which are allocated by the 
> central RM and are instantaneously started, once allocated.
> Queueable is a new type of container, which allows containers to be queued in 
> the NM, thus their execution may be arbitrarily delayed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to