hadoop-hdfs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tsz Wo Sze <szets...@yahoo.com>
Subject Re: Merging the HA branch to trunk - Wednesday, February 29th
Date Thu, 01 Mar 2012 00:32:03 GMT
Hi,

The HA build has been unstable since Feb 13.  In particular, HttpFS failed in the latest
build (#92).  On the other hand, the latest trunk HDFS build (#970) is stable.  Could we
stabilize the HA build before merging?


Nicholas
-------------------------------

Latest HA Build (#92):
https://builds.apache.org/view/G-L/view/Hadoop/job/Hadoop-Hdfs-HAbranch-build/92/console

[INFO] 
[INFO] Apache Hadoop HDFS ................................ SUCCESS [8:34.652s]
[INFO] Apache Hadoop HttpFS .............................. FAILURE [8.346s]
[INFO] Apache Hadoop HDFS BookKeeper Journal ............. SKIPPED
[INFO] Apache Hadoop HDFS Project ........................ SKIPPED
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ---------------------------------


________________________________
 From: Aaron T. Myers <atm@cloudera.com>
To: hdfs-dev@hadoop.apache.org 
Sent: Wednesday, February 29, 2012 4:00 PM
Subject: Re: Merging the HA branch to trunk - Wednesday, February 29th
 
Hello HDFS devs,

The four JIRAs I mentioned below have all now been committed to the HA
branch. We've been running through the test plans posted on HDFS-1623 for
the last week.

The only thing that's been discovered in the interim on the branch that
should perhaps be considered a blocker for the merge is the performance
issues Todd identified. I am of the opinion that we should proceed with the
merge to trunk anyway, despite the presence of these performance
regressions. Todd's done some good work on addressing those, which should
be committed in the next few days, so their presence on trunk should be
brief.

If folks are amenable to the above, I'd like to do the merge to trunk
tomorrow, since it's getting a little late in the day today.

Since this code change is a merge from a branch, we need three +1s to do
it. Clearly I'm +1.

Thanks a lot,
Aaron

--
Aaron T. Myers
Software Engineer, Cloudera



On Wed, Feb 22, 2012 at 6:24 PM, Aaron T. Myers <atm@cloudera.com> wrote:

> Hello HDFS devs,
>
> Work has largely stabilized on the HA-branch in the last few weeks. At
> this point the HA NN project is nearly feature-complete for manual
> failover. We've been running the full test suite nightly, and all automated
> tests have been passing, except for one known test failure which should be
> fixed shortly.
>
> I'd like to begin the process of merging this branch back to HDFS trunk.
> There are still several outstanding sub-JIRAs under the HDFS-1623 and
> HADOOP-7454 umbrella JIRAs, but most of these are either nice-to-haves or
> relate to supporting automatic failover. Once the branch is merged to
> trunk, work on these JIRAs can continue there.
>
> I've identified the following JIRAs which I think should be the only
> remaining blockers for merging to trunk:
>
> HDFS-2904 - Client support for getting delegation tokens in an HA cluster
> HDFS-2920 - Fix remaining TODOs in the code from HA. Mostly little cleanup
> stuff.
> HDFS-2958 - Sweep for remaining proxy construction which doesn't go
> through failover path
> HDFS-2979 - Balancer should use logical URI for creating failover proxy
> (will fix the only current test failure)
>
> All of these JIRAs should be fixed in the next few days.
>
> I propose that, unless more blocker issues are discovered in the interim,
> we merge this branch to trunk one week from today, i.e. Wednesday, February
> 29th. During this time we will also execute the test plans described in the
> test documents attached to HDFS-1623 to try to identify any regressions or
> performance issues in the branch. If you plan to review the code changes or
> the test plan, I ask that you please do so as soon as possible.
>
> Feedback is certainly welcome on this plan.
>
> Thanks a lot,
> Aaron
>
> --
> Aaron T. Myers
> Software Engineer, Cloudera
>
>
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message