Scott Brokaw created YARN-7274:
----------------------------------

             Summary: 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.<queue-path>.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.<queue-path>.capacity for all queues, at 
each level, must be equal to 100 but for 
yarn.scheduler.capacity.<queue-path>.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.<queue-path>.maximum-capacity greater then 
it's yarn.scheduler.capacity.<queue-path>.capacity



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to