Branching for automatic failover work (HDFS-3042/HDFS-2185)

2012-03-28 Thread Todd Lipcon
Hi all, I've created a branch in SVN called HDFS-3042. I plan on working on the ZK-based automatic failover solution (HDFS-3042, design doc on HDFS-2185) in this branch. We'll continue to use the normal JIRA process, with review-then-commit policies in effect. The reason for the branch is that we

[jira] [Created] (HDFS-3156) TestDFSHAAdmin is failing post HADOOP-8202

2012-03-28 Thread Aaron T. Myers (Created) (JIRA)
TestDFSHAAdmin is failing post HADOOP-8202 -- Key: HDFS-3156 URL: https://issues.apache.org/jira/browse/HDFS-3156 Project: Hadoop HDFS Issue Type: Bug Components: test Affects Versions: 0

Re: [RESULT] - [VOTE] Rename hadoop branches post hadoop-1.x

2012-03-28 Thread Arun C Murthy
On Mar 27, 2012, at 10:31 PM, Arun C Murthy wrote: > I'll do the needful after midnight tonight. It should take less than > half-an-hour, and I'll send out the all clear after. > Done, all clear; I've also created jira revisions. Please let me know if you find any issues. thanks, Arun -- Ar

Re: [RESULT] - [VOTE] Rename hadoop branches post hadoop-1.x

2012-03-28 Thread Aaron T. Myers
Hey Arun, On Wed, Mar 28, 2012 at 12:28 AM, Arun C Murthy wrote: > Done, all clear; I've also created jira revisions. Please let me know if > you find any issues. > Thanks a lot for making these changes. Two questions: - Now that we've renamed branch-0.23 to branch-2, and since there is as yet

Re: [RESULT] - [VOTE] Rename hadoop branches post hadoop-1.x

2012-03-28 Thread Arun C Murthy
On Mar 28, 2012, at 12:48 AM, Aaron T. Myers wrote: > Hey Arun, > > On Wed, Mar 28, 2012 at 12:28 AM, Arun C Murthy wrote: > >> Done, all clear; I've also created jira revisions. Please let me know if >> you find any issues. >> > > Thanks a lot for making these changes. Two questions: > > -

Target/Fix Version fields in Jira

2012-03-28 Thread Arun C Murthy
Folks, Can I, please, ask committers to ensure that there is a 'single' fix-version set for each jira? Given our rules on committing to trunk first before other branches, please ensure you set the 'lowest' possible fix-version depending on the branches to which an issue is committed. Idea

Re: [RESULT] - [VOTE] Rename hadoop branches post hadoop-1.x

2012-03-28 Thread Alejandro Abdelnur
> > > > - Now that we've renamed branch-0.23 to branch-2, and since there is as > yet > > no branch-0.23.3, what should be done with JIRAs marked with the 0.23.3 > > version? Perhaps all of these should be updated to 2.0.0? > > > > Yep, in the process of doing it. > > Mhhh, shouldn't we use 2.0.3

Regarding HDFS-234 (Integration with BookKeeper logging system)

2012-03-28 Thread Uma Maheswara Rao G
Hi Devs, Seems HDFS-234 committed only in Trunk. As this is missed to commit in HA branch before, also missed in the merge from HA branch to 23 version. I think we should merge this to 23 branch as well, since this one option for shared storage. Is there any reason for not merging?

Re: Target/Fix Version fields in Jira

2012-03-28 Thread Arun C Murthy
On Mar 28, 2012, at 1:10 AM, Arun C Murthy wrote: > Can I, please, ask committers to ensure that there is a 'single' fix-version > set for each jira? Uh, too late in the night - I guess that doesn't cut it. Henceforth, please ensure it has one for each of the major branches (1.x.x & 2.x.x).

Re: Regarding HDFS-234 (Integration with BookKeeper logging system)

2012-03-28 Thread Ivan Kelly
It would be great if it did go into 0.23. -Ivan On Wed, Mar 28, 2012 at 09:17:55AM +, Uma Maheswara Rao G wrote: > Hi Devs, > > > > Seems HDFS-234 committed only in Trunk. As this is missed to commit in HA > branch before, also missed in the merge from HA branch to 23 version. > > > >

Build failed in Jenkins: Hadoop-Hdfs-0.23-Build #211

2012-03-28 Thread Apache Jenkins Server
See -- Started by timer Building remotely on hadoop2 in workspace Location 'http://svn.apache.org/repos/asf/hadoop/common/branches/branch-

Hadoop-Hdfs-0.23-Build - Build # 211 - Failure

2012-03-28 Thread Apache Jenkins Server
See https://builds.apache.org/job/Hadoop-Hdfs-0.23-Build/211/ ### ## LAST 60 LINES OF THE CONSOLE ### Started by timer Building remotely on hadoop2 in workspace /home/j

Hadoop-Hdfs-trunk - Build # 998 - Still Failing

2012-03-28 Thread Apache Jenkins Server
See https://builds.apache.org/job/Hadoop-Hdfs-trunk/998/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 12632 lines...] [INFO] Temp File is /home/jenkins/jenkins

Build failed in Jenkins: Hadoop-Hdfs-trunk #998

2012-03-28 Thread Apache Jenkins Server
See Changes: [acmurthy] Changed version in trunk to 3.0.0-SNAPSHOT. [todd] HADOOP-8218. RPC.closeProxy shouldn't throw error when closing a mock. Contributed by Todd Lipcon. [eli] HADOOP-8216. Address log4j.properties inconsistencie

[jira] [Created] (HDFS-3157) Error in deleting block is keep on coming from DN even after the block report and directory scanning has happened

2012-03-28 Thread J.Andreina (Created) (JIRA)
Error in deleting block is keep on coming from DN even after the block report and directory scanning has happened - Key: HDFS-3157 URL: https://issues.

Re: [RESULT] - [VOTE] Rename hadoop branches post hadoop-1.x

2012-03-28 Thread Todd Lipcon
On Wed, Mar 28, 2012 at 1:03 AM, Arun C Murthy wrote: > > On Mar 28, 2012, at 12:48 AM, Aaron T. Myers wrote: > >> Hey Arun, >> >> On Wed, Mar 28, 2012 at 12:28 AM, Arun C Murthy wrote: >> >>> Done, all clear; I've also created jira revisions. Please let me know if >>> you find any issues. >>> >>

Re: [RESULT] - [VOTE] Rename hadoop branches post hadoop-1.x

2012-03-28 Thread Aaron T. Myers
On Wed, Mar 28, 2012 at 11:53 AM, Todd Lipcon wrote: > Proposal: is it possible to call the JIRA fixVersion "trunk", and then > when we branch off trunk to make a release, rename it at that point to > "2.1" or "3.0" or whatever it gets called? > I like this idea. Just to be clear, I think the ex

Re: [RESULT] - [VOTE] Rename hadoop branches post hadoop-1.x

2012-03-28 Thread Todd Lipcon
On Wed, Mar 28, 2012 at 11:59 AM, Aaron T. Myers wrote: > On Wed, Mar 28, 2012 at 11:53 AM, Todd Lipcon wrote: > >> Proposal: is it possible to call the JIRA fixVersion "trunk", and then >> when we branch off trunk to make a release, rename it at that point to >> "2.1" or "3.0" or whatever it get

Re: [RESULT] - [VOTE] Rename hadoop branches post hadoop-1.x

2012-03-28 Thread Owen O'Malley
I disagree. Trunk should become branch-3 once someone wants to start stabilizing it. Arun is going to need the minor versions for when he adds features. X.Y.Z Z = bug fixes Y = minor release (compatible, adds features) X = major release (incompatible) So from branch-2 will come branch-2.0 with t

Re: [RESULT] - [VOTE] Rename hadoop branches post hadoop-1.x

2012-03-28 Thread Todd Lipcon
On Wed, Mar 28, 2012 at 12:25 PM, Owen O'Malley wrote: > I disagree. Trunk should become branch-3 once someone wants to start > stabilizing it. Arun is going to need the minor versions for when he adds > features. > > X.Y.Z > > Z = bug fixes > Y = minor release (compatible, adds features) > X = ma

Re: [RESULT] - [VOTE] Rename hadoop branches post hadoop-1.x

2012-03-28 Thread Owen O'Malley
On Wed, Mar 28, 2012 at 12:32 PM, Todd Lipcon wrote: But new features also go to trunk. And if none of our new features are > incompatible, why do we anticipate that trunk is 3.0? > Let's imagine that we already had a 2.0.0 release. Now we want to add features like HA. The only place to put that

Re: [RESULT] - [VOTE] Rename hadoop branches post hadoop-1.x

2012-03-28 Thread Arun C Murthy
On Mar 28, 2012, at 12:32 PM, Todd Lipcon wrote: > But new features also go to trunk. And if none of our new features are > incompatible, why do we anticipate that trunk is 3.0? Essentially 'trunk' is where incompatible changes *may* be committed (in future). We should allow for that. I'm amb

Re: [RESULT] - [VOTE] Rename hadoop branches post hadoop-1.x

2012-03-28 Thread Aaron T. Myers
On Wed, Mar 28, 2012 at 1:57 PM, Arun C Murthy wrote: > On on hand, we've historically bumped the version number for trunk (i.e. > 3.0.0-SNAPSHOT). This has the nice property that when we do cut a release > branch off trunk we don't have to scramble to change fix-versions on all > the jiras commi

[jira] [Created] (HDFS-3158) LiveNodes mebmber of NameNodeMXBean should list non-DFS used space and capacity per DN

2012-03-28 Thread Aaron T. Myers (Created) (JIRA)
LiveNodes mebmber of NameNodeMXBean should list non-DFS used space and capacity per DN -- Key: HDFS-3158 URL: https://issues.apache.org/jira/browse/HDFS-3158 Project:

[jira] [Created] (HDFS-3159) Document NN auto-failover setup and configuration

2012-03-28 Thread Todd Lipcon (Created) (JIRA)
Document NN auto-failover setup and configuration - Key: HDFS-3159 URL: https://issues.apache.org/jira/browse/HDFS-3159 Project: Hadoop HDFS Issue Type: Sub-task Components: auto-fail

Re: [RESULT] - [VOTE] Rename hadoop branches post hadoop-1.x

2012-03-28 Thread Arun C Murthy
On Mar 28, 2012, at 2:14 PM, Aaron T. Myers wrote: > On Wed, Mar 28, 2012 at 1:57 PM, Arun C Murthy wrote: > >> On on hand, we've historically bumped the version number for trunk (i.e. >> 3.0.0-SNAPSHOT). This has the nice property that when we do cut a release >> branch off trunk we don't have

Re: [RESULT] - [VOTE] Rename hadoop branches post hadoop-1.x

2012-03-28 Thread Aaron T. Myers
Hi Owen, On Wed, Mar 28, 2012 at 12:39 PM, Owen O'Malley wrote: > Let's imagine that we already had a 2.0.0 release. Now we want to add > features like HA. The only place to put that is in 2.1.0. On the other > hand, you don't want to pull *ALL* of the changes from trunk. That is way > too much

[jira] [Created] (HDFS-3160) httpfs should exec catalina instead of forking it

2012-03-28 Thread Roman Shaposhnik (Created) (JIRA)
httpfs should exec catalina instead of forking it - Key: HDFS-3160 URL: https://issues.apache.org/jira/browse/HDFS-3160 Project: Hadoop HDFS Issue Type: Bug Components: scripts Af

Re: [RESULT] - [VOTE] Rename hadoop branches post hadoop-1.x

2012-03-28 Thread Doug Cutting
On 03/28/2012 12:39 PM, Owen O'Malley wrote: > [ ... ] So the RM of the 2 branch needs to make the call of what > should be 2.1 vs 3.0. I thought these were community decisions, not RM decisions, no? http://s.apache.org/rm Doug