Mailing-List: contact yarn-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: yarn-issues@hadoop.apache.org
Date: Fri, 17 Apr 2015 11:35:02 +0000 (UTC)
From: "Hudson (JIRA)" <jira@apache.org>
To: yarn-issues@hadoop.apache.org
Message-ID: <JIRA.12765875.1420754535000.29033.1429270502129@Atlassian.JIRA>
In-Reply-To: <JIRA.12765875.1420754535000@Atlassian.JIRA>
References: <JIRA.12765875.1420754535000@Atlassian.JIRA>
 <JIRA.12765875.1420754535030@arcas>
Subject: [jira] [Commented] (YARN-3021) YARN's delegation-token handling
 disallows certain trust setups to operate properly over DistCp
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/YARN-3021?page=3Dcom.atlassian.=
jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D14499=
675#comment-14499675 ]=20

Hudson commented on YARN-3021:
------------------------------

FAILURE: Integrated in Hadoop-Hdfs-trunk #2098 (See [https://builds.apache.=
org/job/Hadoop-Hdfs-trunk/2098/])
YARN-3021. YARN's delegation-token handling disallows certain trust setups =
to operate properly over DistCp. Contributed by Yongjun Zhang (jianhe: rev =
bb6dde68f19be1885a9e7f7949316a03825b6f3e)
* hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-=
core/src/main/java/org/apache/hadoop/mapreduce/security/TokenCache.java
* hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-=
core/src/main/java/org/apache/hadoop/mapreduce/MRJobConfig.java
* hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-res=
ourcemanager/src/main/java/org/apache/hadoop/yarn/server/resourcemanager/se=
curity/DelegationTokenRenewer.java
* hadoop-yarn-project/CHANGES.txt
* hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-res=
ourcemanager/src/test/java/org/apache/hadoop/yarn/server/resourcemanager/se=
curity/TestDelegationTokenRenewer.java


> YARN's delegation-token handling disallows certain trust setups to operat=
e properly over DistCp
> -------------------------------------------------------------------------=
----------------------
>
>                 Key: YARN-3021
>                 URL: https://issues.apache.org/jira/browse/YARN-3021
>             Project: Hadoop YARN
>          Issue Type: Bug
>          Components: security
>    Affects Versions: 2.3.0
>            Reporter: Harsh J
>            Assignee: Yongjun Zhang
>             Fix For: 2.8.0
>
>         Attachments: YARN-3021.001.patch, YARN-3021.002.patch, YARN-3021.=
003.patch, YARN-3021.004.patch, YARN-3021.005.patch, YARN-3021.006.patch, Y=
ARN-3021.007.patch, YARN-3021.007.patch, YARN-3021.007.patch, YARN-3021.pat=
ch
>
>
> Consider this scenario of 3 realms: A, B and COMMON, where A trusts COMMO=
N, and B trusts COMMON (one way trusts both), and both A and B run HDFS + Y=
ARN clusters.
> Now if one logs in with a COMMON credential, and runs a job on A's YARN t=
hat needs to access B's HDFS (such as a DistCp), the operation fails in the=
 RM, as it attempts a renewDelegationToken(=E2=80=A6) synchronously during =
application submission (to validate the managed token before it adds it to =
a scheduler for automatic renewal). The call obviously fails cause B realm =
will not trust A's credentials (here, the RM's principal is the renewer).
> In the 1.x JobTracker the same call is present, but it is done asynchrono=
usly and once the renewal attempt failed we simply ceased to schedule any f=
urther attempts of renewals, rather than fail the job immediately.
> We should change the logic such that we attempt the renewal but go easy o=
n the failure and skip the scheduling alone, rather than bubble back an err=
or to the client, failing the app submission. This way the old behaviour is=
 retained.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)