[jira] [Resolved] (HADOOP-18365) Updated addresses are still accessed using the old IP address

[ https://issues.apache.org/jira/browse/HADOOP-18365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Stack resolved HADOOP-18365. Hadoop Flags: Reviewed Resolution: Fixed PR merged to branch-3.3 and to trunk

Re: [VOTE] Release Apache Hadoop 3.3.4

on a local rig here: [image: image.png] Stack On Fri, Jul 29, 2022 at 11:48 AM Steve Loughran wrote: > I have put together a release candidate (RC1) for Hadoop 3.3.4 > > The RC is available at: > https://dist.apache.org/repos/dist/dev/hadoop/hadoop-3.3.4-RC1/ > > The git tag is re

[jira] [Resolved] (HADOOP-18228) Update hadoop-vote to use HADOOP_RC_VERSION dir

[ https://issues.apache.org/jira/browse/HADOOP-18228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Stack resolved HADOOP-18228. Fix Version/s: 3.4.0 Hadoop Flags: Reviewed Resolution: Fixed > Upd

Re: [VOTE] Release Apache Hadoop 3.3.3 (RC1)

+1 (binding) * Signature: ok * Checksum : ok * Rat check (10.0.2): ok - mvn clean apache-rat:check * Built from source (10.0.2): ok - mvn clean install -DskipTests * Unit tests pass (10.0.2): ok - mvn package -P runAllTests -Dsur

Re: [VOTE] Release Apache Hadoop 3.3.3

+1 (binding) * Signature: ok * Checksum : passed * Rat check (1.8.0_191): passed - mvn clean apache-rat:check * Built from source (1.8.0_191): failed - mvn clean install -DskipTests - mvn -fae --no-transfer-progress -DskipTests -Dmaven.javadoc.skip=true -Pnative -Drequire.openssl

Re: [VOTE] Release Apache Hadoop 3.3.2 - RC5

+1 Verified checksums, signatures, and rat-check are good. Built (RC4) locally from source and ran a small hdfs cluster with hbase on top. Ran an hbase upload w/ chaos and verification and hdfs seemed to do the right thing. S On Mon, Feb 21, 2022 at 9:17 PM Chao Sun wrote: > Hi all, > > Here'

Re: [VOTE] Release Apache Hadoop 3.3.2 - RC2

+1 (binding) * Signature: ok * Checksum : ok * Rat check (1.8.0_191): ok - mvn clean apache-rat:check * Built from source (1.8.0_191): ok - mvn clean install -DskipTests Poking around in the binary, it looks good. Unpacked site. Looks right. Chec

Re: [VOTE] Release Apache Hadoop 3.3.1 RC3

+1 * Signature: ok * Checksum : ok * Rat check (1.8.0_191): ok - mvn clean apache-rat:check * Built from source (1.8.0_191): ok - mvn clean install -DskipTests Ran a ten node cluster w/ hbase on top running its verification loadings w/ (ge

Re: [VOTE] hadoop-thirdparty 1.1.0-RC0

+1 * I verified src tgz is signed with the key from https://people.apache.org/keys/committer/weichiu.asc * Verified hash. * Built from src w/ -Prelease profile * Checked CHANGES against git log. S On Thu, May 13, 2021 at 12:55 PM Wei-Chiu Chuang wrote: > Hello my fellow Hadoop developers, >

[jira] [Resolved] (HADOOP-16524) Automatic keystore reloading for HttpServer2

[ https://issues.apache.org/jira/browse/HADOOP-16524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Stack resolved HADOOP-16524. Resolution: Fixed Resolving again. Thanks for the feature [~borislav.iordanov] contrib

Re: [DISCUSS] Hadoop 3.3.1 release

On Wed, Feb 3, 2021 at 6:41 AM Steve Loughran wrote: > > Regarding blockers &c: how about we have a little hackathon where we try > and get things in. This means a promise of review time from the people with > commit rights and other people who understand the code (Stack?)

Re: [DISCUSS] Hadoop 3.3.1 release

Thanks for bringing up the topic Wei-Chiu. +1 on a 3.3.1 soon. Was going to spend time testing Yours, S On Wed, Jan 27, 2021 at 5:28 PM Wei-Chiu Chuang wrote: > Hi all, > > Hadoop 3.3.0 was released half a year ago, and as of now we've accumulated > more than 400 changes in the branch-3.3.

[jira] [Reopened] (HADOOP-16524) Automatic keystore reloading for HttpServer2

[ https://issues.apache.org/jira/browse/HADOOP-16524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Stack reopened HADOOP-16524: Reopening to revert change until fix failing yarn test. > Automatic keystore reloading

[jira] [Resolved] (HADOOP-16598) Backport "HADOOP-16558 [COMMON+HDFS] use protobuf-maven-plugin to generate protobuf classes" to all active branches

[ https://issues.apache.org/jira/browse/HADOOP-16598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Stack resolved HADOOP-16598. Resolution: Fixed Reclosing after fixing branch-2 and branch-2.9 commits (revert and

[jira] [Reopened] (HADOOP-16598) Backport "HADOOP-16558 [COMMON+HDFS] use protobuf-maven-plugin to generate protobuf classes" to all active branches

[ https://issues.apache.org/jira/browse/HADOOP-16598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Stack reopened HADOOP-16598: Thanks for checking. Reopening while I fix. > Backport "HADOOP-16558 [COMMON+H

Re: [DISCUSS] Tracing in the Hadoop ecosystem

t; > On Tue, Aug 21, 2018 at 7:50 AM Stack wrote: > > > On Tue, Aug 21, 2018 at 3:44 AM Tsuyoshi Ozawa wrote: > > > > > Thanks for starting discussion, Stack. > > > > > > The ZipKin seems to be coming to the Apache Incubator. As Andrew > > > P

Re: [DISCUSS] Tracing in the Hadoop ecosystem

On Tue, Aug 21, 2018 at 3:44 AM Tsuyoshi Ozawa wrote: > Thanks for starting discussion, Stack. > > The ZipKin seems to be coming to the Apache Incubator. As Andrew > Purtell said on HADOOP-15566, it would be good option since there is > no problem about licenses. > https

[DISCUSS] Tracing in the Hadoop ecosystem

There is a healthy discussion going on over in HADOOP-15566 on tracing in the Hadoop ecosystem. It would sit better on a mailing list than in comments up on JIRA so here's an attempt at porting the chat here. Background/Context: Bits of Hadoop and HBase had Apache HTrace trace points added. HTrace

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

On Sat, Oct 28, 2017 at 2:00 PM, Konstantin Shvachko wrote: > Hey guys, > > It is an interesting question whether Ozone should be a part of Hadoop. > I don't see a direct answer to this question. Is there one? Pardon me if I've not seen it but I'm interested in the response. I ask because IMO

Re: Can we update protobuf's version on trunk?

On Thu, Mar 30, 2017 at 9:16 AM, Chris Douglas wrote: > On Wed, Mar 29, 2017 at 4:59 PM, Stack wrote: > >> The former; an intermediate handler decoding, [modifying,] and > >> encoding the record without losing unknown fields. > >> > > > > I did not tr

Re: Can we update protobuf's version on trunk?

On Wed, Mar 29, 2017 at 3:12 PM, Chris Douglas wrote: > On Wed, Mar 29, 2017 at 1:13 PM, Stack wrote: > > Is the below evidence enough that pb3 in proto2 syntax mode does not drop > > 'unknown' fields? (Maybe you want evidence that java tooling behaves the > &g

Re: Can we update protobuf's version on trunk?

file: pb_drops_two.proto. Please use 'syntax = "proto2";' or 'syntax = "proto3";' to specify a syntax version. (Defaulted to proto2 syntax.) input:2:1: Expected identifier, got: 2 Proto 2.5 does same: $ ~/bin/protobuf-2.5.0/src/protoc --encode=Test pb_drop

Re: Can we update protobuf's version on trunk?

alternatives. Since we can't require that our > > >> applications compile (or link) against our updated schema, this > creates > > a > > >> problem that PB was supposed to solve. > > > > > > > > > This is scary, and it potentially

Re: [DISCUSS] Additional maintenance releases for Hadoop 2.y versions

Is there anyone interested in volunteering to run a 2.6.1 release (Akira?)? You'd get some help (especially if the bar is set high and only critical bug fixes are allowed in: i.e. no features, no 'perf' fixes, no jar updates, and so on). St.Ack On Wed, Jul 15, 2015 at 3:07 PM, Chris Douglas wrot

Re: Looking to a Hadoop 3 release

In general +1 on 3.0.0. Its time. If we start now, it might make it out by 2016. If we start now, downstreamers can start aligning themselves to land versions that suit at about the same time. While two big items have been called out as possible incompatible changes, and there is ongoing discussio

Re: Branching 2.5

On Fri, Aug 1, 2014 at 11:28 AM, Karthik Kambatla wrote: > Folks, > > I think we are very close to voting on RC0. Just wanted to check one > (hopefully) last thing. > > I am unable to verify the signed maven artifacts are actually deployed. To > deploy the artifacts, I did the following and it lo

Re: [VOTE] Release Apache Hadoop 2.3.0

+1 Downloaded, deployed to small cluster, and then ran an hbase loading on top of it. Looks good. Packaging wise, is it intentional that some jars show up a few times? I can understand webapps bundling a copy but doesn't mapreduce depend on commons? share/hadoop/mapreduce/lib/hadoop-annotation

Re: Re-swizzle 2.3

I filed https://issues.apache.org/jira/browse/HDFS-5852 as a blocker. See what ye all think. Thanks, St.Ack On Wed, Jan 29, 2014 at 3:52 PM, Aaron T. Myers wrote: > I just filed this JIRA as a blocker for 2.3: > https://issues.apache.org/jira/browse/HADOOP-10310 > > The tl;dr is that JNs will

[jira] [Resolved] (HADOOP-10274) Lower the logging level from ERROR to WARN for UGI.doAs method

[ https://issues.apache.org/jira/browse/HADOOP-10274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HADOOP-10274. Resolution: Fixed Fix Version/s: 2.3.0 3.0.0 Hadoop Flags: Reviewed

Re: Logistics for releasing 2.4

On Wed, Jan 22, 2014 at 5:21 PM, Arun C Murthy wrote: > Andrew, > > > On Jan 22, 2014, at 12:04 PM, Andrew Wang > wrote: > > > Monthly releases make no sense to me. > > I think the 'monthly' was a rough measure. Every 6-8 weeks works too. A regular release schedule works nicely over in hbasela

Re: Logistics for releasing 2.4

Thanks Andrew for bringing this up. +1 on more frequent releases and an effort at (roughly time-based release. We are working to get 'HDFS-5776 Support 'hedged' reads in DFSClient' to land in time for 2.4 (but don't hold up the release for us!) St.Ack On Tue, Jan 21, 2014 at 3:51 PM, Vinod Kum

Re: [VOTE] Release Apache Hadoop 2.1.0-beta

On Wed, Aug 21, 2013 at 1:25 PM, Colin McCabe wrote: > St.Ack wrote: > > > + Once I figured where the logs were, found that JAVA_HOME was not being > > exported (don't need this in hadoop-2.0.5 for instance). Adding an > > exported JAVA_HOME to my running shell which don't seem right but it took

Re: [VOTE] Release Apache Hadoop 2.1.0-beta

On Thu, Aug 15, 2013 at 2:15 PM, Arun C Murthy wrote: > Folks, > > I've created a release candidate (rc2) for hadoop-2.1.0-beta that I would > like to get released - this fixes the bugs we saw since the last go-around > (rc1). > > The RC is available at: > http://people.apache.org/~acmurthy/hadoo

Re: [ACTION NEEDED]: protoc 2.5.0 in trunk/branch-2/branch-2.1-beta/branch-2.1.0-beta

Hot dog! Any chance of the kind soul responsible for keeping up the SNAPSHOTs in apache maven updating the 2.1.x SNAPSHOT so us downstreamers can move over sooner rather than later? Thanks for the work, St.Ack On Wed, Aug 14, 2013 at 4:03 PM, Alejandro Abdelnur wrote: > Following up on this. >

[jira] [Resolved] (HADOOP-9731) Uncaught NullPointerException in MiniDFSCluster.java

[ https://issues.apache.org/jira/browse/HADOOP-9731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HADOOP-9731. --- Resolution: Incomplete Resolving as incomplete. Need more info than 'sugge

Re: Release numbering for branch-2 releases

On Mon, Feb 4, 2013 at 2:14 PM, Suresh Srinivas wrote: > On Mon, Feb 4, 2013 at 1:07 PM, Owen O'Malley wrote: > > > I think that using "-(alpha,beta)" tags on the release versions is a > really > > bad idea. > > > Why? Can you please share some reasons? > > We already had a means for denoting 'al

Re: Release numbering for branch-2 releases

On Mon, Feb 4, 2013 at 10:46 AM, Arun C Murthy wrote: > Would it better to have 2.0.3-alpha, 2.0.4-beta and then make 2.1 as a > stable release? This way we just have one series (2.0.x) which is not > suitable for general consumption. > > That contains the versioning damage to the 2.0.x set. Th

Re: Release numbering for branch-2 releases

On Fri, Feb 1, 2013 at 3:03 AM, Tom White wrote: > On Wed, Jan 30, 2013 at 11:32 PM, Vinod Kumar Vavilapalli > wrote: > > I still have a list of pending API/protocol cleanup in YARN that need to > be > > in before we even attempt supporting compatibility further down the road. > > YARN requires

Re: Release numbering for branch-2 releases

es things better since > no amount of numbering lipstick will make the software better or viable for > the long-term for both users and other projects. Worse, it will force HBase > and other projects to deal with *even more* major Hadoop releases... which > seems like a royal pita. >

Re: Release numbering for branch-2 releases

On Tue, Jan 29, 2013 at 12:56 PM, Arun C Murthy wrote: > Folks, > > There has been some discussions about incompatible changes in the > hadoop-2.x.x-alpha releases on HADOOP-9070, HADOOP-9151, HADOOP-9192 and > few other jiras. Frankly, I'm surprised about some of them since the > 'alpha' monike

Re: Unstuck QA bot

Thanks Todd. St.Ack On Wed, Dec 12, 2012 at 6:34 PM, Todd Lipcon wrote: > The QA bot was previously pointing at a JIRA filter which matched all > Patch Available issues. That number has grown to >300 across the many > projects that the QA bot works on. Unfortunately, that meant that a > lot of

Re: [VOTE] Hadoop-1.0.0 release candidate 2

On Fri, Dec 16, 2011 at 12:32 AM, Matt Foley wrote: > Dear all, > I have a clean build of the below, that passes junit testing, and was about > to post it, when I got email about the newly opened > HADOOP-7929 "Port > HADOOP-7070 to branch-1".  It

Re: 0.20.205.0 Release Candidate 1 Testing

Thanks lads, St.Ack On Thu, Oct 6, 2011 at 12:50 AM, Suresh Srinivas wrote: > This change has been already committed to 205 and 20-security (thanks > Aaron). > > On Wed, Oct 5, 2011 at 11:09 PM, Stack wrote: > >> I found what I think a critical issue w/ RC1.

Re: 0.20.205.0 Release Candidate 1 Testing

I found what I think a critical issue w/ RC1. May we get https://issues.apache.org/jira/browse/HDFS-2408 into RC2? Thanks, St.Ack On Tue, Oct 4, 2011 at 11:24 PM, Stack wrote: > On Tue, Oct 4, 2011 at 10:05 PM, Stack wrote: >> On Tue, Oct 4, 2011 at 8:59 PM, Suresh Srinivas

Re: 0.20.205.0 Release Candidate 1 Testing

On Tue, Oct 4, 2011 at 10:05 PM, Stack wrote: > On Tue, Oct 4, 2011 at 8:59 PM, Suresh Srinivas > wrote: >> Have you turned on the append supported flag in the configuration of HDFS? >> Also can you please provide steps to duplicate this problem? >> That seems to h

Re: 0.20.205.0 Release Candidate 1 Testing

On Tue, Oct 4, 2011 at 8:59 PM, Suresh Srinivas wrote: > Have you turned on the append supported flag in the configuration of HDFS? > Also can you please provide steps to duplicate this problem? > Thanks Suresh: I had it client-side only. Let me turn it on all-around. I'll be back St.Ack

Re: 0.20.205.0 Release Candidate 1 Testing

On Tue, Oct 4, 2011 at 3:41 PM, Matt Foley wrote: > I am going to spin an RC2 early tomorrow.  Does anyone have other issues > they consider critical for 205.0? I've been playing with it. Recovering the lease on an open file (An HBase WAL) the length is always zero and I don't seem to be able to

[jira] [Created] (HADOOP-7355) Add audience and stability annotations to HttpServer class

Reporter: stack Assignee: stack HttpServer has at least one subclasser in HBase. Flag this class w/ annotations that make this plain so we avoid regressions like HADOOP-7351 -- This message is automatically generated by JIRA. For more information on JIRA, see: http

[jira] [Created] (HADOOP-7351) Regression: HttpServer#getWebAppsPath used to be protected so subclasses could supply alternate webapps path but it was made private by HADOOP-6461

--- Key: HADOOP-7351 URL: https://issues.apache.org/jira/browse/HADOOP-7351 Project: Hadoop Common Issue Type: Bug Reporter: stack It USED to be protected rather than private but its access was changed by HADOOP-6461. It did the

[jira] [Created] (HADOOP-7315) Add dynamic config

Add dynamic config -- Key: HADOOP-7315 URL: https://issues.apache.org/jira/browse/HADOOP-7315 Project: Hadoop Common Issue Type: Improvement Reporter: stack I'm sure this issue exists already, at least as

Re: [VOTE] Release candidate 0.20.203.0-rc0

How hard would it be to get the patches Tom lists below into branch-0.20-security-203? I'd think it'd be an easier sell if it were a superset of all in 0.20, especially since it bears its name. Otherwise, glad to see the release candidate. St.Ack

Re: gsoc

Its a good idea Daniel. See https://issues.apache.org/jira/browse/HBASE-1109 St.Ack On Mon, Apr 5, 2010 at 1:06 PM, Allen Wittenauer wrote: > > On Apr 5, 2010, at 12:58 PM, Pek Daniel wrote: >> As far as i know Google's solution for storing static configuration is >> Chubby. Hadoop currently sug

Re: [VOTE] HADOOP-6671 - To use maven for hadoop common build

+1 for exploring. HBase TRUNK is now mavenized. Has kinks still but its getting there. Will see if can get some of the "experts" hanging in hbase space to help out with this effort. St.Ack On Thu, Apr 1, 2010 at 7:34 PM, Chris Douglas wrote: > +1 -C > > On Thursday, April 1, 2010, Giridharan K

Re: [DISCUSSION] Release process

Getting a release out is critical. Otherwise, IMO, the project is dead but for the stiffening. Thanks Tom for stepping up to play the RM role for a 0.21. Regarding Steve's call for what we can offer Tom to help along the release, the little flea hbase can test its use case on 0.21.0 candidates a

Re: Rolling a Hadoop 0.20.2

On Fri, Jan 29, 2010 at 11:26 AM, Hairong Kuang wrote: > TestFiDataTransferProtocol2 tests HDFS-101. I reversed the change made by > HDFS-101 from my local HDFS trunk and ran the test. The test failed. It > seems to me that we still need HDFS-101 in 0.20. > It would seem so. Let me know if you n

Re: Rolling a Hadoop 0.20.2

If the new release included (fixedup) hdfs-127 and hdfs-101, the hbase crew would be big fans of an hadoop 0.20.2. St.Ack On Tue, Jan 26, 2010 at 7:09 PM, Todd Lipcon wrote: > HDFS-127 was originally committed, then rolled back from 0.20 as it caused > test timeouts due to infinite loop. I put a

Re: [VOTE] Should we release Common 0.20.1-rc1?

+1. I tried this release under hbase stress loading and all seems to work at least as well as hadoop 0.20.0. St.Ack On Tue, Sep 1, 2009 at 2:20 PM, Owen O'Malley wrote: > There were some problems in the tests for 0.20.1-rc0, so I incorporated 3 > new patches that only update the tests (MR-911,

Re: [VOTE] Freeze date for Common, HDFS, and MapReduce 0.21

+1 on Sept. 18th freeze date so there is time to get a working flush in 0.21. St.Ack On Fri, Aug 14, 2009 at 9:45 AM, Tsz Wo (Nicholas), Sze < s29752-hadoop...@yahoo.com> wrote: > I thought only Append needs more time. If Map/Reduce also needs more time, > +1 on Owen's proposal (i.e. everything

Re: [VOTE] Release Hadoop 0.19.2 (candidate 0)

+1 on the RC. Downloaded it, put it under hbase, ran our PerformanceEvaluation test on our little cluster which runs clients up in MR. All passed. Browsed the UIs. All looks good. St.Ack On Wed, Jul 1, 2009 at 2:44 AM, Tom White wrote: > I have created a candidate build for Hadoop 0.19.2. Th

Re: [VOTE] Back-port TFile to Hadoop 0.20

+1 On Tue, Jul 7, 2009 at 11:55 AM, Hong Tang wrote: > I have talked with a few folks in the community who are interested in using > TFile (HADOOP-3315) in their projects that are currently dependent on Hadoop > 0.20, and it would significantly simplify the release process as well as > their liv