Return-Path: X-Original-To: apmail-falcon-dev-archive@minotaur.apache.org Delivered-To: apmail-falcon-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 26B081886C for ; Thu, 10 Dec 2015 01:19:29 +0000 (UTC) Received: (qmail 49686 invoked by uid 500); 10 Dec 2015 01:19:24 -0000 Delivered-To: apmail-falcon-dev-archive@falcon.apache.org Received: (qmail 49635 invoked by uid 500); 10 Dec 2015 01:19:24 -0000 Mailing-List: contact dev-help@falcon.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@falcon.apache.org Delivered-To: mailing list dev@falcon.apache.org Received: (qmail 49620 invoked by uid 99); 10 Dec 2015 01:19:23 -0000 Received: from Unknown (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 10 Dec 2015 01:19:23 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id 854BC180AB6 for ; Thu, 10 Dec 2015 01:19:23 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -0.554 X-Spam-Level: X-Spam-Status: No, score=-0.554 tagged_above=-999 required=6.31 tests=[RP_MATCHES_RCVD=-0.554] autolearn=disabled Received: from mx1-us-east.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id hIHPNA_SP6dO for ; Thu, 10 Dec 2015 01:19:12 +0000 (UTC) Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx1-us-east.apache.org (ASF Mail Server at mx1-us-east.apache.org) with SMTP id BFC2742989 for ; Thu, 10 Dec 2015 01:19:11 +0000 (UTC) Received: (qmail 49435 invoked by uid 99); 10 Dec 2015 01:19:11 -0000 Received: from arcas.apache.org (HELO arcas) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 10 Dec 2015 01:19:11 +0000 Received: from arcas.apache.org (localhost [127.0.0.1]) by arcas (Postfix) with ESMTP id 0C3262C1F6D for ; Thu, 10 Dec 2015 01:19:11 +0000 (UTC) Date: Thu, 10 Dec 2015 01:19:11 +0000 (UTC) From: "Venkat Ranganathan (JIRA)" To: dev@falcon.incubator.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (FALCON-141) Support cluster updates 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/FALCON-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15049811#comment-15049811 ] Venkat Ranganathan commented on FALCON-141: ------------------------------------------- [~sriksun] Thanks for the update. bq. Would this be necessary, as all entities that are dependent on the cluster should go through an update. Or in other words requireUpdate is derivable and it may be unnecessary to maintain this as an explicit state. I think we need to have a mechanism to say what have been updated post cluster update so that failed updates can be re-attempted later - not to identify what to change after the cluster update work. as you said bq. Also what happens for entity instances which were complete before the cluster update and which may require a re-run after the update Failed instances before the update with old coordinator will not run - One way is to create the new coordinators only when JT/RM or NN interfaces change and otherwise update existing entities so that reruns are handled correctly in those cases. And whenever JT/RM or NN endpoints change, we can issue a warning saying that post the update and procesing, reruns for instances prior to the update cannot be done > Support cluster updates > ----------------------- > > Key: FALCON-141 > URL: https://issues.apache.org/jira/browse/FALCON-141 > Project: Falcon > Issue Type: Bug > Reporter: Shwetha G S > Assignee: Balu Vellanki > -- This message was sent by Atlassian JIRA (v6.3.4#6332)