hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Purtell <apurt...@apache.org>
Subject Re: Code review request for hbase-4120 table priority
Date Tue, 13 Dec 2011 00:30:51 GMT
HBASE-4120 deals with only the RPC prioritization parts. This cannot be implemented as a coprocessor.

> If it's completely a coprocessor, then it seems we should let it bake
> on github and only incorporate in core if we find that a number of the
> core HBase users are using it in production.  


The addition of the coprocessor framework is from my point of view a double edged sword. It
can be a tool to clarify core and reduce maintenance burden on the community for various
boutique functions. On the other hand it can be used to freeze further feature development
and leave users who need such features out in the cold to go their own way or make a private
fork. 

I've become aware of several private forks of HDFS and HBase. Too bad. A pooling of dev resources
would have almost surely have been better.

HBASE-4120 and successor issues are / will be an attempt to take what runs in production at
Taobao and upstream it. They could just do a code drop on GitHub of what they have now. Would
be much easier than reimplementing it as a coprocessor. However they have incentive here to
give back to upstream, additional co-development with the community, for inclusion of their
work in the distribution. What is the incentive if we want them to make the reimplementation
effort only to then just drop that on GitHub?

There are some cases where it would benefit all users to include coprocessor-based features
in tree: Like security. Perhaps like constraints. Like the isolation/allocation stuff, for
perhaps 0.94. Perhaps secondary indexing. In all of these cases, though the majority of the
implementation is as coprocessor, there must be some changes to core -- to the coprocessor
framework, generally -- to support it. A coprocessor can be included in the tree as a maven
module. Without such inclusion, the rationale for not dropping the enabling logic in core
may be lacking ... "oh, this just supports some GitHub thing".

Best regards,


   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White)


----- Original Message -----
> From: Todd Lipcon <todd@cloudera.com>
> To: dev@hbase.apache.org
> Cc: 
> Sent: Monday, December 12, 2011 4:03 PM
> Subject: Re: Code review request for hbase-4120 table priority
> 
> If it's completely a coprocessor, then it seems we should let it bake
> on github and only incorporate in core if we find that a number of the
> core HBase users are using it in production. Am I misunderstanding the
> implementation? (haven't looked at the most recent patch)
> 
> -Todd
> 
> On Mon, Dec 12, 2011 at 3:50 PM,  <yuzhihong@gmail.com> wrote:
>>  Waiting for review comments from other committers.
>>  The implementation is pluggable by using coprocessors.
>> 
>>  Cheers
>> 
>> 
>> 
>>  On Dec 12, 2011, at 5:43 PM, Stack <stack@duboce.net> wrote:
>> 
>>>  On Mon, Dec 12, 2011 at 6:43 AM,  <yuzhihong@gmail.com> wrote:
>>>>  Hi,
>>>>  4120 has gone through more than 20 revisions.
>>>> 
>>>>  Please provide your comments.
>>>> 
>>>>  I plan to integrate it this week.
>>>> 
>>> 
>>>  I'd suggest hold on commit until some other committers have had a
>>>  looksee.  This is an important feature that we need to get right and
>>>  there is no need to rush it in.
>>> 
>>>  Thanks Ted (and thanks for the reviews so far),
>>>  St.Ack
> 
> 
> 
> -- 
> Todd Lipcon
> Software Engineer, Cloudera
> 

Mime
View raw message