From issues-return-66303-archive-asf-public=cust-asf.ponee.io@ambari.apache.org Mon Feb 5 20:20:04 2018 Return-Path: X-Original-To: archive-asf-public@eu.ponee.io Delivered-To: archive-asf-public@eu.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by mx-eu-01.ponee.io (Postfix) with ESMTP id E6A86180647 for ; Mon, 5 Feb 2018 20:20:04 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id D6647160C4B; Mon, 5 Feb 2018 19:20:04 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 2B463160C3B for ; Mon, 5 Feb 2018 20:20:04 +0100 (CET) Received: (qmail 53504 invoked by uid 500); 5 Feb 2018 19:20:03 -0000 Mailing-List: contact issues-help@ambari.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@ambari.apache.org Delivered-To: mailing list issues@ambari.apache.org Received: (qmail 53464 invoked by uid 99); 5 Feb 2018 19:20:03 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 05 Feb 2018 19:20:03 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id 732DDC0010 for ; Mon, 5 Feb 2018 19:20:02 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -110.311 X-Spam-Level: X-Spam-Status: No, score=-110.311 tagged_above=-999 required=6.31 tests=[ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_SPF_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=disabled Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id 3tw2zP87RgNg for ; Mon, 5 Feb 2018 19:20:01 +0000 (UTC) Received: from mailrelay1-us-west.apache.org (mailrelay1-us-west.apache.org [209.188.14.139]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTP id 580D95FAC2 for ; Mon, 5 Feb 2018 19:20:01 +0000 (UTC) Received: from jira-lw-us.apache.org (unknown [207.244.88.139]) by mailrelay1-us-west.apache.org (ASF Mail Server at mailrelay1-us-west.apache.org) with ESMTP id AF3A0E01AD for ; Mon, 5 Feb 2018 19:20:00 +0000 (UTC) Received: from jira-lw-us.apache.org (localhost [127.0.0.1]) by jira-lw-us.apache.org (ASF Mail Server at jira-lw-us.apache.org) with ESMTP id 1AA0621E88 for ; Mon, 5 Feb 2018 19:20:00 +0000 (UTC) Date: Mon, 5 Feb 2018 19:20:00 +0000 (UTC) From: "Siddharth Wagle (JIRA)" To: issues@ambari.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Updated] (AMBARI-22916) BE: Support Name Federation in Ambari 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/AMBARI-22916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Siddharth Wagle updated AMBARI-22916: ------------------------------------- Description: We are pulling in Name Node federation support in HDFS/HDP 3.0, requires Ambari support for NN Federation. Details ====== What NN federation allows is to share the Data Nodes between a set of independent Name Nodes. Each NN has its own standby and has the meta-data pointing to the blocks in the data nodes, however, they might share the Data Nodes. This will let us scale to 250M files for each NN and add more NNs as we go beyond 250M files. Ambari support will be required to make sure we can manage and configure NN federation. was: We are pulling in Name Node federation support in HDFS/HDP 3.0, requires Ambari support for NN Federation. This is a major pain point for many customers and is part of. Details ====== What NN federation allows is to share the Data Nodes between a set of independent Name Nodes. Each NN has its own standby and has the meta-data pointing to the blocks in the data nodes, however, they might share the Data Nodes. This will let us scale to 250M files for each NN and add more NNs as we go beyond 250M files. Ambari support will be required to make sure we can manage and configure NN federation. > BE: Support Name Federation in Ambari > ------------------------------------- > > Key: AMBARI-22916 > URL: https://issues.apache.org/jira/browse/AMBARI-22916 > Project: Ambari > Issue Type: Epic > Components: ambari-server > Affects Versions: 2.7.0 > Reporter: Paul Codding > Assignee: Siddharth Wagle > Priority: Critical > Fix For: 2.7.0 > > > We are pulling in Name Node federation support in HDFS/HDP 3.0, requires Ambari support for NN Federation. > Details > ====== > What NN federation allows is to share the Data Nodes between a set of independent Name Nodes. Each NN has its own standby and has the meta-data pointing to the blocks in the data nodes, however, they might share the Data Nodes. This will let us scale to 250M files for each NN and add more NNs as we go beyond 250M files. > Ambari support will be required to make sure we can manage and configure NN federation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)