Carlo Curino commented on YARN-4195:

[~leftnoteasy], good questions:

 # We can honor the request in best-effort mode. We can't guarantee we will 
find nodes that match, but if one is found (and not promised to other) we can 
give it to the user.
 # The assignment is independent of capacity promises, so goes through normally 
(am I missing something in this question?). The reservation-system has 
mechanisms to react to changes in amount of capacity under each 
partition/label, handling the case of a dynamically changing label _after_ a 
job grabbed the container is out-of-scope. 

The combinatorial explosion is even worse, I think is the powerset of labels, 
so {{|partitions| = 2^N}}, _where N is the number of base labels_. The good 
news is that we do not automatically explode all combinations, but only focus 
on *"active" partitions*, i.e., unique combinations of labels that are 
associated with least one node. This means that we have a hard upper-bound 
{{|partitions| <= K}} where _K is the number of nodes in the cluster_.  We 
should run some tests, but it is possible that YARN-4476 's algos are efficient 
enough to deal with this even for large clusters (e.g., {{K=5000}}). 

{{|partitions| = K}} would be the norm if we decide to unify the notion of 
labels with the one of locality (I.e., a machine name is nothing but a label, 
and so is the rack). If however, we do not converge node-labels and locality, I 
would expect that in most clusters, we could find groups of nodes which are 
fungible, i.e., they form an equivalence-class (w.r.t. the set of labels they 
share) of size >1. This is like saying that those nodes are "indistinguishable" 
for the user (this used to be true for all nodes in a cluster bar locality). In 
some of our data centers we saw unique partitions in the order of {{K/100 < 
|partitions| < K/20}}---for the set of labels we cared about in those settings. 
(Mileage will heavily vary based on the semantics/use of labels you consider).

> 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

Reply via email to