Re: [VOTE] Apache Hadoop Ozone 1.0.0 RC1

+1 (binding) 1. Verified signatures 2. Built from source 3. deployed with docker 4. tested with basic s3 apis. On Tue, Aug 25, 2020 at 7:01 AM Sammi Chen wrote: > RC1 artifacts are at: > https://home.apache.org/~sammichen/ozone-1.0.0-rc1/ >

Re: [Discuss] Ozone moving to Beta tag

+1. Given massive improvements in performance and stability, ozone is ready for beta. On Wed, Feb 19, 2020 at 1:04 PM Salvatore LaMendola (BLOOMBERG/ 919 3RD A) < slamendo...@bloomberg.net> wrote: > +1 on moving to beta. This move makes sense to me. > > I've tested each point release so far in 0.

Re: [DISCUSS] Feature branch for HDFS-14978 In-place Erasure Coding Conversion

+1 for the feature branch. On Thu, Jan 23, 2020 at 1:34 PM Wei-Chiu Chuang wrote: > Hi we are working on a feature to improve Erasure Coding, and I would like > to seek your opinion on creating a feature branch for it. (HDFS-14978 > ) > > Reason

Re: [DISCUSS] Ozone 0.4.2 release

+1 > On Dec 7, 2019, at 9:13 AM, Arpit Agarwal > wrote: > > +1 > > > >> On Dec 6, 2019, at 5:25 PM, Dinesh Chitlangia wrote: >> >> All, >> Since the Apache Hadoop Ozone 0.4.1 release, we have had significant >> bug fixes towards performance & stability. >> >> With that in mind, 0.4.2 rel

Re: [VOTE] create ozone-dev and ozone-issues mailing lists

The immediate problem we need to fix is to prevent github updates from spamming the dev mailing list. Might make sense to just have a separate issues@ mailing list and point github to that? On Sun, Oct 27, 2019 at 10:12 PM Dinesh Chitlangia wrote: > +1 > > -Dinesh > > > > > On Sun, Oct 27, 2019,

Re: [DISCUSS] Remove Ozone and Submarine from Hadoop repo

+1 On Thu, Oct 24, 2019 at 6:42 PM Ayush Saxena wrote: > Thanx Akira for putting this up. > +1, Makes sense removing. > > -Ayush > > > On 25-Oct-2019, at 6:55 AM, Dinesh Chitlangia > > > wrote: > > > > +1 and Anu's approach of creating a tag makes sense. > > > > Dinesh > > > > > > > > > >> On

Re: [VOTE] - HDDS-4 Branch merge

+1 (binding) On 1/11/19, 10:26 AM, "Ajay Kumar" wrote: +1 (non-binding) On 1/11/19, 7:40 AM, "Anu Engineer" wrote: Since I have not heard any concerns, I will start a VOTE thread now. This vote will run for 7 days and will end on Jan/18/2019 @ 8:00 AM PST.

Re: [Discuss] - HDDS-4 Branch merge

+1, This is a great effort and another milestone in making HDDS and Ozone ready for enterprises. On 1/7/19, 5:10 PM, "Anu Engineer" wrote: Hi All, I would like to propose a merge of HDDS-4 branch to the Hadoop trunk. HDDS-4 branch implements the security work for HDDS and Ozone

Re: [VOTE] Release Apache Hadoop Ozone 0.3.0-alpha (RC1)

+1 (binding) Built from source. Ran smoke tests. On 11/19/18, 9:02 AM, "Anu Engineer" wrote: +1. (Binding) Thanks for getting this release done. Verified the signatures and S3 Gateway. --Anu On 11/16/18, 5:15 AM, "Shashikant Banerjee" wrote: +

Re: [VOTE] Merge Storage Policy Satisfier (SPS) [HDFS-10285] feature branch to trunk

+1 On 7/31/18, 11:38 PM, "Uma Maheswara Rao G" wrote: Hi All, From the positive responses from JIRA discussion and no objections from below DISCUSS thread [1], I am converting it to voting thread. Last couple of weeks we spent time on testing the f

Re: [VOTE] Merge ContainerIO branch (HDDS-48) in to trunk

+1 On 6/29/18, 3:14 PM, "Bharat Viswanadham" wrote: Fixing subject line of the mail. Thanks, Bharat On 6/29/18, 3:10 PM, "Bharat Viswanadham" wrote: Hi All, Given the positive response to the discussion thread [1], here is

Re: [DISCUSS]Merge ContainerIO branch (HDDS-48) in to trunk

k we will clean up the unused classes, fix old integration tests and continue testing the changes. Thanks to Hanisha Koneru, Arpit Agarwal, Anu Engineer, Jitendra Pandey, Xiaoyu Yao, Ajay Kumar, Mukul Kumar Singh, Marton Elek and Shashikant Banerjee for their contributions i

Re: [RESULT][VOTE] Merge HDDS (HDFS-7240) *code* into trunk

w, which merged trunk at a regular >> frequency into ozone, and then ozone was merged back. >> >> Here is the mail that we followed for the merge process. >> https://lists.apache.org/thread.html/43cd65c6b6c3c0e8ac >> >> Thanks >> Xiaoyu >

[RESULT][VOTE] Merge HDDS (HDFS-7240) *code* into trunk

The vote passes with many +1s (12 committers + 5 contributors) and no -1. Thanks everyone for voting. On 4/17/18, 5:19 AM, "Jitendra Pandey" wrote: Hi All, The community unanimously voted (https://s.apache.org/HDDSMergeResult) to adopt

Re: [VOTE] Merge HDDS (HDFS-7240) *code* into trunk

> Thanks, > Hanisha > > > > > > > > > > On 4/16/18, 4:48 PM, "Jitendra Pandey" wrote: > > >Hi All, > > > > The community unanimously voted (https://s.apache.org/HDDSMergeResult) > to adopt > >HDDS/Oz

[VOTE] Merge HDDS (HDFS-7240) *code* into trunk

Hi All, The community unanimously voted (https://s.apache.org/HDDSMergeResult) to adopt HDDS/Ozone as a sub-project of Hadoop, here is the formal vote for code merge. Here is a quick summary of the code changes: - As decided in the JIRA HDFS-10419, the project has been renamed to Hadoop Di

Re: [VOTE] Adopt HDSL as a new Hadoop subproject

+1 (binding) On 3/20/18, 8:39 PM, "Weiwei Yang" wrote: +1 (non-binding) I really like this proposal and thanks for all the discussions. -- Weiwei On 21 Mar 2018, 8:39 AM +0800, Arpit Agarwal , wrote: +1 (binding) Arpit On 3/20/18, 11:21 AM, "O

Re: [VOTE] Merging branch HDFS-8707 (native HDFS client) to trunk

+1 (binding) On 3/14/18, 9:57 AM, "Anu Engineer" wrote: +1 (binding). Thanks for all the hard work and getting this client ready. It is nice to have an official and supported native client for HDFS. Thanks Anu On 3/13/18, 8:16 PM, "Mukul Kumar Singh" wrote:

Re: [VOTE] Merging branch HDFS-7240 to trunk

can choose not to build ozone/hdsl. - User: Cost to users will be completely alleviated if ozone/hdsl is not loaded as mentioned in point (3) above. jitendra From: Andrew Wang Date: Monday, March 5, 2018 at 3:54 PM To: Wangda Tan Cc: Owen O'Malley , Daryn Sharp , Jitendra Pandey , hdf

[VOTE] Merging branch HDFS-7240 to trunk

Dear folks, We would like to start a vote to merge HDFS-7240 branch into trunk. The context can be reviewed in the DISCUSSION thread, and in the jiras (See references below). HDFS-7240 introduces Hadoop Distributed Storage Layer (HDSL), which is a distributed, r

Re: [DISCUSSION] Merging HDFS-7240 Object Store (Ozone) to trunk

Hi Konstantin, Thank you for taking out time to review ozone. I appreciate your comments and questions. > There are two main limitations in HDFS > a) The throughput of Namespace operations. Which is limited by the >number of RPCs the NameNode can handle > b) The number of objects (files + b

Re: 答复: [DISCUSSION] Merging HDFS-7240 Object Store (Ozone) to trunk

I have filed https://issues.apache.org/jira/browse/HDFS-12697 to ensure ozone stays disabled in a secure environment. Since ozone is disabled by default and will not come with security on, it will not expose any new attack surface in a Hadoop deployment. Ozone security effort will need a detailed

Re: [VOTE] HDFS-1312 - Diskbalancer branch merge

I think this is a very useful feature. I have file an improvement request, but that doesn’t block the merge. I think the core functionality is complete, with good test coverage and documentation. +1 for the merge. On Jun 22, 2016, at 12:28 AM, Arpit Agarwal wrote: > This feature is frequently

Re: Why there are so many revert operations on trunk?

Colin raised the -1 demanding a design document. The document was added the very next day. There were constructive discussions on the design. There was a demand for listenable future or futures with callback, which was accepted to accommodate. Rest of the work having been completed, there was no

Re: [DISCUSS] Create branch for HDFS-8707

+1. It will be great to have a high performance async client in c++ in HDFS. There are many use cases that will benefit from this work. From: Owen O'Malley Sent: Wednesday, July 01, 2015 2:38 PM To: hdfs-dev@hadoop.apache.org Subject: [DISCUSS] Create bran

Re: [DISCUSS] Resolving the divergences for web-related code between branch-2 and trunk

+1 for removing the old UI. On Wed, Oct 1, 2014 at 4:05 PM, Suresh Srinivas wrote: > Webui equivalent data has been exposed as jmx http APIs for a long time (I > think from 0.20 release, almost 4 years ago). We have made many jsp changes > that we have made that should have broken these applicat

Re: Thinking ahead to hadoop-2.6

I also believe its worth a week's wait to include HDFS-6584 and HDFS-6581 in 2.6. On Wed, Sep 24, 2014 at 3:28 PM, Suresh Srinivas wrote: > Given some of the features are in final stages of stabilization, > Arun, we should hold off creating 2.6 branch or building an RC by a week? > All the featu

Re: [VOTE] Merge HDFS-6581 to trunk - Writing to replicas in memory.

I would consider following as blockers to merge to trunk: a) Any bugs that makes the feature unusable or cause instability or cause any regression. b) Any bad design choices that add technical debt. c) Any missing functionality, that makes the feature useless or difficult to use for its intended u

Re: [VOTE] Merge HDFS-6581 to trunk - Writing to replicas in memory.

allow HDFS > applications to start evaluating the feature. We will continue work on > documentation, performance tuning and metrics in parallel with the vote and > post-merge. > > Contributors to design and code include Xiaoyu Yao, Sanjay Radia, Jitendra > Pandey, Tassapol Athiap

Re: [VOTE] Merge HDFS-6584 Archival Storage to trunk

; > user documentation, adding a test plan doc, adding more tests and fixing > > some > > minor bugs. We will finish all of the > > remaining work before merging the branch to trunk. > > > > The contributors of this work include Jing Zhao, Arpit > > Agarwal, V

Re: [VOTE] Change by-laws on release votes: 5 days instead of 7

+1 On Tue, Jun 24, 2014 at 6:42 AM, Thomas Graves < tgra...@yahoo-inc.com.invalid> wrote: > +1 > > Tom > > On 6/24/14, 3:53 AM, "Arun C Murthy" wrote: > > >Folks, > > > > As discussed, I'd like to call a vote on changing our by-laws to change > >release votes from 7 days to 5. > > > > I've atta

Re: [DISCUSS] Change by-laws on release votes: 5 days instead of 7

+1, sounds good! On Mon, Jun 23, 2014 at 12:02 PM, Andrew Wang wrote: > +1 here as well, let's do a vote thread (for 7 days, maybe for the last > time!) > > > On Mon, Jun 23, 2014 at 11:46 AM, Vinod Kumar Vavilapalli < > vino...@apache.org> wrote: > > > This seems reasonable, +1. > > > > In cas

Re: Proposal: abandon protocol translator layer for cluster-internal RPCs

Wire compatibility in hdfs private protocols between different components is also important for rolling upgrades. We do want to support upgrading different components of a cluster independent of each other and wire compatibility is one of the essential prerequisites. Therefore, even if some prot

Re: [VOTE] Merge the HA branch to trunk tomorrow - March 2nd

+1. On Thu, Mar 1, 2012 at 9:05 PM, Aaron T. Myers wrote: > Hello HDFS devs, > > As mentioned in a thread started last week, I'd like to merge the HA branch > to trunk. I had originally intended to do this yesterday, but ran into some > last minute issues, and as such would like to do it tomorro

Re: Merging the HA branch to trunk - Wednesday, February 29th

That's a great plan! We have also been running tests and performance benchmarks for some time now, and the HA branch seems to be in decent shape to be merged back to the trunk. I had a merge-patch to do some pre-merge testing, which I have uploaded on the jira, but I agree we should wait for these

Re: Retire 0.20-append branch?

+1. On Mon, Oct 3, 2011 at 10:15 PM, Owen O'Malley wrote: > On Mon, Oct 3, 2011 at 2:50 PM, Todd Lipcon wrote: > > In essence, that means that we would: > > 1) Ask contributors to provide patches against 0.20-security branch > > instead of 0.20-append > > +1 > > > 2) Move the branch itself into