hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stack <st...@duboce.net>
Subject Re: dynamic RPC and coprocessor changes
Date Wed, 06 Oct 2010 18:31:38 GMT
I spent some time reviewing the two fat patches that are up in
review.hbase.org.  I haven't finished either review yet -- they are
large patches (and sorry for taking so long to get around to the
reviews Andrew, Gary and 	Mingjie) -- but here's a few high-level
observations.  Please correct me if I'm off in any way.

+ Its a fat, quality contrib. of some really sweet functionality
+ It looks like both of the big patches have to go in for the
functionality to be complete (2001+2002)
+ There looks to me to be work to do yet, at least from what I've
seen.  Nothing that one or two more rounds of patch+review couldn't
fix but in at least a few cases, there are currently IMO blockers on
commit (The CP-specific but generically named classes in client
package that Gary is working on and some base class namings in CP
+ The patch+review cycle will take some time to complete not least
because the patches are big -- a week under normal circumstances I'd
say and IMO this 'opportunity' where CP is put under the spotlight
should not be rushed -- but at this particular time there are
'distractions' that will likely push this out namely core bug-fixing,
testing, and stabilizations for 0.90 and HW so elapsed time will go
+ CP while super-cool is ancillary to HBase core

My fear is that adding in CP now will push out 0.90 by some
non-inconsequential amount of time.

My preference would be to not include CP in 0.90.

If 'exposure' is the justification for getting CP into 0.90 and it is
admittedly still malleable -- is this right? -- subject to change and
'experimental', doesn't it better belong in TRUNK post a 0.90 branch?
We could commit as soon as end-of-day today if was wanted?  Having it
in branch brings exposure and shows hbase projects committment to CP?


On Wed, Oct 6, 2010 at 9:14 AM, Andrew Purtell <apurtell@apache.org> wrote:
>> From: Todd Lipcon
>> If we could hold up the 0.90 release for enough time to do
>> a dev release or two with coprocessors, I'd be all for it.
>> But given the aims of the release, I don't think coprocessors
>> are a blocking feature.
> This position makes sense when viewed through the lens of your priorities. However it
also confirms my suspicion coprocessors as a feature is somehow considered second class.
> That said, I do acknowledge I let coprocessors sit for a while so someone else could
pick up what was on jira and iterate on it. Anticipating many of the points raised in this
discussion, especially the one about having multiple parties try it out on their use cases.
But nobody did, so I eventually tasked our guys to finish it. We also agreed to base our security
work on it. So coprocessors blocks all of our stuff now. Then we put coprocessor patches for
review. They sat there untouched for many days. Now I'm agitating for inclusion because otherwise
it seems this feature would be ignored. At the same time, we have received comment the coprocessor
framework is exciting, which is incongruent.
>> I think, though, that for this kind of large new framework,
>> we want to have some experience actually trying to use it -
>> having at least one other person/company outside of
>> TrendMicro use the framework to build a non-toy app is the
>> requirement in my mind.
> That would be great, but it is totally out of my control, so making it a precondition
for inclusion seems somewhat unfair.
>   - Andy

View raw message