Wangda Tan commented on YARN-796:

Hi [~sunilg],
Thanks for reply,

bq. 1. In our use case scenarios, we are more likely to have OR and NOT. I feel 
combination of these labels need to be in a defined or restricted way. Result 
of some combinations (AND, OR and NOT) may come invalid, and some may need to 
be reduced. This complexity need not have to bring to RM to take a final 
Agree that we need some restricted way, we need think harder about this :)
bq. 2. Reservation: If a node label has many nodes under it, then there is a 
chance of reservation. Valid candidates may come later, so solution can be look 
in to this aspect also. Node Label level reservations ?
I haven't thought about this before, I'll think about it, thanks for reminding 
bq. 3. Centralized Configuration: If a new node is added to cluster, may be it 
can be started by having a label configuration in its yarn-site.xml. This may 
be fine I feel. your thoughts?
I think this is more like a decentralized configuration in your description. 
For centralized configuration, I think maybe there's a "node label repo" which 
stores mapping of nodes to labels. And we will provide RESTful API for changing 


> 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, 
> Node-labels-Requirements-Design-doc-V1.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

Reply via email to