hadoop-yarn-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "bc Wong (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (YARN-796) Allow for (admin) labels on nodes and resource-requests
Date Mon, 07 Jul 2014 08:49:37 GMT

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

bc Wong commented on YARN-796:
------------------------------

[~yufeldman] & [~sdaingade], just read your proposal (LabelBasedScheduling.pdf). Has a
few comments:

1. *Would let each node report its own labels.* The current proposal specifies the node-label
mapping in a centralized file. This seems operationally unfriendly, as the file is hard to
maintain.
* You need to get the DNS name right, which could be hard for a multi-homed setup.
* The proposal uses regexes on FQDN, such as {{perfnode.*}}. This may work if the hostnames
are set up by IT like that. But in reality, I've seen lots of sites where the FQDN is like
{{stmp09wk0013.foobar.com}}, where "stmp" refers to the data center, and "wk0013" refers to
"worker 13", and other weird stuff like that. Now imagine that a centralized node-label mapping
file with 2000 nodes with such names. It'd be a nightmare.

Instead, each node can supply its own labels, via {{yarn.nodemanager.node.labels}} (which
specifies labels directly) or {{yarn.nodemanager.node.labelFile}} (which points to a file
that has a single line containing all the labels). It's easy to generate the label file for
each node. The admin can have puppet push it out, or populate it when the VM is built, or
compute it in a local script by inspecting /proc. (Oh I have 192GB, so add the label "largeMem".)
There is little room for mistake.

The NM can still periodically refreshes its own labels, and update the RM via the heartbeat
mechanism. The RM should also expose a "node label report", which is the real-time information
of all nodes and their labels.

2. *Labels are per-container, not per-app. Right?* The doc keeps mentioning "application label",
"ApplicationLabelExpression", etc. Should those be "container label" instead? I just want
to confirm that each container request can carry its own label expression. Example use case:
Only the mappers need GPU, not the reducers.

3. *Can we fail container requests with no satisfying nodes?* In "Considerations, #5", you
wrote that the app would be in waiting state. Seems that a fail-fast behaviour would be better.
If no node can satisfy the label expression, then it's better to tell the client "no". Very
likely somebody made a typo somewhere.



> Allow for (admin) labels on nodes and resource-requests
> -------------------------------------------------------
>
>                 Key: YARN-796
>                 URL: https://issues.apache.org/jira/browse/YARN-796
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>            Reporter: Arun C Murthy
>            Assignee: Wangda Tan
>         Attachments: LabelBasedScheduling.pdf, YARN-796.patch
>
>
> It will be useful for admins to specify labels for nodes. Examples of labels are OS,
processor architecture etc.
> We should expose these labels and allow applications to specify labels on resource-requests.
> Obviously we need to support admin operations on adding/removing node labels.



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

Mime
View raw message