[
https://issues.apache.org/jira/browse/YARN-2496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14143993#comment-14143993
]
Craig Welch commented on YARN-2496:
-----------------------------------
So, re the headroom issue (2) - the short version - I don't think we can put
off addressing this, because I think it is going to be a typical case and will
be problematic. I think the most realistic solution is to support only a short
list of pre-configured label expressions per queue. Another option is to limit
nodes to supporting only 1 label per node (which, realistically, might be
sufficient). A third option is to limit the number of labels which a queue can
access to a very small value + the "all" value (1-2). Basically, one of the
factors pushing the large set of possible values which must be considered to
properly calculate headroom needs to be made finite/drastically reduced.
longer version...
I don't think we should move forward without addressing it. I say this because
I think it is likely to be a typical situation to have a queue which has more
than one label associated with it- most likely, the simple case of a queue
which can address all nodes some of which have a label and some of which do
not. Jobs entering these queues using a restrictive label expression will hit
this headroom issue - it's especially true in cases where there are lower
resources, which is what one would expect from a "small set of special
machines" (e.g. typical node label case). It's important to make sure headroom
is correctly handled as we add node labels, and as things stand, we know it is
not.
I'm afraid it is something of a design issue, allowing arbitrary node label
expressions with multiple labels on queues, etc, is leading to something of a
combinatory explosion. It may be that the right solution is to narrow the
feature set a bit for this iteration. We could choose to only support a
restricted set of expressions on a given queue. This could even mean only
supporting the default label expression - I'm concerned that this may be too
restrictive - and so that we would need to support a set of expressions. This
could then be a finite list which is pre-calculated. I think, in practical
terms, this will probably meet people's needs. A second option is to restrict
the number of labels supported on a queue, a small enough set could be
pre-calculated for all possibilities. I suspicious of this latter option,
though, it would have to be a very small number of labels to be manageable and
I think it reduces, realistically, to the restricted set of expressions.
I also don't see any performant way to support arbitrary nodelable expressions
on every request with unlimited labels per queue and node - things as they are.
It appears to me you would need to keep track of all resource values for
intersection of all label combinations. If we limited the number of possible
labels on a node to one then we could calculate based on expressions at runtime
(possibly for a very small number > 1, but again, growth is exponential? I
believe... and functionally complex)
> [YARN-796] Changes for capacity scheduler to support allocate resource
> respect labels
> -------------------------------------------------------------------------------------
>
> Key: YARN-2496
> URL: https://issues.apache.org/jira/browse/YARN-2496
> Project: Hadoop YARN
> Issue Type: Sub-task
> Components: resourcemanager
> Reporter: Wangda Tan
> Assignee: Wangda Tan
> Attachments: YARN-2496.patch, YARN-2496.patch, YARN-2496.patch,
> YARN-2496.patch
>
>
> This JIRA Includes:
> - Add/parse labels option to {{capacity-scheduler.xml}} similar to other
> options of queue like capacity/maximum-capacity, etc.
> - Include a "default-label-expression" option in queue config, if an app
> doesn't specify label-expression, "default-label-expression" of queue will be
> used.
> - Check if labels can be accessed by the queue when submit an app with
> labels-expression to queue or update ResourceRequest with label-expression
> - Check labels on NM when trying to allocate ResourceRequest on the NM with
> label-expression
> - Respect labels when calculate headroom/user-limit
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
