Jason Lowe commented on YARN-2884:

Note that not all applications pick up configs from the nodes, and I don't see 
how relying on a HADOOP_CONF_DIR modification will address them.  For example, 
our setup runs a MapReduce job as a self-contained application -- it does not 
reference the jars nor the configs on the cluster nodes.  This makes rolling 
upgrades more reliable, otherwise a config change on the node could break old 
code in a job or new code in a job could break on an old node config.  This 
happened in practice which is why our jobs no longer rely on confs from the 
nodes.  HADOOP_CONF_DIR does _not_ show up on the classpath for such 
applications, otherwise they would be relying on server-side configs and lead 
to the rolling upgrade instabilities.

Any ideas on how to address the self-contained application scenario?

> Proxying all AM-RM communications
> ---------------------------------
>                 Key: YARN-2884
>                 URL: https://issues.apache.org/jira/browse/YARN-2884
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>          Components: nodemanager, resourcemanager
>            Reporter: Carlo Curino
>            Assignee: Kishore Chaliparambil
>         Attachments: YARN-2884-V1.patch, YARN-2884-V2.patch, 
> YARN-2884-V3.patch, YARN-2884-V4.patch, YARN-2884-V5.patch, 
> YARN-2884-V6.patch, YARN-2884-V7.patch, YARN-2884-V8.patch, YARN-2884-V9.patch
> We introduce the notion of an RMProxy, running on each node (or once per 
> rack). Upon start the AM is forced (via tokens and configuration) to direct 
> all its requests to a new services running on the NM that provide a proxy to 
> the central RM. 
> This give us a place to:
> 1) perform distributed scheduling decisions
> 2) throttling mis-behaving AMs
> 3) mask the access to a federation of RMs

This message was sent by Atlassian JIRA

Reply via email to