hadoop-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron T. Myers" <...@cloudera.com>
Subject Re: Heads Up - hadoop-2.0.3 release
Date Wed, 19 Dec 2012 05:07:11 GMT
Great, that makes sense to me as well.

Thanks a lot, and have a happy holidays.

Aaron


On Tue, Dec 18, 2012 at 9:00 PM, Arun C Murthy <acm@hortonworks.com> wrote:

> As Sid responded I think we can move off alpha once we fix
> YARN-142/MAPREDUCE-4067. There are other apis we should clean up, but none
> as egregious as those two.
>
> Someone on my team is starting on it as we speak and I believe we can get
> it done sometime in Jan... thus targetting 2.0.4 (as a beta?). By then
> we'll also have wider rollouts of YARN and would have fixed some more
> issues we've seen at very high scale deployments at Y!. Sounds like the
> right time to do a beta release to me.
>
> Arun
>
> On Dec 19, 2012, at 10:13 AM, Aaron T. Myers wrote:
>
> > Hey Arun,
> >
> > Awesome to see we're almost down to zero blockers. What are your thoughts
> > on removing the "alpha" label from the upcoming release? It seems to me
> > from the earlier discussion that most folks feel that we're at the point
> > where the interfaces are sufficiently stable to warrant it.
> >
> > Aaron
> >
> >
> > On Tue, Dec 18, 2012 at 8:15 PM, Arun C Murthy <acm@hortonworks.com>
> wrote:
> >
> >> Nearly there:
> >> http://s.apache.org/hadoop-2-blockers
> >>
> >> YARN-217 should be easy, I'd also like to get in YARN-253.
> >>
> >> Arun
> >>
> >> On Dec 19, 2012, at 1:15 AM, Todd Lipcon wrote:
> >>
> >>> Any news on how this is progressing? Some folks in this thread below
> >>> inquired about getting this release out around the New Year timeframe,
> >>> but it looks like YARN-117 subtasks have gone pretty quiet. We all
> >>> know how long lifecycle changes can take to get pushed through ;-)
> >>>
> >>> -Todd
> >>>
> >>> On Mon, Nov 19, 2012 at 12:41 PM, Steve Loughran
> >>> <steve.loughran@gmail.com> wrote:
> >>>> I want to make some changes to the lifecycle of a yarn service (in a
> >>>> backwards compatible way).
> >>>>
> >>>> https://issues.apache.org/jira/browse/YARN-117
> >>>>
> >>>>
> >>>>  1. formal state machine model with stop state idempotent and
> >> entry-able
> >>>>  from any state
> >>>>  2. waiting/blocked state a service can enter when waiting for
> >> something
> >>>>  else
> >>>>  3. an alternate base class that does the state model checks before
> >>>>  executing any state change functions -currently its done at
> >>>>  end-of-operation in the super() calls.
> >>>>  4. gradual move of services to the stricter base class.
> >>>>
> >>>> With a new base class nothing will break (as the move can be done
> >>>> case-by-case, leaving the heavily subclassed ones alone); the state
> >> model
> >>>> extensions & formalisation would be visible but not used.
> >>>>
> >>>> I don't want to hold anything up, because I need more testing of
> things
> >>>> before this is ready for review. I just want to get the fixes in
> before
> >> it
> >>>> ships
> >>>>
> >>>> On 19 November 2012 16:22, Robert Evans <evans@yahoo-inc.com>
wrote:
> >>>>
> >>>>> I am OK with removing the alpha assuming that we think that the
APIs
> >> are
> >>>>> stable enough that we are willing to truly start maintaining
> backwards
> >>>>> compatibility on them within 2.X. From what I have seen I think
that
> >> they
> >>>>> are fairly stable and I think there is enough adoption by other
> >> projects
> >>>>> right now that breaking backwards compatibility would be problematic.
> >>>>>
> >>>>> --Bobby Evans
> >>>>>
> >>>>> On 11/16/12 11:34 PM, "Stack" <stack@duboce.net> wrote:
> >>>>>
> >>>>>> On Fri, Nov 16, 2012 at 3:38 PM, Aaron T. Myers <atm@cloudera.com>
> >> wrote:
> >>>>>>> Hi Arun,
> >>>>>>>
> >>>>>>> Given that the 2.0.3 release is intended to reflect the
growing
> >>>>>>> stability
> >>>>>>> of YARN, and the QJM work will be included in 2.0.3 which
provides
> a
> >>>>>>> complete HDFS HA solution, I think it's time we consider
removing
> the
> >>>>>>> "-alpha" label from the release version. My preference would
be to
> >>>>>>> remove
> >>>>>>> the label entirely, but we could also perhaps call it "-beta"
or
> >>>>>>> something.
> >>>>>>>
> >>>>>>> Thoughts?
> >>>>>>>
> >>>>>>
> >>>>>> I think it fine after two minor releases undoing the '-alpha'
> suffix.
> >>>>>>
> >>>>>> If folks insist we next go to '-beta', I'd hope we'd travel
all
> >>>>>> remaining 22 letters of the greek alphabet before we 2.0.x.
> >>>>>>
> >>>>>> St.Ack
> >>>>>
> >>>>>
> >>>
> >>>
> >>>
> >>> --
> >>> Todd Lipcon
> >>> Software Engineer, Cloudera
> >>
> >> --
> >> 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