Return-Path: X-Original-To: apmail-hadoop-yarn-issues-archive@minotaur.apache.org Delivered-To: apmail-hadoop-yarn-issues-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id D2ED31790F for ; Wed, 22 Oct 2014 03:38:35 +0000 (UTC) Received: (qmail 62277 invoked by uid 500); 22 Oct 2014 03:38:34 -0000 Delivered-To: apmail-hadoop-yarn-issues-archive@hadoop.apache.org Received: (qmail 62227 invoked by uid 500); 22 Oct 2014 03:38:34 -0000 Mailing-List: contact yarn-issues-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: yarn-issues@hadoop.apache.org Delivered-To: mailing list yarn-issues@hadoop.apache.org Received: (qmail 62211 invoked by uid 99); 22 Oct 2014 03:38:34 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 22 Oct 2014 03:38:34 +0000 Date: Wed, 22 Oct 2014 03:38:34 +0000 (UTC) From: "Vinod Kumar Vavilapalli (JIRA)" To: yarn-issues@hadoop.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (YARN-1915) ClientToAMTokenMasterKey should be provided to AM at launch time MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/YARN-1915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14179528#comment-14179528 ] Vinod Kumar Vavilapalli commented on YARN-1915: ----------------------------------------------- bq. Yes, I thought the ugi mangling was gone, but the AMRMToken is indeed manually removed. I had a JIRA for fixing this, so that NMs themselves will remove it for non-AM containers, will find it. bq. I'm assuming there was a valid reason why the secret is passed in the registration response, perhaps for future functionality. The secret used to be in env. We moved it to registration because of security issues in Windows. bq. However there's some confusion as to how the client token master key should be sent to the RM (e.g.: via container credentials, via the current method, etc.). We can deprecate the key returning in response and instead put it inside container credentials. The credentials is unfortunately named as 'tokens' - it was always token so far. We could deprecate tokens too and instead move to credentials ala CredentialsInfo for web-services. The wait in the current patch is worrisome *only* if we have large number of clients pinging in and blocking RPC handlers. This doesn't happen in practice though, I'm okay getting it in for 2.6. > ClientToAMTokenMasterKey should be provided to AM at launch time > ---------------------------------------------------------------- > > Key: YARN-1915 > URL: https://issues.apache.org/jira/browse/YARN-1915 > Project: Hadoop YARN > Issue Type: Sub-task > Affects Versions: 2.2.0 > Reporter: Hitesh Shah > Assignee: Jason Lowe > Priority: Blocker > Attachments: YARN-1915.patch, YARN-1915v2.patch, YARN-1915v3.patch > > > Currently, the AM receives the key as part of registration. This introduces a race where a client can connect to the AM when the AM has not received the key. > Current Flow: > 1) AM needs to start the client listening service in order to get host:port and send it to the RM as part of registration > 2) RM gets the port info in register() and transitions the app to RUNNING. Responds back with client secret to AM. > 3) User asks RM for client token. Gets it and pings the AM. AM hasn't received client secret from RM and so RPC itself rejects the request. -- This message was sent by Atlassian JIRA (v6.3.4#6332)