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

Wangda Tan commented on YARN-4195:
----------------------------------

Hi [~curino],

Thanks for explanation, I can understand the proposal now.

When there are more than one property of nodes need to be shared by queues with 
specified capacity, this proposal will be very useful. For example, if both of 
the PUBLICIP and GPU are all required to be shared by queues with specified 
capacity. 

And I'm also thinking about how user to configure the cluster when this feature 
is enabled:
1. User added partition A/B
2. User configure capacity for partition = \{A_B, A, B and <empty>\} to queues.
3. User assign A/B partition to nodes
4. Submit job with partitions
(2/3 could be swapped) 

But if user doesn't configure capacity for A_B and:
- Submit a job with A_B, what should we do?  
- Assign A/B to one node, what should we do?

And a cluster with N different "atomic" partitions could produce N^N "actual" 
partitions, how can we avoid such dimension explosion happens?

If any of the property doesn't need guaranteed capacity for sharing, we can 
make it to be a simple constraint (YARN-3409), which will be FCFS and arbitrary 
combination of constraints could be supported. 

> Support of node-labels in the ReservationSystem "Plan"
> ------------------------------------------------------
>
>                 Key: YARN-4195
>                 URL: https://issues.apache.org/jira/browse/YARN-4195
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>            Reporter: Carlo Curino
>            Assignee: Carlo Curino
>         Attachments: YARN-4195.patch
>
>
> As part of YARN-4193 we need to enhance the InMemoryPlan (and related 
> classes) to track the per-label available resources, as well as the per-label
> reservation-allocations.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to