Vote on getting org.apache.hadoop.hbase.mapred back in 0.21

[Jean-Daniel Cryans <jd...@apache.org>]

Hi devs,

The removing of the old HBase mapred API while Hadoop 0.21 is still
keeping it causes the situation where we are forcing users to migrate
while they may not have to. Also, other projects like cascading
continue to rely on the old Hadoop mapred API so their HBase module
will break. This is very problematic.

What I propose is that we get the org.apache.hadoop.hbase.mapred
package back in 0.21. To do that, we need to refactor all the
dependencies on the old client API to use the new one. The impact on
users upgrading from 0.20 to 0.21 with MR jobs using the old package
will be the same, they will have to change all the client calls in
their code.

This is ok with everyone?

If the vote passes, I will do the work.

J-D

Re: Vote on getting org.apache.hadoop.hbase.mapred back in 0.21

[stack <st...@duboce.net>]

I'm fine w/ us requiring mapreduce as opposed to mapred going into 0.21
except for the part where we'll break our cascading hookup.  So, +1 (Let me
ping Chris to see if this mapred vs mapreduce story for cascading is going
to change any time soon).
St.Ack

On Fri, Jan 15, 2010 at 2:02 PM, Jean-Daniel Cryans <jd...@apache.org>wrote:

> Hi devs,
>
> The removing of the old HBase mapred API while Hadoop 0.21 is still
> keeping it causes the situation where we are forcing users to migrate
> while they may not have to. Also, other projects like cascading
> continue to rely on the old Hadoop mapred API so their HBase module
> will break. This is very problematic.
>
> What I propose is that we get the org.apache.hadoop.hbase.mapred
> package back in 0.21. To do that, we need to refactor all the
> dependencies on the old client API to use the new one. The impact on
> users upgrading from 0.20 to 0.21 with MR jobs using the old package
> will be the same, they will have to change all the client calls in
> their code.
>
> This is ok with everyone?
>
> If the vote passes, I will do the work.
>
> J-D
>

Re: Vote on getting org.apache.hadoop.hbase.mapred back in 0.21

[Andrew Purtell <ap...@apache.org>]

+1 since Hadoop 0.21 is keeping it. 



----- Original Message ----
> From: Jean-Daniel Cryans <jd...@apache.org>
> To: HBase Dev List <hb...@hadoop.apache.org>
> Sent: Fri, January 15, 2010 2:02:26 PM
> Subject: Vote on getting org.apache.hadoop.hbase.mapred back in 0.21
> 
> Hi devs,
> 
> The removing of the old HBase mapred API while Hadoop 0.21 is still
> keeping it causes the situation where we are forcing users to migrate
> while they may not have to. Also, other projects like cascading
> continue to rely on the old Hadoop mapred API so their HBase module
> will break. This is very problematic.
> 
> What I propose is that we get the org.apache.hadoop.hbase.mapred
> package back in 0.21. To do that, we need to refactor all the
> dependencies on the old client API to use the new one. The impact on
> users upgrading from 0.20 to 0.21 with MR jobs using the old package
> will be the same, they will have to change all the client calls in
> their code.
> 
> This is ok with everyone?
> 
> If the vote passes, I will do the work.
> 
> J-D



      

Re: Vote on getting org.apache.hadoop.hbase.mapred back in 0.21

[Jean-Daniel Cryans <jd...@apache.org>]

Alright let's do it. I opened https://issues.apache.org/jira/browse/HBASE-2136

Thx Andrew, Stack and Kay Kay!

J-D

On Fri, Jan 15, 2010 at 2:54 PM, Kay Kay <ka...@gmail.com> wrote:
> Not exactly a developer , but then +1 to maintain that since the stability
> of mapreduce-0.21 is a major source of concern (with the new packages) at
> this point with refactoring going on in that arena. It is going to be some
> time before that could be trusted entirely.
>
> At that point in the future, may be we can also have   *.mapreduce.*
> packages going with the new classes as well.  Thanks.
>
>
>
> On 1/15/10 2:02 PM, Jean-Daniel Cryans wrote:
>>
>> Hi devs,
>>
>> The removing of the old HBase mapred API while Hadoop 0.21 is still
>> keeping it causes the situation where we are forcing users to migrate
>> while they may not have to. Also, other projects like cascading
>> continue to rely on the old Hadoop mapred API so their HBase module
>> will break. This is very problematic.
>>
>> What I propose is that we get the org.apache.hadoop.hbase.mapred
>> package back in 0.21. To do that, we need to refactor all the
>> dependencies on the old client API to use the new one. The impact on
>> users upgrading from 0.20 to 0.21 with MR jobs using the old package
>> will be the same, they will have to change all the client calls in
>> their code.
>>
>> This is ok with everyone?
>>
>> If the vote passes, I will do the work.
>>
>> J-D
>>
>>
>
>

Re: Vote on getting org.apache.hadoop.hbase.mapred back in 0.21

[Kay Kay <ka...@gmail.com>]

Not exactly a developer , but then +1 to maintain that since the 
stability of mapreduce-0.21 is a major source of concern (with the new 
packages) at this point with refactoring going on in that arena. It is 
going to be some time before that could be trusted entirely.

At that point in the future, may be we can also have   *.mapreduce.* 
packages going with the new classes as well.  Thanks.



On 1/15/10 2:02 PM, Jean-Daniel Cryans wrote:
> Hi devs,
>
> The removing of the old HBase mapred API while Hadoop 0.21 is still
> keeping it causes the situation where we are forcing users to migrate
> while they may not have to. Also, other projects like cascading
> continue to rely on the old Hadoop mapred API so their HBase module
> will break. This is very problematic.
>
> What I propose is that we get the org.apache.hadoop.hbase.mapred
> package back in 0.21. To do that, we need to refactor all the
> dependencies on the old client API to use the new one. The impact on
> users upgrading from 0.20 to 0.21 with MR jobs using the old package
> will be the same, they will have to change all the client calls in
> their code.
>
> This is ok with everyone?
>
> If the vote passes, I will do the work.
>
> J-D
>
>