Naganarasimha G R commented on YARN-2495:

Thanks [~aw],[~wangda] & [~sunilg],

*For [~aw] comments:*
bq. I don't fully understand your question, but I'll admit I've been distracted 
with other JIRAs lately.
You got first part of my question right and thanks for detailing the scenario

bq. If we are rolling out a new version of the JDK, I shouldn't have to tell 
the system that it's ok to broadcast that JDK version first.
I understood the use case but what i did not understand is how would it 
restrict/deter a user, as he can do one more updation ; one more label to the 
central valid label list, like java version or jdk version etc. As anyway 
script will be written/updated to get specific set of labels so i feel in most 
cases admin can know what lables will be coming in the cluster. Any other use 
case where it will be difficult for admin to list the labels before hand  ?

*For [~wangda] comments:*
bq. they will be reported to RM when NM registration. We may not need to 
persist any of them, but RM should know these labels existence to do scheduling.
Does RM needs to have all the list of valid labels even before registering of 
all nodes are done ? How will it impact scheduling ? How is it different from 
Central configuration ? As in centralized config; user needs to update the new 
labels and then send the node to lables mapping . similarly in distributed 
config first we can find out the new labels and update the super set list of 
lables and then update the label mapping for a node which wants update or 
modify labels.

bq. Another question is if we need check labels when they registering, I prefer 
to pre-set them because this affects scheduling behavior. For example, the 
maximum-resource and minimum-resource are setup in RM side, and RackResolver is 
also run in RM side
May be this i did not get it correctly.  You mean when NM is registering for 
the first time after startup, you want it have preset apart from what is read 
from NM's yarn-site.xml/script ? did not get this clearly please elaborate. 

bq. At least, the label checking should be kept configurable in distributed 
mode. – "just ignore all the labels for that node if invalid labels exists" 
might be a good way when it enabled.
in your earlier stmt you said it affects scheduling, if so then if its kept 
configurable then how will that solve ? But what was clear was 
* Support to add and remove Valid label and centralized level is required
* RM will do the label validation on NM registraion & heartbeat
* If while validating (during NM registraion & heartbeat) if one of the labels 
fail for a given node. then we will just ignore all the labels for that node.

*For [~sunilg] comments:*
bq. If any such node label is invalid as per RM, then how this will be reported 
back to NM? Error Handling?
I too have the same doubt and feel that usability will be reduced as script is 
executed some where and the validations are happening some where, if error is 
not propagated back to NM. 

 bq. But imagine a 1000 node cluster, and then with changing labels per 
heartbeat, will this be a bottleneck?
we will not be changing label for every heart beat i will try to ensure that 
during heartbeat only if the labels have changed from previous set of labels 
for a node only then it will send the updated label set.  But issue will be 
there that lot of contention will happen suppose some script is modified and 
all 2000 nodes want to update their labels

> Allow admin specify labels in each NM (Distributed configuration)
> -----------------------------------------------------------------
>                 Key: YARN-2495
>                 URL: https://issues.apache.org/jira/browse/YARN-2495
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>          Components: resourcemanager
>            Reporter: Wangda Tan
>            Assignee: Naganarasimha G R
> Target of this JIRA is to allow admin specify labels in each NM, this covers
> - User can set labels in each NM (by setting yarn-site.xml or using script 
> suggested by [~aw])
> - NM will send labels to RM via ResourceTracker API
> - RM will set labels in NodeLabelManager when NM register/update labels

This message was sent by Atlassian JIRA

Reply via email to