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 <[email protected]> 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 <[email protected]> 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" <[email protected]> wrote: >> >> >On Fri, Nov 16, 2012 at 3:38 PM, Aaron T. Myers <[email protected]> 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
