hadoop-hdfs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eli Collins <...@cloudera.com>
Subject Re: VOTE: HDFS-347 merge
Date Mon, 25 Feb 2013 21:16:05 GMT
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?

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