From common-dev-return-99232-archive-asf-public=cust-asf.ponee.io@hadoop.apache.org Sun Mar 18 21:46:12 2018 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id 55DF2180645 for ; Sun, 18 Mar 2018 21:46:11 +0100 (CET) Received: (qmail 32565 invoked by uid 500); 18 Mar 2018 20:46:08 -0000 Mailing-List: contact common-dev-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list common-dev@hadoop.apache.org Received: (qmail 32519 invoked by uid 99); 18 Mar 2018 20:46:07 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 18 Mar 2018 20:46:07 +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 DFF4018048E; Sun, 18 Mar 2018 20:46:06 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 2.88 X-Spam-Level: ** X-Spam-Status: No, score=2.88 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_REPLY=1, HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_RED=0.001] autolearn=disabled Authentication-Results: spamd3-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id RBQtDV_mB0L9; Sun, 18 Mar 2018 20:46:04 +0000 (UTC) Received: from mail-qk0-f169.google.com (mail-qk0-f169.google.com [209.85.220.169]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTPS id 2EBFD5F3B9; Sun, 18 Mar 2018 20:46:04 +0000 (UTC) Received: by mail-qk0-f169.google.com with SMTP id s188so16343799qkb.2; Sun, 18 Mar 2018 13:46:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YPqwy6cLokLk9o2Jb7C41GOlhBCHTEO+esfiYuOaxd8=; b=LbObmKv/3YlcFWG9DH0PSS8VX0sGFmK46rc99QD7PMfAm1ISzEV8HNhedXR92eJ0xQ YLiMHVIIzH0dLiGeMUx7r5EjI41McUv2Qbm48tj8MLtmc3sB/fi9F5IC3DxXHJDvnTrD uA78dQzK17FvsZkej8Lch6Z+KSwzSVcYY6O6Vk03WTvc9XtefJIkMucwpfE/4GGGIkRo pgb0astZNtEzCEsWrzYpl474Lkz9jIIkS9+i66Z2PEFcleVFBU45DT3V7Wr6/Yv/Qo1i 6iuLDSB1TNEsnls5nA9m1wFqR9SSFi8M/H4Z2MuNmPcAtvVR1a1PsKwtFXM6rZJIKTor XFkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YPqwy6cLokLk9o2Jb7C41GOlhBCHTEO+esfiYuOaxd8=; b=taTS+6/Zk1dm5ZguF35z4YwrayG4oqw0yqMwS0EM6qA72tDNCP34lRKTS2ILo27bkJ HdDgWKlG5QP55lnKD/32NFHoFgjGX0dHaST4QuQChIpam+EgzKOcRsb3eSx41JA09i8B AacsC8i5OZrsrsBn6S95bwKXqNfZ3r4ez2bphEv4UFGs632VFqIVT/LibdgV0Z5IVDOg 7++Cxj/sNXg6CAM5Gk0EiT7sPq2rAoBXOFb4mKpwarzQigUzi90wtgbs+3tQ8NrPBi5j Rx4Hw4ANQmlb1isPx+axCDRFfEICf2vx8BiWLsjB5xC1XjA+SwgHS6MaRa6FkJ+dG1T9 H9/Q== X-Gm-Message-State: AElRT7G2cVF8txyeKagqoEwaoqUULsaFRvKjTsc9WwFVL7dHq+Ijc1wT bYHmEZFxOGajp1y3FlOmdFtHbKbsPTWFOQ9OtrI= X-Google-Smtp-Source: AG47ELsX2RijcOT+1PAcpReWTrlox+yin38Fa0SMyITva/ya+WIwRFG22VKavnqCXKXN+owDyBryfyFuhv7oOCOsi0A= X-Received: by 10.55.209.217 with SMTP id o86mr14388511qkl.231.1521405958304; Sun, 18 Mar 2018 13:45:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.212.204 with HTTP; Sun, 18 Mar 2018 13:45:57 -0700 (PDT) In-Reply-To: <0B68BCFE-D4C5-448D-9F07-035F4288756A@hortonworks.com> References: <460F525D-20D1-42DB-A064-2512CC070614@hortonworks.com> <1166A019-B47C-4BAD-A553-50EEE16853A1@hortonworks.com> <0B68BCFE-D4C5-448D-9F07-035F4288756A@hortonworks.com> From: Konstantin Shvachko Date: Sun, 18 Mar 2018 13:45:57 -0700 Message-ID: Subject: Re: [VOTE] Merging branch HDFS-7240 to trunk To: Sanjay Radia Cc: "Owen O'Malley" , Jitendra Pandey , Andrew Wang , Wangda Tan , hdfs-dev , "common-dev@hadoop.apache.org" , "yarn-dev@hadoop.apache.org" , "mapreduce-dev@hadoop.apache.org" Content-Type: multipart/alternative; boundary="001a1147a4bab438500567b5edca" --001a1147a4bab438500567b5edca Content-Type: text/plain; charset="UTF-8" The proposal to add it as a subproject of Hadoop makes sense to me. Thank you Owen. I am glad to have a path for scaling HDFS further, especially as it enters areas like IoT and self-driving cars, where storage requirements are huge. I am not very fond of the name HDSL, though. "Storage Layer" sounds too generic. May be something more descriptive, like HDDS / HDSS (Hadoop Dynamically Distributed/Scaling Storage). We can discuss this in the jira HDFS-10419. Thanks, --Konstantin On Fri, Mar 16, 2018 at 3:17 PM, Sanjay Radia wrote: > Owen, > Thanks for your proposal. > While I would have prefered to have HDSL in HDFS and also to be part > of Hadoop releases for the reasons stated earlier in this thread, > I am willing to accept your proposal as a compromise to move this forward. > > Jitendra, Anu, Daryn, Andrew, Konstantine your thoughts? > > Thanks > > Sanjay > > > On Mar 14, 2018, at 1:50 PM, Owen O'Malley owen.omalley@gmail.com>> wrote: > > This discussion seems to have died down coming closer consensus without a > resolution. > > I'd like to propose the following compromise: > > * HDSL become a subproject of Hadoop. > * HDSL will release separately from Hadoop. Hadoop releases will not > contain HDSL and vice versa. > * HDSL will get its own jira instance so that the release tags stay > separate. > * On trunk (as opposed to release branches) HDSL will be a separate module > in Hadoop's source tree. This will enable the HDSL to work on their trunk > and the Hadoop trunk without making releases for every change. > * Hadoop's trunk will only build HDSL if a non-default profile is enabled. > * When Hadoop creates a release branch, the RM will delete the HDSL module > from the branch. > * HDSL will have their own Yetus checks and won't cause failures in the > Hadoop patch check. > > I think this accomplishes most of the goals of encouraging HDSL development > while minimizing the potential for disruption of HDFS development. > > Thoughts? Andrew, Jitendra, & Sanjay? > > Thanks, > Owen > > --001a1147a4bab438500567b5edca--