On Thu, Dec 23, 2010 at 3:33 PM, Ian Holsman <[email protected]> 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 <[email protected]> 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 > > <[email protected]> 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 <[email protected]> > 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 <[email protected]> > 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 <[email protected]> > >>> 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 <[email protected]> > >>> wrote: > >>>>> > >>>>>> On Wed, Dec 22, 2010 at 11:07 PM, Roy T. Fielding < > [email protected]> > >>>>>> 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
