hadoop-hdfs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Douglas <cdoug...@apache.org>
Subject Re: VOTE: HDFS-347 merge
Date Mon, 25 Feb 2013 21:50:21 GMT
On Mon, Feb 25, 2013 at 1:16 PM, Eli Collins <eli@cloudera.com> wrote:
> I think we need a transition period when any kinks are worked out of
> 347 but I don't think we need one alpha/beta release where both
> mechanisms are supported (because 2246 was just a short term solution
> rather than a long term commitment).  Ideally we'd get 347 in branch-2
> for 2.0.4-beta and have that release to address issues that come up to
> fix for GA.  Cloudera is actively testing 347 and parts of the
> community are eager to pick it up so I think that would work out
> timing wise.  Reasonable?

ATM's suggestion of removing HDFS-2246 in trunk, but not branch-2, is
a rational compromise: it allows some period for others to adapt, but
not an indefinite one. It's not clear what you're proposing, if

Nicholas/Suresh: have you had a chance to review HDFS-347, yet? -C

> On Mon, Feb 25, 2013 at 12:50 PM, Tsz Wo Sze <szetszwo@yahoo.com> wrote:
>> I agree that HDFS-2246 is a short term solution and we should not keep it there forever.
 However, we still need a transition period to replace an old mechanism by a new one.  No?
>> Tsz-Wo
>> ________________________________
>>  From: Eli Collins <eli@cloudera.com>
>> To: "hdfs-dev@hadoop.apache.org" <hdfs-dev@hadoop.apache.org>; Tsz Wo Sze <szetszwo@yahoo.com>
>> Sent: Monday, February 25, 2013 10:24 AM
>> Subject: Re: VOTE: HDFS-347 merge
>> On Sat, Feb 23, 2013 at 4:23 PM, Tsz Wo Sze <szetszwo@yahoo.com> wrote:
>>> I still do not see a valid reason to remove HDFS-2246 immediately.  Some users
may have insecure clusters and they don't want to change their configuration.
>> Because it doesn't make sense to support multiple mechanisms for the
>> same thing.
>> 2246 was always intended to be a *short term solution* util 347 was
>> completed, eg see Sanjay's first comment on 2246:   "A shortcut has
>> been proposed where the client access the hdfs file blocks directly...
>> This is non-invasive and is a good short term solution till HDFS-347
>> is completed."
>> Thanks,
>> Eli

View raw message