hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Purtell <apurt...@apache.org>
Subject Re: [ANNOUNCE] Intend to build a 0.20.205.1 candidate next Friday 11 Nov.
Date Fri, 11 Nov 2011 23:08:04 GMT
> From: Todd Lipcon <todd@cloudera.com>

> Calling this a "critical fix" for HBase is a bit strange as 99.9% of
> the HBase installs out there do not use it. Trend Micro and Facebook
> are the only ones I'm aware of that do.

It would be more accurate to say we are running it in one production installation, but

  - have questions as to the performance benefits we will actually see

  - won't be able to use it in a deployment that requires stronger assurance 

> And the patch as it stands today has a very suspect security model...


Agreed.

In my opinion, this is a useful option to provide, but off by default, and isn't a critical
fix. Nothing is broken. Call it "a performance optimization option".

Best regards,


   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White)


----- Original Message -----
> From: Todd Lipcon <todd@cloudera.com>
> To: common-dev@hadoop.apache.org
> Cc: 
> Sent: Friday, November 11, 2011 5:29 PM
> Subject: Re: [ANNOUNCE] Intend to build a 0.20.205.1 candidate next Friday 11 Nov.
> 
> On Fri, Nov 11, 2011 at 1:29 AM, Matt Foley <mfoley@hortonworks.com> 
> wrote:
> 
>> 
>>  Also, I believe in the HDFS-2246 Jira, Todd requested extra time to review,
>>  due to commitments at Hadoop World.  Todd, would Monday be sufficient extra
>>  time, so as not to slow down the anticipated release schedule too much?
>> 
> 
> Yes, I will probably have time to review it by Monday. But the
> review-time concern is separate from the concern about which version
> this should go into.
> 
> Calling this a "critical fix" for HBase is a bit strange as 99.9% of
> the HBase installs out there do not use it. Trend Micro and Facebook
> are the only ones I'm aware of that do. And the patch as it stands
> today has a very suspect security model...
> 
> -Todd
> 
> 
>> 
>>  On Thu, Nov 10, 2011 at 10:31 PM, Eli Collins <eli@cloudera.com> 
> wrote:
>> 
>>>  Hey guys,
>>> 
>>>  HDFS-2246 is not a fix, it's a non-trivial performance 
> optimization.
>>>  The roadmap page is pretty clear..  "Point releases are made to 
> fix
>>>  critical bugs. They do not introduce new features or make other
>>>  improvements other than fixing bugs".
>>> 
>>>  I'm not opposed to the change, I'm just pointing out that we 
> agreed to
>>>  develop trunk first, and we agreed to follow the release policies for
>>>  the sustaining branch. I don't see why we can't honor those
>>>  agreements, ie why not post a patch for trunk first and then backport
>>>  it to 206? Reasonable?
>>> 
>>>  Thanks,
>>>  Eli
>>> 
>>>  On Thu, Nov 10, 2011 at 9:58 PM, Suresh Srinivas 
> <suresh@hortonworks.com>
>>>  wrote:
>>>  > Eli,
>>>  >
>>>  > As Jitendra indicated in the jira, this was originally supposed to 
> be
>>>  part
>>>  > of 0.205. Due to time crunc, we could not get this done in 0.205. 
> This
>>>  can
>>>  > be turned off by a flag and only can be enabled by users who want 
> to use
>>>  > the functionality. Given that, I feel it is okay to go into 
> 0.205.1.
>>>  >
>>>  > I agree it would be good to have a trunk patch for this and make 
> it part
>>>  of
>>>  > 0.23.
>>>  >
>>>  > Regards,
>>>  > Suresh
>>>  >
>>>  > On Thu, Nov 10, 2011 at 4:32 PM, Eli Collins 
> <eli@cloudera.com> wrote:
>>>  >
>>>  >> Hey Matt,
>>>  >>
>>>  >> Is HDFS-2246 slated for 0.20.205.1?  Given that it's not a 
> bug and is
>>>  >> non-trivial it seems better suited for 206 than a point 
> release. Also,
>>>  >> per the sustaining roadmap - 
> http://wiki.apache.org/hadoop/Roadmap -
>>>  >> "Only functionality already committed to trunk should be 
> submitted to
>>>  >> a sustaining release." and this functionality does not 
> yet have a
>>>  >> patch for trunk yet (let alone committed).
>>>  >>
>>>  >> Thanks,
>>>  >> Eli
>>>  >>
>>>  >> On Fri, Nov 4, 2011 at 5:56 PM, Matt Foley 
> <mattf@apache.org> wrote:
>>>  >> > Hi all,
>>>  >> > I propose to make a 0.20.205.1 candidate soon, with the 
> following
>>>  sets of
>>>  >> > patches:
>>>  >> >
>>>  >> >   - deficiencies in HBase support, pointed out by the 
> HBase team and
>>>  >> others
>>>  >> >   - deficiencies in webhdfs support on secure clusters
>>>  >> >   - a couple last-minute fixes submitted to 
> branch-0.20-security-205
>>>  that
>>>  >> >   were too late to be included in 205.0
>>>  >> >
>>>  >> > If you would like other patches included, and you feel it 
> is
>>>  appropriate
>>>  >> to
>>>  >> > have them in 205.1 rather than waiting for 206.0, please 
> declare them
>>>  by
>>>  >> > setting the "Target Versions" field in their 
> Jiras, and they will
>>>  receive
>>>  >> > due consideration, assuming that the proposed patch is 
> actually
>>>  >> > contributed, tested, reviewed, approved, and committed
>>>  >> > to branch-0.20-security-205 by the freeze date :-)
>>>  >> >
>>>  >> > I would like to make the rc0 candidate next Friday, so I 
> propose to
>>>  >> declare
>>>  >> > 205.1 code freeze at noon, PST, Friday 11 Nov.  If this 
> is a problem
>>>  for
>>>  >> > anyone, please let me know.
>>>  >> >
>>>  >> > Thank you, and best regards,
>>>  >> > --Matt (Release Manager)
>>>  >> >
>>>  >>
>>>  >
>>> 
>> 
> 
> 
> 
> -- 
> Todd Lipcon
> Software Engineer, Cloudera
>

Mime
View raw message