Link related JIRAs

Should be as simple as:
YarnRunner sets label on ApplicationSubmissionContext for MapReduce applications based on additional configuration property like mapreduce.job.label.

It is described in https://issues.apache.org/jira/secure/attachment/12654148/LabelBasedScheduling.pdf even though it was not done as such.

mapreduce.job.label may not be enough. There should be at least another parameter such as mapreduce.job.am.label for the application master. For example, on EC2, we don't want to run an application master on a spot instance, but we do allow MR tasks to run on spot instances (otherwise, what is the purpose to use instances?). Furthermore, Application Master is a special Yarn container and MRAppMaster does not run as a YarnChild, right?

Jian Fang Definitely it depends whether you want separate label for AM and the rest of the tasks.

YarnRunner is the right place to set the labels for a MR job. However, there is one concern here. If I understand correctly, YarnRunner runs at the job client side, right? There should also be a way to hook in the labels on the server side, i.e., resource manager side. The reason is that many Hadoop users do not understand or set the labels by themselves and they simply rely on the Hadoop platform provider (or system admins for on-premise clusters) to set up the labels for them. I am not sure if this is a general use case, but it is definitely a feature that we need.

I do not think labels should be dictated by RM, since different types of jobs may require different types of resources. It is definitely true that cluster admins label nodes so those labels can be used while making a decision from the application prospective.
It is true that job is submitted from the client, but it is not like you submit different classes of jobs every time, so eventually job owner will know what resources he/she needs for that specific class of jobs.
The case you described warrants just setting labels in mapred-site.xml on client side and be done. If you submit all sorts of jobs then may be you don't even care about labels.
Yet another choice is to utilize labels on Queues - this will be set on the cluster so for jobs submitted to a specific queue specific labels will be applied

I understand your point from on-premise cluster perspective. However, it is not very practical to manage mapred-site.xml or queue files for users if hadoop is a service in cloud. As a hadoop developer, you should consider both on-premise hadoop cluster and hadoop in cloud.

There are many many users for a hadoop cloud service. Usually they launch their own hadoop clusters in cloud and control their own queue files or mapred-site.xml. Some of them even run their hadoop jobs on their own gateways that the hadoop platform provider does not have access to. But the hadoop service provider may still want to have a mechanism to set up some global labels for all users to improve their user experiences. For example, a failure of an application master on a spot instance due to the termination of a spot instance will cause more trouble than a failure of one MR task. These types of settings most likely can only be done by hadoop cloud service providers based on their deep knowledge in their own cloud services.

Or could hadoop provide a mechanism for hadoop providers to extend so that you only need to specify the labels in YarnRunner in Vanilla hadoop?

Thanks for the comments Yuliya Feldman & Jian Fang,

Definitely it depends whether you want separate label for AM and the rest of the tasks.

I have started working on this patch and had already considered the 2 kinds of labels as ApplicationSubmissionContext was supporting it and REST has already taken care of it .

The reason is that many Hadoop users do not understand or set the labels by themselves and they simply rely on the Hadoop platform provider (or system admins for on-premise clusters) to set up the labels for them. I am not sure if this is a general use case, but it is definitely a feature that we need.

Even though labels should not be dictated by RM, i feel there might be cases as mentioned by Jian Fang where users might not be aware what each label stands for! or users might not want to understand the label as partition (which is more on administrative side in multi tenant scenarios) and they might just require some auto mapping based on user or group. So i think we can come up with some configurations of automapping based on user/group (similar to queues) for labels too.

Thanks Naganarasimha for your understanding. However, user/group mapping may not work for us since we don't have control of that as a hadoop service provider. I would prefer a plugin mechanism rather than a solution here so that we can extend that for our service. But I think the change for YarnRunner is still needed for hadoop users anyway.

But I think the change for YarnRunner is still needed for hadoop users anyway.

yes that true, other discussion is more like an additional requirement, which i think needs attention from Tan, Wangda too.

Just found I'm not in the watcher list, missed some discussions.

I think Jian Fang's use case is very unique but also interesting, platform provider has no control and knowledge of user's applications, and user doesn't understand about platform's details such as which machine is temporary or not.

Maybe a possible way to solve this problem is to add a global-am-resource-request setting, which can include node-label-expression, node/rack information. Because as YARN RM, it doesn't know what's the application's running model, it only knows which container is AM or not, which seems enough for your requirements.

But adding such global-am-resource-request setting can also be dangerous, such as how about a queue is not accessible node-label-expression of global-am-resource-request?

Attaching a patch for this issue

Hi Tan, Wangda, As global-am-resource-request can have some caveats which you mention, what if we can have yarn.scheduler.capacity.{queue_path}.default-am-node-label-expression which we can ensure while loading if the labels configured for the queue path exists or not. Or in much more generic way, can we have some ContainerPlacementPolicy interface @ CS which needs to provide which queue and label to be used for a given container, user & group ?

-1 overall. Here are the results of testing the latest attachment
http://issues.apache.org/jira/secure/attachment/12724623/MAPREDUCE-6304.20150410-1.patch
against trunk revision 7660da9.

+1 @author. The patch does not contain any @author tags.

+1 tests included. The patch appears to include 1 new or modified test files.

-1 javac. The patch appears to cause the build to fail.

Console output: https://builds.apache.org/job/PreCommit-MAPREDUCE-Build/5389//console

This message is automatically generated.

correcting the previous patch

-1 overall. Here are the results of testing the latest attachment
http://issues.apache.org/jira/secure/attachment/12724652/MAPREDUCE-6304.20150411-1.patch
against trunk revision 7660da9.

+1 @author. The patch does not contain any @author tags.

+1 tests included. The patch appears to include 1 new or modified test files.

+1 javac. The applied patch does not increase the total number of javac compiler warnings.

+1 javadoc. There were no new javadoc warning messages.

-1 eclipse:eclipse. The patch failed to build with eclipse:eclipse.

+1 findbugs. The patch does not introduce any new Findbugs (version 2.0.3) warnings.

+1 release audit. The applied patch does not increase the total number of release audit warnings.

+1 core tests. The patch passed unit tests in .

Test results: https://builds.apache.org/job/PreCommit-MAPREDUCE-Build/5390//testReport/
Console output: https://builds.apache.org/job/PreCommit-MAPREDUCE-Build/5390//console

This message is automatically generated.

A more generic way could be to add a decorator to ApplicationSubmissionContext in class ClientRMService so that people can change the ApplicationSubmissionContext in the method submitApplication(). The default decorator from Apache does nothing, but hadoop allows users to use a custom decorator from hadoop configuration.

Jian Fang, thanks for the comments but did not get your idea completely. Comment is for the approach taken in the patch or earlier discussion of supporting default label expression for am container ?

The default decorator from Apache does nothing, but hadoop allows users to use a custom decorator from hadoop configuration.

Can you please specify which configuration you are referring to ?

I mean hadoop could provide a new mechanism such as a decorator for the ApplicationSubmissionContext. When the method submitApplication() in class ClientRMService is called, hadoop decorates the ApplicationSubmissionContext before it calls the following line. For example, manipulates the amLabelExpression.

rmAppManager.submitApplication(submissionContext,
System.currentTimeMillis(), user);

Hadoop could provide a default decorator that does nothing. But users could override the default decorator in yarn-site.xml by a new configuration parameter, for example, "yarn.app.submission.context.decorator.class".

This new mechanism is not directly related to the change you are making, but it is more generic so that the platform providers could update the ApplicationSubmissionContext in their own ways. Once we have such a new mechanism in place, you do not really need to add anything new to your label code for my use case. Instead, the custom logic will be included in the custom decorator provided by the platform provider. For example, we could provide a decorator to update amLabelExpression in ApplicationSubmissionContext. Other fields of ApplicationSubmissionContext could be changed as well to meet user's needs.

I created JIRA YARN-3490 for the application decorator proposal.

Tan, Wangda, if you have bandwidth can you take a look @ this small patch ?

Hi Tan, Wangda,Harsh J,Jian He,
Can any one take a look at this patch ?

Hi Naganarasimha G R,
Just took a look at the patch, some comments about syntax:

• Beyond AM/Job node-labels setting, should we support Mapper/Reducer setting?
• When job and AM (or mapper/reducer) set together, AM (or mapper/reducer)'s node-label-expression should overwrite job's setting.
• If we need support mapper/reducer's node-label-expression. We may need add some changes in MR AM side and some tests.

Any ideas? Lohit Vijayarenu.

Thanks for the review comments Tan, Wangda,

Beyond AM/Job node-labels setting, should we support Mapper/Reducer setting?

If we need support mapper/reducer's node-label-expression. We may need add some changes in MR AM side and some tests.

Well my view should be to support them as i feel in some cases we might feel like mapper can run in any node but may be reducer requires more mem so may be clients might require it to be run in high mem nodes (may be some constraint on mem for the nodes) or some other node constraints.

When job and AM (or mapper/reducer) set together, AM (or mapper/reducer)'s node-label-expression should overwrite job's setting.

Well, IIUC then ApplicationSubmissionContext.getNodeLabelExpression() is for mapper/reducer and AM's node label expression is set in ApplicationSubmissionContext.getAMContainerResourceRequest. I could cross verify the same with code in ApplicationMasterService (line number 495) & RMAppManager (line number 378) and so did not get what you meant by the above statement, correct me if my understanding is wrong.

Well my view should be to support them as i feel in some cases we might feel like mapper can run in any node but may be reducer requires more mem so may be clients might require it to be run in high mem nodes (may be some constraint on mem for the nodes) or some other node constraints.

That's correct, so you agree to add mapper/reducer node-label-expression?

Well, IIUC then ApplicationSubmissionContext.getNodeLabelExpression() is for mapper/reducer and AM's node label expression is set in ApplicationSubmissionContext.getAMContainerResourceRequest. I could cross verify the same with code in ApplicationMasterService (line number 495) & RMAppManager (line number 378) and so did not get what you meant by the above statement, correct me if my understanding is wrong.

What I meant is:
When job.label = x, and don't set am/mapper/reducer label, all containers should get allocated on x
When job.label = x and am.label = y, don't set mapper/reducer label, am will get allocated on y (overwritten x) but mapper/reducer should get allocated on x.
When job.label = x, am.label=y, mapper.label=z, am will get allocated on y, mapper will get allocated on z (overwrite x), and reducer get allocated on x.
This should be existing behavior. And mapper/reducer's label should be added to ResourceRequest (may need modify RMContainerRequestor) instead of AplicationSubmissionContext.

Thanks for detailed clarification, got what you intended and was planning to do the same way, i.e. only if "mapreduce.job.map.node-label-expression" or "mapreduce.job.reduce.node-label-expression" config are set then modify the ask in RMContainerRequestor as yarn takes care of setting in ApplicationMasterService when no labels specified in resource request for mapper and reducer and in RMAppManager for AM.

Hi Tan, Wangda, have incorporated changes for add mapper/reducer node-label-expression also incorported limitations set by YARN-2694(Ensure only single node label specified in ResourceRequest) which limits labels to be supported on only "ANY" ResourceRequests.
But one query what i have is : Isnt it a serious limitation if labels are supported for only ANY resource requests?

-1 overall

This message was automatically generated.

hi Tan, Wangda checkstyle has only valid white space issues, correcting it. Findbugs issues is not so relveant for the variables usage, resubmitting the patch with the white space issue

-1 overall

This message was automatically generated.

Naganarasimha G R,
Patch generally LGTM, one minor comment:

• If specify label="" in mapred-default.xml, which means the job will always set label="" while adding resource-request, but the previously behavior is send "null" instead of empty string. So I suggest to change the default to be "NOT SPECIFIED" (which is not a valid label since it contains space) as default value, and we will replace it by null. Does this make sense to you? Do you have any other ideas on this?

And could you deploy a few nodes cluster, with 2-3 labels, and run MR job with am.label, mapper.label, reducer.label, etc. that will be very important to make sure everything works well.

Thanks for reviewing Tan, Wangda,

If specify label="" in mapred-default.xml, which means the job will always set label="" .... So I suggest to change the default to be "NOT SPECIFIED" (which is not a valid label since it contains space) as default value, and we will replace it by null.

Good catch, but AFAIK we need not do so much handling and if we just remove <value></value> in mapred-default.xml then the value will be taken as null by xml parser in the Configuration class. while i am testing in the multi node cluster will verify this and then update the patch.

could you deploy a few nodes cluster, with 2-3 labels, and run MR job with am.label, mapper.label, reducer.label, etc. that will be very important to make sure everything works well.

Will try to get this tested on monday ( currenty only left with laptop ).
Test case failures doesn't seem to be related to the patch based on logs.

Naganarasimha G R, remove from mapred-default.xml is not good. mapred-default.xml is a way to document all options we have, how about make its default to be "USE_QUEUE_DEFINED_DEFAULT" or better name, it's not "not specified" or "null" actually, it's using queue defined node label expression. Thoughts?

hi Tan, Wangda,
I meant actually only deletion of <value></value> for example

<property>
<name>mapreduce.job.am.node-label-expression</name>
<!-- value></value -->
<description>Overrides mapreduce.job.node-label-expression for application
master containers
</description>
</property>

which is similar to the existing configs like yarn.ipc.*.factory.class, yarn.resourcemanager.cluster-id,yarn.resourcemanager.ha.rm-ids,yarn.resourcemanager.ha.id ....
In general your approach is fine but as we can make use of the above approach of configuration did not want to bring in additional default configs. thoughts ?

Naganarasimha G R, thanks for pointing me about yarn.ipc.*.factory, etc. I think it's important to

• Not bring in additional unncessary default config
• Follow what we have in *default.xml
• Make admin easy to understand

So I think it's fine to do as what you suggested, but could you please mention in description that, by default the node-label-expression for job is not set, it will use queue's default-node-label-expression.

Thanks Tan, Wangda for your comments,
+1 for mention in description that, by default the node-label-expression for job is not set, it will use queue's default-node-label-expression.. I am getting it tested in cluster setup, will upload the updated patch today.

Updated the description and tested in 2 NM with 3 labels and also specifying different combination of labels

-1 overall

This message was automatically generated.

Attaching patch with applicable white-space and check style issues fixed

-1 overall

This message was automatically generated.

Thanks Naganarasimha G R for working on this and testing, mostly LGTM, could you add the overwriting behavior in mapred-default.xml? (For example, by default is using queue's default-node-label-expression, AM.expression can overwrite job.expression, etc.

Hi Tan, Wangda, have modified the documentation in Mapred-default.xml. Please check.

-1 overall

This message was automatically generated.

Thanks update, Naganarasimha G R, +1 for latest patch.

Hi Tan, Wangda
One suggestion for this patch : labels will be applicable for only for Any resource requests, so would it be better to have a config, based on which rack local and node specific will not be submitted and only Any resource requests with label will be submitted ? This will ensure that MR tasks run only on the labelled nodes.
If the existing support to labels are sufficient then can we push this in ?

Naganarasimha G R,
Actually now CS will check label-expression of ANY resource request matches labels on nodes before allocating rack/node local requests. IAW, node-label-expression of rack/node local request will be ignored and will be treated as same as ANY request. To reply your concern:
MR tasks run only on the labeled nodes.

Since this changes MR configuration, I will wait for another couple of days before commit this.

Thanks,

Thanks Tan, Wangda for clarifying my query, and ok for waiting for couple days for committing this.

Naganarasimha G R, I think I made a mistake in previous comment, rack/node local resource request is not allowed to specify label-expression for now. See SchedulerUtils.validateResourceRequest, I think you need to add a check in MR side, if the resourceName is not ANY, don't set node-label-expression to it.

Hi Tan, Wangda
I have already taken care of this

• JOB_NODE_LABEL_EXP is set to the Application submission context and yarn takes care of setting only when ResourceRequest is ANY
• AM_NODE_LABEL_EXP is set to the AM's Resource request which is of Any type always.
• MAP_NODE_LABEL_EXP & REDUCE_NODE_LABEL_EXP are added to the resource request only when its of ANY type in RMContainerRequestor.addContainerReq(ContainerRequest). Test case is also present for it.

My question was in most cases container is assigned to either Node Local or Rack local, So in these cases container cannot be assigned to a Node satisfying the Node Label exp. So my suggestion was based on boolean config flag can we decide whether to add node local and rack local request or not. for example expose ENABLE_ANY_RESOURCE_REQUEST_ONLY config based on which node local and rack local request will not be set.

Naganarasimha G R,
Thanks for replying, it's glad to hear such cases are already addressed.

I think that will be problematic if we enable_any_resource_request_only, now we calculate pending-resource-by-label only for ANY request. I think it's fine to me to leave behind the node-local/rack-local out of partition issue. MR job can still get start and running.

Thanks for replying Tan, Wangda

Thanks for replying, it's glad to hear such cases are already addressed.

I think that will be problematic if we enable_any_resource_request_only, now we calculate pending-resource-by-label only for ANY request. I think it's fine to me to leave behind the node-local/rack-local out of partition issue. MR job can still get start and running.

I am ok with not adding, but my intention was not to add node-local/rack-local resource requests at all so that it there are no issues with the ones mentioned in YARN-2694. Also in small clusters(<50) all are in the same rack i.e. default rack and suppose i want to run the reducers in the nodes with good HW config (high mem/fast cpu) then this kind of config might be helpful.

Hi Tan, Wangda,
Any thoughts/updates on my previous comment ? if no more changes then can we get this in ?

It's the last call of comments, I plan to get this in today.

FAILURE: Integrated in Hadoop-trunk-Commit #7909 (See https://builds.apache.org/job/Hadoop-trunk-Commit/7909/)
MAPREDUCE-6304. Specifying node labels when submitting MR jobs. (Naganarasimha G R via wangda) (wangda: rev 3164e7d83875aa6b7435d1dfe61ac280aa277f1c)

• hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-jobclient/src/test/java/org/apache/hadoop/mapred/TestYARNRunner.java
• hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-app/src/main/java/org/apache/hadoop/mapreduce/v2/app/rm/RMContainerRequestor.java
• hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-app/src/test/java/org/apache/hadoop/mapreduce/v2/app/rm/TestRMContainerAllocator.java
• hadoop-mapreduce-project/CHANGES.txt
• hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-jobclient/src/main/java/org/apache/hadoop/mapred/YARNRunner.java
• hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-core/src/main/resources/mapred-default.xml
• hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-app/src/main/java/org/apache/hadoop/mapreduce/v2/app/rm/RMContainerAllocator.java
• hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-core/src/main/java/org/apache/hadoop/mapreduce/MRJobConfig.java

Just committed to branch-2/trunk. Thanks Naganarasimha G R and review from Jian Fang and Yuliya Feldman. I cannot resolve it because JIRA system is so slow today.

Thanks for reviewing and commiting Tan, Wangda,Jian Fang & Yuliya Feldman.

FAILURE: Integrated in Hadoop-Yarn-trunk-Java8 #211 (See https://builds.apache.org/job/Hadoop-Yarn-trunk-Java8/211/)
MAPREDUCE-6304. Specifying node labels when submitting MR jobs. (Naganarasimha G R via wangda) (wangda: rev 3164e7d83875aa6b7435d1dfe61ac280aa277f1c)

• hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-app/src/test/java/org/apache/hadoop/mapreduce/v2/app/rm/TestRMContainerAllocator.java
• hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-core/src/main/java/org/apache/hadoop/mapreduce/MRJobConfig.java
• hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-jobclient/src/main/java/org/apache/hadoop/mapred/YARNRunner.java
• hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-app/src/main/java/org/apache/hadoop/mapreduce/v2/app/rm/RMContainerAllocator.java
• hadoop-mapreduce-project/CHANGES.txt
• hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-jobclient/src/test/java/org/apache/hadoop/mapred/TestYARNRunner.java
• hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-app/src/main/java/org/apache/hadoop/mapreduce/v2/app/rm/RMContainerRequestor.java
• hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-core/src/main/resources/mapred-default.xml

SUCCESS: Integrated in Hadoop-Yarn-trunk #941 (See https://builds.apache.org/job/Hadoop-Yarn-trunk/941/)
MAPREDUCE-6304. Specifying node labels when submitting MR jobs. (Naganarasimha G R via wangda) (wangda: rev 3164e7d83875aa6b7435d1dfe61ac280aa277f1c)

• hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-app/src/main/java/org/apache/hadoop/mapreduce/v2/app/rm/RMContainerAllocator.java
• hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-jobclient/src/test/java/org/apache/hadoop/mapred/TestYARNRunner.java
• hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-core/src/main/java/org/apache/hadoop/mapreduce/MRJobConfig.java
• hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-app/src/test/java/org/apache/hadoop/mapreduce/v2/app/rm/TestRMContainerAllocator.java
• hadoop-mapreduce-project/CHANGES.txt
• hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-jobclient/src/main/java/org/apache/hadoop/mapred/YARNRunner.java
• hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-core/src/main/resources/mapred-default.xml
• hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-app/src/main/java/org/apache/hadoop/mapreduce/v2/app/rm/RMContainerRequestor.java

FAILURE: Integrated in Hadoop-Hdfs-trunk #2139 (See https://builds.apache.org/job/Hadoop-Hdfs-trunk/2139/)
MAPREDUCE-6304. Specifying node labels when submitting MR jobs. (Naganarasimha G R via wangda) (wangda: rev 3164e7d83875aa6b7435d1dfe61ac280aa277f1c)

• hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-jobclient/src/test/java/org/apache/hadoop/mapred/TestYARNRunner.java
• hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-core/src/main/java/org/apache/hadoop/mapreduce/MRJobConfig.java
• hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-app/src/test/java/org/apache/hadoop/mapreduce/v2/app/rm/TestRMContainerAllocator.java
• hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-jobclient/src/main/java/org/apache/hadoop/mapred/YARNRunner.java
• hadoop-mapreduce-project/CHANGES.txt
• hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-core/src/main/resources/mapred-default.xml
• hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-app/src/main/java/org/apache/hadoop/mapreduce/v2/app/rm/RMContainerAllocator.java
• hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-app/src/main/java/org/apache/hadoop/mapreduce/v2/app/rm/RMContainerRequestor.java

FAILURE: Integrated in Hadoop-Hdfs-trunk-Java8 #199 (See https://builds.apache.org/job/Hadoop-Hdfs-trunk-Java8/199/)
MAPREDUCE-6304. Specifying node labels when submitting MR jobs. (Naganarasimha G R via wangda) (wangda: rev 3164e7d83875aa6b7435d1dfe61ac280aa277f1c)

• hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-app/src/test/java/org/apache/hadoop/mapreduce/v2/app/rm/TestRMContainerAllocator.java
• hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-app/src/main/java/org/apache/hadoop/mapreduce/v2/app/rm/RMContainerRequestor.java
• hadoop-mapreduce-project/CHANGES.txt
• hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-jobclient/src/main/java/org/apache/hadoop/mapred/YARNRunner.java
• hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-core/src/main/resources/mapred-default.xml
• hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-core/src/main/java/org/apache/hadoop/mapreduce/MRJobConfig.java
• hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-app/src/main/java/org/apache/hadoop/mapreduce/v2/app/rm/RMContainerAllocator.java
• hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-jobclient/src/test/java/org/apache/hadoop/mapred/TestYARNRunner.java

SUCCESS: Integrated in Hadoop-Mapreduce-trunk-Java8 #209 (See https://builds.apache.org/job/Hadoop-Mapreduce-trunk-Java8/209/)
MAPREDUCE-6304. Specifying node labels when submitting MR jobs. (Naganarasimha G R via wangda) (wangda: rev 3164e7d83875aa6b7435d1dfe61ac280aa277f1c)

• hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-core/src/main/java/org/apache/hadoop/mapreduce/MRJobConfig.java
• hadoop-mapreduce-project/CHANGES.txt
• hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-jobclient/src/main/java/org/apache/hadoop/mapred/YARNRunner.java
• hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-app/src/main/java/org/apache/hadoop/mapreduce/v2/app/rm/RMContainerRequestor.java
• hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-jobclient/src/test/java/org/apache/hadoop/mapred/TestYARNRunner.java
• hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-app/src/test/java/org/apache/hadoop/mapreduce/v2/app/rm/TestRMContainerAllocator.java
• hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-core/src/main/resources/mapred-default.xml
• hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-app/src/main/java/org/apache/hadoop/mapreduce/v2/app/rm/RMContainerAllocator.java

SUCCESS: Integrated in Hadoop-Mapreduce-trunk #2157 (See https://builds.apache.org/job/Hadoop-Mapreduce-trunk/2157/)
MAPREDUCE-6304. Specifying node labels when submitting MR jobs. (Naganarasimha G R via wangda) (wangda: rev 3164e7d83875aa6b7435d1dfe61ac280aa277f1c)

• hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-jobclient/src/test/java/org/apache/hadoop/mapred/TestYARNRunner.java
• hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-core/src/main/resources/mapred-default.xml
• hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-app/src/test/java/org/apache/hadoop/mapreduce/v2/app/rm/TestRMContainerAllocator.java
• hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-app/src/main/java/org/apache/hadoop/mapreduce/v2/app/rm/RMContainerAllocator.java
• hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-core/src/main/java/org/apache/hadoop/mapreduce/MRJobConfig.java
• hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-jobclient/src/main/java/org/apache/hadoop/mapred/YARNRunner.java
• hadoop-mapreduce-project/CHANGES.txt
• hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-app/src/main/java/org/apache/hadoop/mapreduce/v2/app/rm/RMContainerRequestor.java

Naganarasimha G R, I just found there's one findbugs warning, I missed that before committing, could you reopen this issue and add an addendum patch to fix that?

Thanks,

Naganarasimha G R, I just found the problem is already resolved by MAPREDUCE-6421, please ignore my previous comment.

Hi Tan, Wangda
Thanks for informing but while working on this jira had looked into it and commented also, but missed to see the jira MAPREDUCE-6421 and could have been added to the exclude list ! Will keep this in mind for next time .

cc/ Naganarasimha G R, Wangda Tan, Junping Du

Currently in 2.6 branch, this patch s not present. So for users who wants to specify label at app submission time, this feature is not available . I think we can backport this to 2.6 line. I had mentioned this point in release mail thread also. Thoughts?

Sunil G,

I would suggest don't backport this issue, it's a new feature instead of criticial bug fix. And I think user who wants to try node label feature should move to more stable 2.7.x release

Hi Sunil G & Tan, Wangda,
Though this patch can be applied with slight modification, its not a blocking bug/ feature so i am ok even if its not merged with 2.6.x as usually we try to back port only the critical/blocker issues.

Thanks Wangda Tan and NGarla_Unused for the clarification. It makes sense to me to backport critical/blocker alone. But one more question, since we are not porting back features, do we have a document which specifies what all functionalities of NodeLabel is available in 2.6 line. I couldn't get much information from 2.6.4 docs.

Hi Sunil G,
YARN-2801 introduced the documentation for the nodelabels and it was committed to branch 2.7.2, so even if we back port we need to ensure only the applicable part of the document needs to be backported. but the question is anyone using nodelabels in 2.6.x release ? if so taking that effort is fine else may be not worth it. Thoughts ?

Yes. I also was having similar thoughts. If we know any user s using labels in 2.6 line, we can document only that much. I have seen the doc in 307 line, and it's pretty much fine. But I agree that effort of simple backport won't be easy as we do not have all set of functionality of labels in 2.6.
I am fine with current way, but was getting confused sometimes as Eric used a deprecated way to test labels. Also I too tested the way I do in 2.7 or trunk and met with some pblm. So it may help users if they use labels in 2.6. If its not intended, then we may not need it.

Backporting to 2.7.4

Backport to 2.7.4.

+1 (non-binding) for the 2.7.4 patch.

+1 for backport. Thanks Inigo Goiri for taking on it. Will commit shortly.

I just committed this to branch-2.7. Thanks Inigo Goiri for backport.