hadoop-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Todd Lipcon <t...@cloudera.com>
Subject Re: DISCUSSION: Cut a hadoop-0.20.0-append release from the tip of branch-0.20-append branch?
Date Thu, 23 Dec 2010 23:52:36 GMT
On Thu, Dec 23, 2010 at 3:33 PM, Ian Holsman <hadoop@holsman.net> wrote:

> The release is one issue, but ongoing maintenance of it is another, which
> is the point roy raised.
>
> It's a concern if we have a security issue, and who will patch it (and test
> it) going forward.
>

The nice thing is that Hadoop 0.20.x (without security patches) has no
guarantees as to security. So, I can't imagine any security issue that could
possibly exist that would be worth addressing. It doesn't run as root so
root escalation is only possible with a JVM bug, and it's trivially possible
to read anyone's data since 0.20 has no strong authentication.

Thanks
-Todd



>
> ---
> Ian Holsman - 703 879-3128
>
> I saw the angel in the marble and carved until I set him free --
> Michelangelo
>
> On 24/12/2010, at 9:39 AM, Ryan Rawson <ryanobjc@gmail.com> wrote:
>
> > How does stack volunteering his time to release an existing branch
> > divert resources?
> >
> > Without an ASF release of 0.20-append I will keep having to recommend
> > an external vendor's release of Hadoop.
> >
> >
> > On Thu, Dec 23, 2010 at 2:18 PM, Konstantin Shvachko
> > <shv.hadoop@gmail.com> wrote:
> >> I also think building 0.20-append will be a major distraction from
> moving
> >> 0.22 forward with all the great new features, including the new append
> >> implementation, sitting on the bench because we are delaying the
> release.
> >> It seems to be beneficial for the entire community to focus on 0.22
> rather
> >> than chasing both birds.
> >>
> >> I hear a concern that 0.22 will lack large scale testing as was the case
> >> with 0.21.
> >> I'd like to volunteer to put as many large scale resources, as I can
> grasp,
> >> into stabilizing of 0.22. Under Nigel's management of course.
> >> This should get us to production quality in 3-6 months rather than
> >> "another 12-15". I also hope it can go even faster/better if others
> >> could join the effort. I see > 100 companies claiming they are powered
> by
> >> Apache Hadoop.
> >>
> >> I also hope with this effort HBase will be able to start moving to the
> new
> >> append implementation in the next 2-3 months, which in turn will help
> 0.22
> >> HDFS
> >> rather than divert resources from it as it would have be with
> 0.20-append.
> >>
> >> Stack, will this plan will work for HBase survival?
> >>
> >> One other thought. Apache Hadoop community is not in control of external
> >> releases and distributions, but we should not fork our own releases by
> >> introducing
> >> competing apis. If we can keep the dev line relatively straight the
> external
> >> releases
> >> will follow.
> >>
> >> Thanks,
> >> --Konstantin
> >>
> >>
> >> On Thu, Dec 23, 2010 at 11:40 AM, Ryan Rawson <ryanobjc@gmail.com>
> wrote:
> >>
> >>> The append solution in 0.22 that you are referring to was supposed to
> >>> be out 13-15 months ago.  Pardon if I look for solutions that deploy 4
> >>> months ago (as the 0.20 append branch did).
> >>>
> >>> Another 12-15 months of delay is not exactly helping HDFS either.
> >>>
> >>> -ryan
> >>>
> >>> On Thu, Dec 23, 2010 at 9:38 AM, Jakob Homan <jghoman@gmail.com>
> wrote:
> >>>> It's difficult to support this proposal knowing how much time would
be
> >>>> spent preparing an official release, continuing to support it and
> >>>> continuing to two support two separate implementations of append.  I
> >>>> believe that effort would be better spent getting out a kick-ass 22
> >>>> (or, barring that, a *really* kick-ass 23).
> >>>>
> >>>> The Promised Land that we say we're all trying to get to is regular,
> >>>> timely, feature-complete, tested, innovative but stable releases of
> >>>> new versions of Apache Hadoop.  Missing out any one of those criteria
> >>>> discovered will continue (and has continued) the current situation
> >>>> where quasi-official branches and outside distributions fill the void
> >>>> such a release should.  The effort to maintain this offical branch and
> >>>> fix the bugs that will be discovered could be better spent moving us
> >>>> closer to that goal.
> >>>>
> >>>> I'm certainly sympathetic to the difficult position our quagmire has
> >>>> placed HBase into.  However, the current proposal would hurt HDFS to
> >>>> help HBase. The best solution for that project, as well as for HDFS,
> >>>> is to get HDFS back to a healthy release cycle; not prolong or codify
> >>>> the current ad-hoc state of affairs.  Let's stop digging this hole.
> >>>> -jakob
> >>>>
> >>>> On Thu, Dec 23, 2010 at 9:33 AM, M. C. Srivas <mcsrivas@gmail.com>
> >>> wrote:
> >>>>> [ Sorry if this is be-laboring the obvious ]
> >>>>>
> >>>>> There are two append solutions floating around, and they are
> >>> incompatible
> >>>>> with each other. Thus, the two "branches" will forever remain
> >>> incompatible
> >>>>> with each other, regardless of how they are numbered (0.22,  0.23,
> >>>  0.20.3,
> >>>>> e.t.c.)
> >>>>>
> >>>>> Unless both are merged into one branch, and a switch provided to
>  "use
> >>>>> HDFS-200 append" or "use 0.22 append", we have effectively split
> Hadoop
> >>> into
> >>>>> two.
> >>>>>
> >>>>>
> >>>>> On Thu, Dec 23, 2010 at 12:00 AM, Owen O'Malley <omalley@apache.org>
> >>> wrote:
> >>>>>
> >>>>>> On Wed, Dec 22, 2010 at 11:07 PM, Roy T. Fielding <
> fielding@gbiv.com>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> Features are not release version tags.  If there is a security
bug
> >>>>>>> found then we would have to release a new version of the
append
> >>>>>>> version, and a round of severe trout slapping would result.
> >>>>>>>
> >>>>>>
> >>>>>> Yeah, it isn't a perfect solution and it doesn't scale to a
second
> tag,
> >>> but
> >>>>>> the problem is that this is effectively a release branch between
> 0.20
> >>> and
> >>>>>> 0.21. Of course I agree that any critical bugs would need to
be
> fixed
> >>> in
> >>>>>> the
> >>>>>> append branch as well as the 0.20 and 0.21 branches.
> >>>>>>
> >>>>>> If you want to stick to pure numbers and we want to leave ourselves
> a
> >>> way
> >>>>>> to
> >>>>>> bugfix the 0.20 branch without append, we'd could use a version
> string
> >>> like
> >>>>>> 0.20.100, etc. Not pretty, but it does preserve the numeric
ordering
> >>> and
> >>>>>> suggest a version jump.
> >>>>>>
> >>>>>> If I remember right, there were also protocol changes in the
append
> >>> branch,
> >>>>>> which was another reason we didn't want to put it directly into
the
> >>> 0.20
> >>>>>> branch.
> >>>>>>
> >>>>>> -- Owen
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
>



-- 
Todd Lipcon
Software Engineer, Cloudera

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