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

Carlo Curino commented on YARN-1707:
------------------------------------

I share the uncertainty towards getQueueName returning the name of the parent. 
It seems the least intrusive way to mask the user from our internal queue 
management. The alternative is to use a QueueName class instead of String, and 
allow the receiver to use a "displayName" or "localName"... but this has 
awfully broad footprint. Alternatively we can add a "getDisplayName" to CSQueue 
to be used by the UI, and implement it everywhere as getQueueName except in 
ReservationQueue where we can answer with parent name. Again a bit large of a 
change for a rather minor outcome.  

Thanks,
Carlo

> Making the CapacityScheduler more dynamic
> -----------------------------------------
>
>                 Key: YARN-1707
>                 URL: https://issues.apache.org/jira/browse/YARN-1707
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>          Components: capacityscheduler
>            Reporter: Carlo Curino
>            Assignee: Carlo Curino
>              Labels: capacity-scheduler
>         Attachments: YARN-1707.2.patch, YARN-1707.3.patch, YARN-1707.4.patch, 
> YARN-1707.patch
>
>
> The CapacityScheduler is a rather static at the moment, and refreshqueue 
> provides a rather heavy-handed way to reconfigure it. Moving towards 
> long-running services (tracked in YARN-896) and to enable more advanced 
> admission control and resource parcelling we need to make the 
> CapacityScheduler more dynamic. This is instrumental to the umbrella jira 
> YARN-1051.
> Concretely this require the following changes:
> * create queues dynamically
> * destroy queues dynamically
> * dynamically change queue parameters (e.g., capacity) 
> * modify refreshqueue validation to enforce sum(child.getCapacity())<= 100% 
> instead of ==100%
> We limit this to LeafQueues. 



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Reply via email to