[
https://issues.apache.org/jira/browse/YARN-4257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15074422#comment-15074422
]
Wangda Tan edited comment on YARN-4257 at 12/29/15 11:24 PM:
-------------------------------------------------------------
Thanks [~kasha]/[~rhaase], 0 resource makes sense to me if container is just a
pack resources and could be delegated to other processes. (Llama or YARN-1488).
After YARN-1488, we can relax 0 resource limits for all schedulers. I agree
that we can keep validateConf as-is, each scheduler keeps own criteria about 0
resources. From my side, I still want CS checks 0 resource, since 0 mem
container will be killed immediately and 0 vcore container doesn't sound
correct in semantic (now we have to launch a process for each container, a
process cannot use 0 vcores).
Agree?
was (Author: leftnoteasy):
Thanks [~kasha]/[~rhaase], 0 resource makes sense to me if container is just a
pack resources and could be delegated to other processes. (Llama or YARN-1408).
After YARN-1408, we can relax 0 resource limits for all schedulers. I agree
that we can keep validateConf as-is, each scheduler keeps own criteria about 0
resources. From my side, I still want CS checks 0 resource, since 0 mem
container will be killed immediately and 0 vcore container doesn't sound
correct in semantic (now we have to launch a process for each container, a
process cannot use 0 vcores).
Agree?
> Move scheduler validateConf method to AbstractYarnScheduler and make it
> protected
> ---------------------------------------------------------------------------------
>
> Key: YARN-4257
> URL: https://issues.apache.org/jira/browse/YARN-4257
> Project: Hadoop YARN
> Issue Type: Improvement
> Components: scheduler
> Reporter: Swapnil Daingade
> Assignee: Rich Haase
> Labels: easyfix
> Attachments: YARN-4257.patch
>
>
> Currently FairScheduler, CapacityScheduler and FifoScheduler each have a
> method private void validateConf(Configuration conf).
> All three methods validate the minimum and maximum scheduler allocations for
> cpu and memory (with minor difference). FairScheduler supports 0 as minimum
> allocation for cpu and memory, while CapacityScheduler and FifoScheduler do
> not. We can move this code to AbstractYarnScheduler (avoids code duplication)
> and make it protected for individual schedulers to override.
> Why do we care about a minimum allocation of 0 for cpu and memory?
> We contribute to a project called Apache Myriad that run yarn on mesos.
> Myriad supports a feature call fine grained scaling (fgs). In fgs, a NM is
> launched with zero capacity (0 cpu and 0 mem). When a yarn container is to be
> run on the NM, a mesos offer for that node is accepted and the NM capacity is
> dynamically scaled up to match the accepted mesos offer. On completion of the
> yarn container, resources are returned back to Mesos and the NM capacity is
> scaled down back to zero (cpu & mem).
> In ResourceTrackerService.registerNodeManager, yarn checks if the NM capacity
> is at-least as much as yarn.scheduler.minimum-allocation-mb and
> yarn.scheduler.minimum-allocation-vcores. These values can be set to 0 in
> yarn-site.xml (so a zero capacity NM is possible). However, the validateConf
> methods in CapacityScheduler and FifoScheduler do not allow for 0 values for
> these properties (The FairScheduler one does allow for 0). This behaviour
> should be consistent or at-least be override able.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
