[
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)
