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 D421D17B0E for ; Tue, 4 Nov 2014 00:00:42 +0000 (UTC) Received: (qmail 17345 invoked by uid 500); 4 Nov 2014 00:00:42 -0000 Delivered-To: apmail-hadoop-yarn-issues-archive@hadoop.apache.org Received: (qmail 17302 invoked by uid 500); 4 Nov 2014 00:00:42 -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 17291 invoked by uid 99); 4 Nov 2014 00:00:42 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 04 Nov 2014 00:00:42 +0000 Date: Tue, 4 Nov 2014 00:00:42 +0000 (UTC) From: "Tsuyoshi OZAWA (JIRA)" To: yarn-issues@hadoop.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (YARN-2800) Should print WARN log in both RM/RMAdminCLI side when MemoryRMNodeLabelsManager is enabled 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-2800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14195407#comment-14195407 ] Tsuyoshi OZAWA commented on YARN-2800: -------------------------------------- [~leftnoteasy], If we assume the labels as a configuration which can be highly updated, ZK is not good option as you mentioned. In this case, I think NodeLabelsManager, whose backend can be leveldb or rockdb, should be loosely coupling with RM like TimelineServer for stabilization of RM. One option is making NodeLabelsManager NodeLabelsServer. It means RM should work correctly even if NodeLabelsManager is temporary unavailable. And update operation should only affect NodeLabelsManager(it doesn't affect RM). For example, RM pulls the label information from NodeLabelsServer periodically. RM treats the lable information as a hint and does schedule based on label information. Even without the information, RM should schedule apps. I think this weak consistency approach is suitable for large-scale updating. > Should print WARN log in both RM/RMAdminCLI side when MemoryRMNodeLabelsManager is enabled > ------------------------------------------------------------------------------------------ > > Key: YARN-2800 > URL: https://issues.apache.org/jira/browse/YARN-2800 > Project: Hadoop YARN > Issue Type: Sub-task > Components: client, resourcemanager > Reporter: Wangda Tan > Assignee: Wangda Tan > Attachments: YARN-2800-20141102-1.patch, YARN-2800-20141102-2.patch > > > Even though we have documented this, but it will be better to explicitly print a message in both RM/RMAdminCLI side to explicitly say that the node label being added will be lost across RM restart. -- This message was sent by Atlassian JIRA (v6.3.4#6332)