hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From yuzhih...@gmail.com
Subject Re: Code review request for hbase-4120 table priority
Date Tue, 13 Dec 2011 08:42:33 GMT
Thanks for the suggestion, Lars. 
The original scope for 4120 is bigger than the latest patch which only covers table priorities.


Let's perform more reviews for the current patch. We can create more subtasks for the umbrella
feature. 

Cheers



On Dec 12, 2011, at 11:23 PM, lars hofhansl <lhofhansl@yahoo.com> wrote:

> While I haven't looked (in depth) at the patch, yet, this is definitely a feature that
will be extremely helpful
> for Salesforce's multitenant architecture to isolate tenants and services from each other.
> 
> While we don't have HBase in our production data centers, yet (working on it), I am certain
that we will use this feature
> eventually.
> 
> Would it help to break the patch into multiple smaller patches?
> 
> Off the bat I think of:
> 1. the grouping logic
> 2. regionserver configuration (caching, etc) per group
> 3. table priorities
> 4. etc... (folks who have actually looked at the patch can probably identify better demarcations
between the aspects of this change.)
> 
> That would certainly make it more manageable for me - personally - to review the code.
> 
> -- Lars
> 
> 
> ----- Original Message -----
> From: Todd Lipcon <todd@cloudera.com>
> To: dev@hbase.apache.org; Andrew Purtell <apurtell@apache.org>
> Cc: 
> Sent: Monday, December 12, 2011 4:55 PM
> Subject: Re: Code review request for hbase-4120 table priority
> 
> On Mon, Dec 12, 2011 at 4:36 PM, Andrew Purtell <apurtell@apache.org> wrote:
>> 
>> HBase as a project should not have as a criteria for inclusion of some feature that
Cloudera and SU and Facebook run it. Core managed to escape Yahoo. Let's not run history in
reverse here in HBase land. And, actually, this makes it worse, because the the occurrence
that a number of core HBase users (multiple) will all need something is substantially less
likely than if one might find it useful; or, maybe, only users outside of those with such
self-appointed attitude, yet perhaps a community multiples in size of "core users".
> 
> It's not about Cloudera/SU/FB - it's about code that will be supported
> by people who are committed to the project. TrendMicro certainly fits
> the bill. I of course mean no offense to Lu Jia, but neither he nor
> Taobao has made continued contributions in the past - just one other
> bug fix beyond the HBASE-4120 project.
> 
> If we have a few of the core people committed to running this in
> production and supporting it in the future, I'm all for it (just like
> I am +1 on security). I just want to avoid repeating mistakes like the
> Avro server which isn't really supported despite being in our
> codebase. (You'll note this was a Cloudera contribution but from a
> contributor who was doing this in his spare time rather than part of
> job responsibilities, and we have never run it in production
> scenarios)
> 
> I am consistently conservative on what goes into the project because
> we have to stand behind what we release. I certainly don't think _all_
> core people should find every feature useful (eg REST and Thrift are
> examples of some things which are useless to many but I think make
> sense). But if _no_ core people see a feature as a requirement then
> I'd rather let it bake until we have many people requesting it.
> Otherwise people download HBase, try out these "fringe" features, and
> get a bad taste in their mouth when they've bit-rot across several
> versions of little usage.
> 
> -Todd
> -- 
> Todd Lipcon
> Software Engineer, Cloudera
> 

Mime
View raw message