Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id CA7A1200D0F for ; Fri, 29 Sep 2017 16:58:05 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id C908D1609C5; Fri, 29 Sep 2017 14:58:05 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id E8BEE1609D1 for ; Fri, 29 Sep 2017 16:58:04 +0200 (CEST) Received: (qmail 38031 invoked by uid 500); 29 Sep 2017 14:58:04 -0000 Mailing-List: contact yarn-issues-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list yarn-issues@hadoop.apache.org Received: (qmail 38020 invoked by uid 99); 29 Sep 2017 14:58:04 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 29 Sep 2017 14:58:04 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id 9D349184FC6 for ; Fri, 29 Sep 2017 14:58:03 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -100.002 X-Spam-Level: X-Spam-Status: No, score=-100.002 tagged_above=-999 required=6.31 tests=[RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=disabled Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id d8AwWIk4OIgL for ; Fri, 29 Sep 2017 14:58:02 +0000 (UTC) Received: from mailrelay1-us-west.apache.org (mailrelay1-us-west.apache.org [209.188.14.139]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTP id 663865FAEA for ; Fri, 29 Sep 2017 14:58:01 +0000 (UTC) Received: from jira-lw-us.apache.org (unknown [207.244.88.139]) by mailrelay1-us-west.apache.org (ASF Mail Server at mailrelay1-us-west.apache.org) with ESMTP id 912BAE0D34 for ; Fri, 29 Sep 2017 14:58:00 +0000 (UTC) Received: from jira-lw-us.apache.org (localhost [127.0.0.1]) by jira-lw-us.apache.org (ASF Mail Server at jira-lw-us.apache.org) with ESMTP id 37E9B24286 for ; Fri, 29 Sep 2017 14:58:00 +0000 (UTC) Date: Fri, 29 Sep 2017 14:58:00 +0000 (UTC) From: "Scott Brokaw (JIRA)" To: yarn-issues@hadoop.apache.org Message-ID: In-Reply-To: References:

Subject: [jira] [Updated] (YARN-7274) Ability to disable elasticity at leaf queue level MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 archived-at: Fri, 29 Sep 2017 14:58:06 -0000 [ https://issues.apache.org/jira/browse/YARN-7274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Brokaw updated YARN-7274: ------------------------------- Description: The documentation [https://hadoop.apache.org/docs/current/hadoop-yarn/hadoop-yarn-site/CapacityScheduler.html] defines yarn.scheduler.capacity..maximum-capacity as "Maximum queue capacity in percentage (%) as a float. This limits the elasticity for applications in the queue. Defaults to -1 which disables it." However, setting this value to -1 sets maximum capacity to 100% but I thought (perhaps incorrectly) that the intention of the -1 setting is that it would disable elasticity. This is confirmed looking at the code: {code:java} public static final float MAXIMUM_CAPACITY_VALUE = 100; public static final float DEFAULT_MAXIMUM_CAPACITY_VALUE = -1.0f; ...... maxCapacity = (maxCapacity == DEFAULT_MAXIMUM_CAPACITY_VALUE) ? MAXIMUM_CAPACITY_VALUE : maxCapacity; {code} The sum of yarn.scheduler.capacity..capacity for all queues, at each level, must be equal to 100 but for yarn.scheduler.capacity..maximum-capacity this value is actually a percentage of the entire cluster not just the parent queue. Yet it can not be set lower then the leaf queue's capacity setting. This seems to make it impossible to disable elasticity at a leaf queue level. This improvement is proposing that YARN have the ability to have elasticity disabled at a leaf queue level even if a parent queue permits elasticity by having a yarn.scheduler.capacity..maximum-capacity greater then it's yarn.scheduler.capacity..capacity was: The documentation[https://hadoop.apache.org/docs/current/hadoop-yarn/hadoop-yarn-site/CapacityScheduler.html] defines yarn.scheduler.capacity..maximum-capacity as "Maximum queue capacity in percentage (%) as a float. This limits the elasticity for applications in the queue. Defaults to -1 which disables it." However, setting this value to -1 sets maximum capacity to 100% but I thought (perhaps incorrectly) that the intention of the -1 setting is that it would disable elasticity. This is confirmed looking at the code: {code:java} public static final float MAXIMUM_CAPACITY_VALUE = 100; public static final float DEFAULT_MAXIMUM_CAPACITY_VALUE = -1.0f; ...... maxCapacity = (maxCapacity == DEFAULT_MAXIMUM_CAPACITY_VALUE) ? MAXIMUM_CAPACITY_VALUE : maxCapacity; {code} The sum of yarn.scheduler.capacity..capacity for all queues, at each level, must be equal to 100 but for yarn.scheduler.capacity..maximum-capacity this value is actually a percentage of the entire cluster not just the parent queue. Yet it can not be set lower then the leaf queue's capacity setting. This seems to make it impossible to disable elasticity at a leaf queue level. This improvement is proposing that YARN have the ability to have elasticity disabled at a leaf queue level even if a parent queue permits elasticity by having a yarn.scheduler.capacity..maximum-capacity greater then it's yarn.scheduler.capacity..capacity > Ability to disable elasticity at leaf queue level > ------------------------------------------------- > > Key: YARN-7274 > URL: https://issues.apache.org/jira/browse/YARN-7274 > Project: Hadoop YARN > Issue Type: Improvement > Components: capacityscheduler > Reporter: Scott Brokaw > > The documentation [https://hadoop.apache.org/docs/current/hadoop-yarn/hadoop-yarn-site/CapacityScheduler.html] defines yarn.scheduler.capacity..maximum-capacity as "Maximum queue capacity in percentage (%) as a float. This limits the elasticity for applications in the queue. Defaults to -1 which disables it." > However, setting this value to -1 sets maximum capacity to 100% but I thought (perhaps incorrectly) that the intention of the -1 setting is that it would disable elasticity. This is confirmed looking at the code: > {code:java} > public static final float MAXIMUM_CAPACITY_VALUE = 100; > public static final float DEFAULT_MAXIMUM_CAPACITY_VALUE = -1.0f; > ...... > maxCapacity = (maxCapacity == DEFAULT_MAXIMUM_CAPACITY_VALUE) ? > MAXIMUM_CAPACITY_VALUE : maxCapacity; > {code} > The sum of yarn.scheduler.capacity..capacity for all queues, at each level, must be equal to 100 but for yarn.scheduler.capacity..maximum-capacity this value is actually a percentage of the entire cluster not just the parent queue. Yet it can not be set lower then the leaf queue's capacity setting. This seems to make it impossible to disable elasticity at a leaf queue level. > This improvement is proposing that YARN have the ability to have elasticity disabled at a leaf queue level even if a parent queue permits elasticity by having a yarn.scheduler.capacity..maximum-capacity greater then it's yarn.scheduler.capacity..capacity -- This message was sent by Atlassian JIRA (v6.4.14#64029) --------------------------------------------------------------------- To unsubscribe, e-mail: yarn-issues-unsubscribe@hadoop.apache.org For additional commands, e-mail: yarn-issues-help@hadoop.apache.org