hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karthik Kambatla <ka...@cloudera.com>
Subject Re: [VOTE] Release Apache Hadoop 2.1.0-beta
Date Tue, 13 Aug 2013 17:37:27 GMT
Hi Arun,

Would it be possible to include YARN-1056 in the next RC - it is a
straight-forward config change. I marked it as a blocker for 2.1.0.

Thanks
Karthik


On Thu, Aug 8, 2013 at 8:14 AM, Kihwal Lee <kihwal@yahoo-inc.com> wrote:

> Another blocker, HADOOP-9850, has been committed.
>
>
> Kihwal
>
>
> ________________________________
>  From: Arun C Murthy <acm@hortonworks.com>
> To: Daryn Sharp <daryn@yahoo-inc.com>
> Cc: "<hdfs-dev@hadoop.apache.org>" <hdfs-dev@hadoop.apache.org>; "
> mapreduce-dev@hadoop.apache.org" <mapreduce-dev@hadoop.apache.org>; "
> yarn-dev@hadoop.apache.org" <yarn-dev@hadoop.apache.org>; "
> common-dev@hadoop.apache.org" <common-dev@hadoop.apache.org>
> Sent: Thursday, August 1, 2013 1:30 PM
> Subject: Re: [VOTE] Release Apache Hadoop 2.1.0-beta
>
>
> Ok, thanks for heads up Daryn. I'll spin an RC2 once HADOOP-9816 gets in -
> I'd appreciate if you could help push the fix in ASAP.
>
> Thanks again!
>
> Arun
>
> On Aug 1, 2013, at 9:38 AM, Daryn Sharp <daryn@yahoo-inc.com> wrote:
>
> > I broke RPC QOP for integrity and privacy options. :(  See blocker
> HADOOP-9816.  I think I understand the problem and it shouldn't be hard to
> fix.
> >
> > The bug went unnoticed because sadly there are no unit tests for the QOP
> options, even though it just involves a conf setting.
> >
> > Daryn
> >
> >
> > On Jul 29, 2013, at 5:00 PM, Arun C Murthy wrote:
> >
> >> Ok, I think we are close to rc1 now - the last of blockers should be
> committed later today… I'll try and spin RC1 tonight.
> >>
> >> thanks,
> >> Arun
> >>
> >> On Jul 21, 2013, at 12:43 AM, Devaraj Das <ddas@hortonworks.com> wrote:
> >>
> >>> I have just raised https://issues.apache.org/jira/browse/HDFS-5016 ..
> This
> >>> bug can easily be reproduced by some HBase tests. I'd like this to be
> >>> considered before we make a beta release. Have spoken about this with
> some
> >>> hdfs folks offline and I am told that it is being worked on.
> >>>
> >>> Thanks
> >>> Devaraj
> >>>
> >>>
> >>> On Wed, Jul 17, 2013 at 4:25 PM, Alejandro Abdelnur <tucu00@gmail.com
> >wrote:
> >>>
> >>>> As I've mentioned in my previous email, if we get YARN-701 in, we
> should
> >>>> also get in the fix for unmanaged AMs in an un-secure setup in
> 2.1.0-beta.
> >>>> Else is a regression of a functionality it is already working.
> >>>>
> >>>> Because of that, to avoid continuing delaying the release, I'm
> suggesting
> >>>> to mention in the release notes the API changes and behavior changes
> that
> >>>> YARN-918 and YARN-701 will bring into the next beta or GA release.
> >>>>
> >>>> thx
> >>>>
> >>>>
> >>>> On Wed, Jul 17, 2013 at 4:14 PM, Vinod Kumar Vavilapalli <
> >>>> vinodkv@hortonworks.com> wrote:
> >>>>
> >>>>>
> >>>>> On Jul 17, 2013, at 1:04 PM, Alejandro Abdelnur wrote:
> >>>>>
> >>>>>> * YARN-701
> >>>>>>
> >>>>>> It should be addressed before a GA release.
> >>>>>>
> >>>>>> Still, as it is this breaks unmanaged AMs and to me
> >>>>>> that would be a blocker for the beta.
> >>>>>>
> >>>>>> YARN-701 and the unmanaged AMs fix should be committed
> >>>>>> in tandem.
> >>>>>>
> >>>>>> * YARN-918
> >>>>>>
> >>>>>> It is a consequence of YARN-701 and depends on it.
> >>>>>
> >>>>>
> >>>>>
> >>>>> YARN-918 is an API change. And YARN-701 is a behaviour change. We
> need
> >>>>> both in 2.1.0.
> >>>>>
> >>>>>
> >>>>>
> >>>>>> * YARN-926
> >>>>>>
> >>>>>> It would be nice to have it addressed before GA release.
> >>>>>
> >>>>>
> >>>>> Either ways. I'd get it in sooner than later specifically when we
are
> >>>>> trying to replace the old API with the new one.
> >>>>>
> >>>>> Thanks,
> >>>>> +Vino
> >>>>>
> >>>>>
> >>>>
> >>
> >> --
> >> Arun C. Murthy
> >> Hortonworks Inc.
> >> http://hortonworks.com/
> >>
> >>
> >
>
> --
> Arun C. Murthy
> Hortonworks Inc.
> http://hortonworks.com/
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message