[ https://issues.apache.org/jira/browse/YARN-4257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15074422#comment-15074422 ]
Wangda Tan commented on YARN-4257: ---------------------------------- 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)