[Hadoop-common-dev] [VOTE] Release 0.20.204.0-rc0

Is it still failing to build according to Jenkins?

Myself and Eric Yang are looking into this.
-Giri

This issue is fixed with Eric's patch for HADOOP-7356. Since Owen is out on
vacation Iam working on getting the release tarball.

-Giri

Shouldn't this vote be taking place on general@, instead of common-dev@? I'm
under the impression that that is where all votes are supposed to take
place. Please correct me if I am wrong about that.

Nope. general@ is only for announcements.

AFAIK Votes are developer activities.

Arun

Somehow I remember that the 0.20.203.0 vote was carried out on general@

Here is a message from the archive:

http://mail-archives.apache.org/mod_mbox/hadoop-general/201105.mbox/browser

- milind

---
Milind Bhandarkar


-----Original Message-----
From: Arun C Murthy
Sent: Thursday, July 28, 2011 5:27 PM
To: [email protected]
Subject: Re: [VOTE] Release 0.20.204.0-rc0

Nope. general@ is only for announcements.

AFAIK Votes are developer activities.

Arun

In the past we've carried it out on common-dev:
http://hadoop-common.472056.n3.nabble.com/VOTE-Release-Hadoop-0-21-0-candidate-2-td1181981.html

Arun

We've done both, even within a branch (0.20.0 was voted on core-dev@
and 0.20.2 on general@). The bylaws suggest general@ should be used,
which seems to make sense since we're releasing common, hdfs and mr. I
think either works as long as people know where to check.

http://hadoop.apache.org/bylaws.html

"Voting
Decisions regarding the project are made by votes on the primary
project development mailing list ([email protected])"

Thanks for the link Eli.
IMO general@ isn't the primary 'development' mailing list - it's just an 'announcement' list.

But, it doesn't really matter... do folks feel strongly we should restart the vote on general?

Arun

I don't think there's need to restart the vote. I only brought this up
because I've heard from a few people that they didn't know a release vote
was going on. Let's just send an email to general@ saying there's a vote
going on on common-dev@, and from now on be sure to send votes to general@.
As Eli already said, it doesn't matter which it is, as long as people know
where to look.

Done. Thanks.

I'd like to rm the log4j.properties file; I'll apply the patch for this
to the branch and build and test locally. Yes: test.

I've committed the HADOOP-7468 patch to build.xml to stop
conf/log4.properties going into the JAR to trunk.

There's a separate patch for the 0.20.204 release, which I'd argue for
inclusion
1. It doesn't impact the server code
2. It breaks any app downstream that wants its own log4j. To be
precise, it causes inconsistent behaviour depending on the classpath
ordering.

This change isn't going to impact any of the hadoop scripts -including
client side ones- that have a the conf/ dir on the classpath.

-Steve

I can't believe we're holding a vote on a release that isn't passing the nightly build. If my vote was binding, I'd -1 it based upon that alone.

Allen,
I think Giri already sent out an email for that. Below is the
response from him. There'll be a new rc candidate soon.

Hope that helps.

thanks
mahadev


===================================

This issue is fixed with Eric's patch for HADOOP-7356. Since Owen is out on
vacation Iam working on getting the release tarball.

-Giri
==============================

Incidentally, has anyone tested on Java7.

The Lucene team are unhappy:
http://www.lucidimagination.com/search/document/1a0d3986e48a9348/warning_index_corruption_and_crashes_in_apache_lucene_core_apache_solr_with_java_7

JAR. Someone did a patch for it yesterday
This bug is not marked as a blocker. In that case I think we should pick
this up in 205 release that is going to out soon.

I do not think this is blocker either.

New release candidate will be out soon that fixes the Jenkins failures. Vote
will resume on that RC.

Regards,
Suresh

Hi,
Four critical patches have been applied to 0.20-security-204, and release
candidate 0.20.204-rc1 is now ready for evaluation.
The signed release is available at
http://people.apache.org/~mattf/hadoop-0.20.204-rc1/
A successful build and test under Jenkins may be examined at
https://builds.apache.org/view/G-L/view/Hadoop/job/Hadoop-0.20.204-Build/24/

The four changes since rc0 are:

------------------------------------------------------------------------
r1152887 | mattf | 2011-08-01 11:32:12 -0700 (Mon, 01 Aug 2011) | 1 line
HDFS-2218. Disable TestHdfsProxy.testHdfsProxyInterface in automated test
suite for 0.20-security-204 release.
------------------------------------------------------------------------
r1152037 | gkesavan | 2011-07-28 23:39:42 +0000 (Thu, 28 Jul 2011) | 1 line
HADOOP-7356. Fix bin scripts to support dev build environment
------------------------------------------------------------------------
r1150862 | ddas | 2011-07-25 19:32:59 +0000 (Mon, 25 Jul 2011) | 1 line
Merge -r 1150859:1150860 from branch-0.20-security onto
branch-0.20-security-204
------------------------------------------------------------------------
r1150857 | ddas | 2011-07-25 19:28:14 +0000 (Mon, 25 Jul 2011) | 1 line
MAPREDUCE-2621. Merge -r 1150527:1150528 from branch-0.20-security onto
branch-0.20-security-204
------------------------------------------------------------------------


Although Owen is the RM for this release, he requested assistance in
progressing the release while he is traveling.
Please resume the 0.20.204 release vote today, using this rc1 candidate.

Thank you,
--Matt

I'm getting confused about release roadmaps right now


Is there somewhere that lists the (proposed) timetable for the 0.20.204,
0.20.205, 0.22, 0.23 releases?

It sounds like any non-critical problem in 20.204rc0 is intended to go
into to the 0.20.205 release. Correct? If so is there a release manager
or can I go ahead and patch in the normal RTC process?

branch-20 is the new trunk, given that features keep popping up in it rather than bug fixes.

When we voted to adopt 203.rc0 we also voted to adopt the new 4 part
version scheme which was intended to allow feature development on the
203.x series. See http://search-hadoop.com/m/iegPf7aDvh1

branch-20-security is not the new trunk, trunk and branches from trunk
are where most of the action is happening. However it is disappointing
to see some of the features being developed on branch-20-security,
rather being developed first on trunk and then ported to
branch-20-security.

Thanks,
Eli

... which was exactly my point.

Yes, I think this is wrong

Every feature should go into trunk then be backported to the branch, so
that trunk is a proper superset of the branch

RPM packaging and Ganglia plugin for metrics v2 features committed to trunk before in branch-0.20-security. There is no rule that declares the new feature landed in trunk needs to materialized into a release then back port is allowed to happen. Those are the only two new minor features that were back ported from trunk to 0.20 security branch. No one is using branch-0.20-security as their new trunk. Hence, the 4 part version number should not apply.

Majority of users are not affected by the utility features introduced in 0.20.204. Change Log shows what is in this release. 0.20.204 is incremental improvement of existing 0.20.x release.

regards,
Eric

No one is suggesting that. We're saying features should be developed
on trunk first, before being backported to a release branch. Yes,
there is no current rule that says trunk needs to be a superset of
branch-0.20, but it would help us not get stuck on a given release for
too long.
There are others, eg MR disk failure handling, MR security, etc. that
are not in trunk but are in branch-0.20-security.
If that's so then why use a 4 part version (0.20.204.0)?

Thanks,
Eli

This makes things clearer.

Now, if I were to propagate a change from trunk to the 0.20.20x branch
by committing it to
https://svn.apache.org/repos/asf/hadoop/common/branches/branch-0.20-security-204/
, that's going to get into .204? Yet my proposal to do what was
rejected, saying "hold for .205". Should someone create a .205 branch so
that we can backport all non-critical patches for the 20.20x line into
there, while the 0.20.204 becomes frozen for the release except for
absolutely critical patches?

Here's the analysis of changes in 204 vs trunk. We believe that ALL the
changes in 204 are either already in trunk or do not need to be in trunk.
Here is the list of 204 items not already in trunk, and their
categorization.

Please, if anyone thinks we've missed something, bring it to my attention
and if it isn't already in trunk we will get it into trunk as expeditiously
as possible.
Thanks,
--Matt

Not needed for trunk:
HDFS-1758. Make Web UI JSP pages thread safe. (Tanping via suresh) (Not a
problem in trunk)
HDFS-2057. Wait time to terminate the threads causes unit tests to take
longer time. (Bharath Mundlapudi via suresh) (Not a problem in trunk)
HDFS-1878. TestHDFSServerPorts unit test failure - race condition in
FSNamesystem.close() causes NullPointerException without serious
consequence. (mattf) (not a problem in trunk)
HDFS-1842. Handle editlog opcode conflict with 0.20.203 during upgrade, by
throwing an error to indicate the editlog needs to be empty. (suresh)
(Handled by HDFS-1824)
HDFS-2218. Disable TestHdfsProxy.testHdfsProxyInterface in automated test
suite for 0.20-security-204 release. (Matt Foley) (Not a problem in trunk)
HDFS-2044. TestQueueProcessingStatistics failing automatic test due to
timing issues. (mattf) (not a problem in trunk)
HADOOP-7459. Remove jdk-1.6.0 dependency check from rpm. (omalley) (replaced
by HDFS-2156)
HADOOP-7398. Suppress warnings about use of HADOOP_HOME. (omalley) (not a
problem in trunk)
HADOOP-7369. Fix permissions in tarball for sbin/* and libexec/* (omalley)
(not a problem in trunk)
HADOOP-7373. Fix {start,stop}-{dfs,mapred} and hadoop-daemons.sh from trying
to use the wrong bin directory. (omalley) (not a problem in trunk)
HADOOP-7475. Fix hadoop-setup-single-node.sh to reflect new layout. (eyang
via omalley) (not a problem in trunk)

Back port from trunk:
MAPREDUCE-2524. Port reduce failure reporting semantics from trunk, to fail
faulty maps more aggressively. (Thomas Graves via cdouglas)
MAPREDUCE-2479. Move distributed cache cleanup to a background task,
backporting MAPREDUCE-1568. (Robert Joseph Evans via cdouglas)
HDFS-2023. Backport of NPE for File.list and File.listFiles. Merged ports
of HADOOP-7322, HDFS-1934, HADOOP-7342, and HDFS-2019. (Bharath Mundlapudi
via mattf)
HADOOP-7248. Update eclipse target to generate .classpath from ivy config.
(Thomas Graves and Tom White via cdouglas) (from HADOOP-6407)
HADOOP-7274. Fix typos in IOUtils. (Jonathan Eagles via cdouglas) (from
HADOOP-7057)
HADOOP-7277. Add generation of run configurations to eclipse target.
(Jeffrey Naisbitt and Philip Zeyliger via cdouglas) (from HADOOP-5911)
HADOOP-7364. TestMiniMRDFSCaching fails if test.build.dir is set to
something other than build/test. (Thomas Graves via mahadev) (from
MAPREDUCE-2575)

Already in trunk for MRV2:
MAPREDUCE-2558. Add queue-level metrics 0.20-security branch (test fixes)
(Jeffrey Naisbitt via mahadev)
MAPREDUCE-2418. Show job errors in JobHistory page. (Siddharth Seth via
acmurthy) (Already in MR279)
MAPREDUCE-2411. Force an exception when the queue has an invalid name or its
ACLs are misconfigured. (Dick King via cdouglas) (Already in MR279)

Waiting for MR279 merge:
MAPREDUCE-2429. Validate JVM in TaskUmbilicalProtocol. (Siddharth Seth via
acmurthy)
MAPREDUCE-2447. Fix Child.java to set Task.jvmContext sooner to avoid corner
cases in error handling. (Siddharth Seth via acmurthy)

MapReduce v1 exceptions:
MAPREDUCE-2415. Distribute the user task logs on to multiple disks.
(Bharath Mundlapudi via omalley)
MAPREDUCE-2413. TaskTracker should handle disk failures by reinitializing
itself. (Ravi Gummadi and Jagane Sundar via omalley)
MAPREDUCE-2621. TestCapacityScheduler fails with "Queue "q1" does not
exist". (Sherry Chen via mahadev)
MAPREDUCE-2535. Fix NPE in JobClient caused by retirement. (Robert Joseph
Evans via cdouglas)
MAPREDUCE-2555. Avoid sprious logging from completedtasks. (Thomas Graves
via cdouglas)
MAPREDUCE-2443. Fix TaskAspect for TaskUmbilicalProtocol.ping(..).
(Siddharth Seth via szetszwo)

Looks good to me Matt. Thanks for doing the analysis. I think the
regression wrt trunk are from the original cut of the branch and don't
need to block the 204 release, ie the trunk first discussion is IMO an
orthogonal thread.

Thanks,
Eli

Can we add
* HADOOP-6942 Ability for having user's classes take precedence over the
system classes for tasks' classpath

It's pretty bad in a sense that it's not on trunk but 0.20.204 and CDH3 both
have this *using different parameters*.

Koji

Thanks Koji.

HADOOP-6942 is in the 'MRv1 exceptions' category since MRv2 doesn't have this issue at all.
This was originally part of the 0.20.203 release, but what/how Cloudera chooses to put in CDH3 is beyond the scope of this discussion... :)

Arun

Since I was among the people who started the 'security on 0.20' thread, I apologize for the lack of clarity on the roadmap and timelines.

Eric did send out a note on the motivation for sustaining releases (http://s.apache.org/hadoop-sustenance-releases) - which I believe is important to keep Hadoop installations going. However, I accept that there has been very poor clarity on the process for inclusion of content to the sustaining releases and the timelines.

Here is my proposal for the community process for sustaining releases moving forward:
# The Release Manager should clearly communicate, upfront, the expected timeline for each upcoming release.
# Anyone interested in contributing to the release submits a patch to trunk, if applicable*, and to the branch-0.20-security branch. Then talk to the Release Manager for inclusion via the normal process.

The RM is responsible for release content, timelines and for enforcing that each change should have an equivalent for trunk, as applicable, before inclusion.

If this makes sense, I'll add this to the wiki to record it.

----

So, how are we doing with 0.20.204 content and trunk given the above proposal? Very well, in fact. Matt, Suresh and I have done a detailed analysis (separate email), please take a look.

thanks,
Arun

*Please note the exception that we have agreed that MRv2 is the way forward (http://s.apache.org/mr1) , and thus, MR1 patches might not be ported as-is to trunk in some cases such as fixes to JobTracker/TaskTracker. However, this doesn't mean changes to the runtime (i.e. map task, reduce task, sort, shuffle etc.) are exempt from the rules proposed above.

+1 sounds great.

Thanks,
Eli

Per Arun's message below, I edited the "Sustaining Release" section of
http://wiki.apache.org/hadoop/Roadmap
to incorporate these items. Feedback welcome.
--Matt

Hi all,

I've just run unit test of 0.20.204 using SUN jdk1.6.0_21, on a 64bit RHEL
machine, and find the following cases failed:

[junit] Test org.apache.hadoop.mapred.TestJobTrackerRestart FAILED (timeout)
[junit] Test org.apache.hadoop.mapred.TestJobTrackerRestartWithLostTracker
FAILED
[junit] Test org.apache.hadoop.mapred.TestJobTrackerSafeMode FAILED
[junit] Test org.apache.hadoop.filecache.TestMRWithDistributedCache FAILED
[junit] Test org.apache.hadoop.filecache.TestTrackerDistributedCacheManager
FAILED
[junit] Test org.apache.hadoop.mapred.TestMiniMRMapRedDebugScript FAILED
[junit] Test org.apache.hadoop.mapred.TestRecoveryManager FAILED
[junit] Test org.apache.hadoop.mapred.TestTaskTrackerLocalization FAILED
[junit] Test org.apache.hadoop.mapred.TestJobTrackerRestartWithCS FAILED
(timeout)
[junit] Test org.apache.hadoop.mapred.TestRackAwareTaskPlacement FAILED

I run each failed test case for 4 times, the above 9 cases failed for each
round, while the last case succeeded twice and failed twice.

I also tested 0.20.203 rc1 with the same testing environment some time
earlier, and got almost the same result(with the failed cases attached
below)

[junit] Test org.apache.hadoop.mapred.TestJobTrackerRestart FAILED
[junit] Test org.apache.hadoop.mapred.TestJobTrackerRestartWithLostTracker
FAILED
[junit] Test org.apache.hadoop.mapred.TestJobTrackerSafeMode FAILED
[junit] Test org.apache.hadoop.filecache.TestMRWithDistributedCache FAILED
[junit] Test org.apache.hadoop.filecache.TestTrackerDistributedCacheManager
FAILED
[junit] Test org.apache.hadoop.mapred.TestMiniMRMapRedDebugScript FAILED
[junit] Test org.apache.hadoop.mapred.TestRecoveryManager FAILED
[junit] Test org.apache.hadoop.mapred.TestTaskTrackerLocalization FAILED
[junit] Test org.apache.hadoop.hdfsproxy.TestHdfsProxy FAILED

Could somebody have a look on these failed test cases? Or tell me if I set
anything wrong in my environment? Many thanks.

PS: I referred to http://wiki.apache.org/hadoop/HadoopJavaVersions about
setting the testing environment.

I hit this one too. If you look at that test case, you'll see it has an @Ignore on it. For some unknown reason, when you use ant 1.8.2 junit does the wrong thing. Use ant 1.7.1 and the test cases will be properly ignored.

-- Owen

Thanks Owen, for the quick and helpful response!

By removing those test cases marked as "@Ignored", there're still 3 failed
test cases for 0.20.203:

[junit] Test org.apache.hadoop.filecache.TestMRWithDistributedCache FAILED
[junit] Test org.apache.hadoop.filecache.TestTrackerDistributedCacheManager
FAILED
[junit] Test org.apache.hadoop.hdfsproxy.TestHdfsProxy FAILED

and 3 failed, 1 unstable cases for 0.20.204:

[junit] Test org.apache.hadoop.filecache.TestMRWithDistributedCache FAILED
[junit] Test org.apache.hadoop.filecache.TestTrackerDistributedCacheManager
FAILED
[junit] Test org.apache.hadoop.mapred.TestJobTrackerRestartWithCS FAILED
(timeout)
[junit] Test org.apache.hadoop.mapred.TestRackAwareTaskPlacement --> FAILED
twice, SUCCEED twice

Has anybody met with these case failures? Thanks.

I saw @jeric14's tweet about 0.20.204 vote last night, and was about to reply, because I could not see any vote on the general@ mailing list.

Yes, toy are right @atm, the vote should be on general@.

- milind

---
Milind Bhandarkar

-----Original Message-----
From: Aaron T. Myers
Sent: Thursday, July 28, 2011 5:12 PM
To: [email protected]
Subject: Re: [VOTE] Release 0.20.204.0-rc0

Shouldn't this vote be taking place on general@, instead of common-dev@? I'm
under the impression that that is where all votes are supposed to take
place. Please correct me if I am wrong about that.