Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
HDFS >> mail # dev >> VOTE: HDFS-347 merge


Copy link to this message
-
Re: VOTE: HDFS-347 merge
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
> To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>; Tsz Wo Sze <[EMAIL PROTECTED]>
> 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 <[EMAIL PROTECTED]> 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