Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 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
On Mon, Feb 25, 2013 at 1:50 PM, Chris Douglas <[EMAIL PROTECTED]> wrote:
> On Mon, Feb 25, 2013 at 1:16 PM, Eli Collins <[EMAIL PROTECTED]> 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
> anything.

I'm not proposing anything new, Nicholas said he had some concerns
with ATM's proposal and we're discussing them.

Specifically, ATM's proposal does not allow for a single release that
contains both 347 and 2246 (he proposes removing 2246 from branch-2
when 347 is ready). I think Nicholas was saying that we should not
remove 2246 immediately for the sake of a transition period (which I
interpret to mean a release that supports both), I responded saying
that the transition that we'd have in ATM's proposal (people adjust on
trunk and there's some branch-2 release that flips over) is sufficient
given that 2246 was intended as a short term thing.  Curious if
Nicholas and others think that's reasonable.

Thanks,
Eli

>
> 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 <[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
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB