Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
HDFS >> mail # dev >> Re-swizzle 2.3


Copy link to this message
-
Re: Re-swizzle 2.3
Do you guys think that committing
    https://issues.apache.org/jira/browse/HDFS-4858
to branch-2.3 is still Ok? It is a small change that bring fixes broken
timeout behavior of DN to NN RPC.

We have been testing this fix on top of 2.0.6 for a long time now and it seems
to be a real help.

Appreciate the feedback on 2.3 scope. If it is too late then I will commit it
to trunk, branch-2.4 and branch-2 only.

Regards,
  Cos

On Thu, Feb 06, 2014 at 05:44PM, Alejandro Abdelnur wrote:
> yep, the idea is to pull all of them out from branch2.3. things go back to normal then.
>
> thanks
>
> Alejandro
> (phone typing)
>
> > On Feb 6, 2014, at 17:39, Zhijie Shen <[EMAIL PROTECTED]> wrote:
> >
> > Recently I brought 4 JIRAs to branch-2.3, which are MAPREDUCE-5743, YARN-1628,
> > YARN-1661 and YARN-1689. Recall that we mark test failure fixes as blockers
> > for pior releases as closing to release, thus I brought to branch-2.3
> > MAPREDUCE-5743
> > and YARN-1628 that are the fixes for the test failure on 2.3.0, but didn't
> > marked them as blockers. Please let me know if I should do that.
> >
> > YARN-1661 is a fix for exit log of DS AppMaster, otherwise the exit log of
> > it will always be failure, which sounds a critical issue to me. Feel free
> > to pull it out if any objects.
> >
> > YARN-1689 is brought to branch-2.3 as YARN-1493 is still in this branch. It
> > fixes one bug caused by YARN-1493. Those should be included or excluded
> > together upon the decision.
> >
> > Thanks,
> > Zhijie
> >
> >
> >> On Thu, Feb 6, 2014 at 5:15 PM, Sandy Ryza <[EMAIL PROTECTED]> wrote:
> >>
> >> +1 to reverting those JIRAs from branch-2.3.  As YARN-1689 is fixing a
> >> problem caused by YARN-1493 I think we can revert it in branch-2.3 as well.
> >>
> >> I think we should leave them in branch-2 for now.  We can revert if 2.4 is
> >> imminent and they're holding it up, but hopefully the issues they caused
> >> will be fixed by then.
> >>
> >> -Sandy
> >>
> >>
> >> On Thu, Feb 6, 2014 at 5:07 PM, Alejandro Abdelnur <[EMAIL PROTECTED]
> >>> wrote:
> >>
> >>> Thanks Robert,
> >>>
> >>> All,
> >>>
> >>> So it seems that YARN-1493 and YARN-1490 are introducing serious
> >>> regressions.
> >>>
> >>> I would propose to revert them and the follow up JIRAs from the 2.3
> >> branch
> >>> and keep working on them on trunk/branch-2 until the are stable (I would
> >>> even prefer reverting them from branch-2 not to block a 2.4 if they are
> >> not
> >>> ready in time).
> >>>
> >>> As I've mentioned before, the list of JIRAs to revert were:
> >>>
> >>> YARN-1493
> >>> YARN-1490
> >>> YARN-1166
> >>> YARN-1041
> >>> YARN-1566
> >>>
> >>> Plus 2 additional JIRAs committed since my email on this issue 2 days
> >> ago:
> >>>
> >>> *YARN-1661
> >>> *YARN-1689 (not sure if this JIRA is related in functionality to the
> >>> previous ones but it is creating conflicts).
> >>>
> >>> I think we should hold on continuing work on top of something that is
> >>> broken until the broken stuff is fixed.
> >>>
> >>> Quoting Arun, "Committers - Henceforth, please use extreme caution while
> >>> committing to branch-2.3. Please commit *only* blockers to 2.3."
> >>>
> >>> YARN-1661 & YARN-1689 are not blockers.
> >>>
> >>> Unless there are objections, I'll revert all these JIRAs from branch-2.3
> >>> tomorrow around noon and I'll update fixedVersion in the JIRAs.
> >>>
> >>> I'm inclined to revert them from branch-2 as well.
> >>>
> >>> Thoughts?
> >>>
> >>> Thanks.
> >>>
> >>>
> >>> On Thu, Feb 6, 2014 at 3:54 PM, Robert Kanter <[EMAIL PROTECTED]>
> >>> wrote:
> >>>
> >>>> I think we should revert YARN-1490 from Hadoop 2.3 branch.  I think it
> >>> was
> >>>> causing some strange behavior in the Oozie unit tests:
> >>>>
> >>>> Basically, we use a single MiniMRCluster and MiniDFSCluster across all
> >>> unit
> >>>> tests in a module.  With YARN-1490 we saw that, regardless of test
> >> order,
> >>>> the last few tests would timeout waiting for an MR job to finish; on