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 4082910E77 for ; Wed, 7 Aug 2013 18:10:58 +0000 (UTC) Received: (qmail 46790 invoked by uid 500); 7 Aug 2013 18:10:54 -0000 Delivered-To: apmail-hadoop-yarn-issues-archive@hadoop.apache.org Received: (qmail 46477 invoked by uid 500); 7 Aug 2013 18:10:54 -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 46070 invoked by uid 99); 7 Aug 2013 18:10:53 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 07 Aug 2013 18:10:53 +0000 Date: Wed, 7 Aug 2013 18:10:53 +0000 (UTC) From: "Sandy Ryza (JIRA)" To: yarn-issues@hadoop.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (YARN-1018) prereq check for AMRMClient.ContainerRequest relaxLocality flag wrong 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-1018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13732244#comment-13732244 ] Sandy Ryza commented on YARN-1018: ---------------------------------- If I understand correctly, you're saying that someone might want to colocate containers with other containers that have already been scheduled, so the first can be anywhere, and the later ones need to be strictly on the same node(s) as the first. While this is a situation that we should support, it seems to me that it should require the special handling that you're suggesting. By the semantics of relaxLocality, the first request is expected to behave semantically differently than the ones that will come after it. It is not a strictly local request, so setting the relaxLocality flag to false on it doesn't make sense. > prereq check for AMRMClient.ContainerRequest relaxLocality flag wrong > --------------------------------------------------------------------- > > Key: YARN-1018 > URL: https://issues.apache.org/jira/browse/YARN-1018 > Project: Hadoop YARN > Issue Type: Bug > Components: client > Affects Versions: 2.1.0-beta > Reporter: Steve Loughran > Priority: Minor > > Trying to create a container request with no racks/nodes and no relaxed priority fails > {code} > new AMRMClient.ContainerRequest(capability, null, null, 0, false); > {code} > expected: a container request. > actual: stack trace saying I can't relax node locality. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira