dynamic RPC and coprocessor changes

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

We've been nursing dynamic RPC and coprocessor changes for a couple of weeks now and don't see any failures beyond what are already on trunk with them applied.

I was going to apply them tonight but will wait until tomorrow given that trunk is already disrupted a little. 

Best regards,

    - Andy



      

Re: dynamic RPC and coprocessor changes

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

+1, looking forward to these changes.

J-D

On Tue, Oct 5, 2010 at 7:13 PM, Andrew Purtell <ap...@apache.org> wrote:
> We've been nursing dynamic RPC and coprocessor changes for a couple of weeks now and don't see any failures beyond what are already on trunk with them applied.
>
> I was going to apply them tonight but will wait until tomorrow given that trunk is already disrupted a little.
>
> Best regards,
>
>    - Andy
>
>
>
>
>
>

Re: dynamic RPC and coprocessor changes

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

Well, three +0 is enough to resolve this discussion I think. 

> From: stack
>
> 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?

Since this appears to be the best possible outcome for us, we'll take it.

   - Andy



      

Re: dynamic RPC and coprocessor changes

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

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
package).
+ 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
up.
+ 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?

St.Ack










On Wed, Oct 6, 2010 at 9:14 AM, Andrew Purtell <ap...@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
>
>
>
>
>
>

Re: dynamic RPC and coprocessor changes

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

> From: Ryan Rawson
>
> For what it's worth, the Result changes are just a few functions
> and represent a big bang for the buck in terms of lines of code
> added.  I fixed the build - sorry about that!

I wasn't trying to pick on these changes. You'll see a +1 from me on the jira because I agree .. big bang for the buck. It's just that seeing changes like this and others (blooms, replication, master changes, hfof, etc.) go in make rationalizations about 0.90 being a stability-only release incongruent. 

Let's not forget 0.90 is in fact a major release that contains a number of new features. 0.89 has not been a "real" release. 0.90 is a new major release that has new features relative to the last major release branch 0.20.x. 

It piques me that coprocessors have been largely deferred by everyone (I won't say "ignored") and this is used as a reason to hold up including them in the upcoming release. Especially as they do not change any core semantic. Except, arguably, the RPC changes may drift up to that line, I grant that.

>
> From: Jon Gray
>
> I just don't think this is the kind of thing that gets nailed with
> two weeks of code reviews.  It needs to be used, exercised, and
> different use cases need to be applied to it.
> 
> For example, the initial CP implementation underwent a huge amount
> of change once you guys started to make security work with it.
> That's just one use case.  Others will push it in new directions
> and will have different requirements.

I totally agree with this. However, as a project we have only been going through with deprecation in one release and removal in the next for client side code. 

Our client side changes are very generic and flexible. 

On the server side, the interfaces indeed may change with experience, but I anticipate the predominant type of change would be additions, as new users find they can't do something with the existing hooks, not change or removal of existing methods. For example, we have not added HLog hooking or looked at master extensibility (at least, how extending HLog plays with recovery). But this can be added without impacting any users of existing interfaces.  

We have already put coprocessors up in a feature branch, up on GitHub (http://github.com/trendmicro/hbase). I don't think it makes sense to do this in Apache SVN, because SVN is a lousy tool for maintaining feature branches and nobody looks at them anyway. However we know that the majority of users will not pull some arbitrary code from GitHub to use given there is an official ASF release tarball available. That's not an unreasonable position on their part. For coprocessors to have the widest exposure or use, they need to go in to a release. 

> 
> From: Gary Helmling
>
> For coprocessors, sure there were quite a few changes from the
> initial patches to actually using it to implement security, but a
> lot of that amounted to paring it down to a core usable scope.
> It will doubtless not address all use cases, but I think that will
> remain true whether it's included in 0.90 or 0.92.

Or 0.91, or 0.93, or 0.94 ...

This is the very first cut of a new feature. 

I expect to branch out from this beachhead in multiple directions, new extensibility for new use cases, some we know, some we haven't anticipated yet. I hope to introduce code weaving for the reasons talked about up on jira under HBASE-2000 somewhere (I think 2001). 

But we have to start somewhere...

   - Andy



      

Re: dynamic RPC and coprocessor changes

[Ryan Rawson <ry...@gmail.com>]

For what it's worth, the Result changes are just a few functions and
represent a big bang for the buck in terms of lines of code added.  I
fixed the build - sorry about that!

>From what I've seen, the coprocessor stuff interacts but isnt as crazy
as other things.  I'd say go for it.  We only get 1 chance a year to
release apparently.

-ryan

On Tue, Oct 5, 2010 at 8:49 PM, Todd Lipcon <to...@cloudera.com> wrote:
> On Tue, Oct 5, 2010 at 8:17 PM, Andrew Purtell <ap...@apache.org> wrote:
>
>> > It's not a matter of viewing it as second-class, but more
>> > that it's not necessarily within scope for this exact
>> > release -- in general we have always talked about 0.90 as
>> > a release where we focus on stability and durability.
>>
>> What of replication?
>>
>> Or HFOF?
>>
>>
> Both of these went into our very first 0.89 dev release this summer, and
> have been tried out on clusters for multiple dev releases since. In
> replication's case, it's only been used so far at StumbleUpon AFAIK, but the
> new HFOF support has been used in real workloads at at least 5 companies off
> the top of my head, three of which do not employ any contributors. Like i
> said above, I think new APIs and new big features should go in early in a DR
> series, not right before the release itself.
>
> 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.
>
>
>> Or the recent Result changes?
>>
>>
> Honestly I've been too swamped to look at these, but if it's a substantial
> new API I also think it should be held for 0.92 as well. If it's a few new
> function calls to existing classes, it seems OK to put it in late.
>
>
>> None are in scope for a stability and durability release.
>>
>> HBASE-2001 has been little changed for 6 months. We've made incremental
>> changes to the server side framework but it's been basically as stable as
>> possible given the changes around it. Then, Gary added a big push with a lot
>> of work on client side support. This part is newer, I grant you that.
>>
>> That it has not received as much review or experience as perhaps you would
>> like means mainly that other HBase committers have had other priorities.
>>
>
> That's true - I've been wanting to review it for months but haven't had time
> to do so. Apologies for that. 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. I'm pretty
> sure I said exactly that on the very first coprocessor patch, and my opinion
> is the same- it's an awful lot of code that has the primary purpose of
> extensibility, and if we don't have some examples of real extensions, it's
> hard to know if it's all good.
>
> For example, I imagine the Lily people could make good use of this
> framework. Similarly, Sam Pullara's havrobase might provide some good use
> cases. The secondary indexing situation in HBase right now leaves a lot to
> be desired - maybe we could try implementing indexing based on CPs?
>
>
>> That does not mean we do not deserve due consideration.
>>
>>
> Any thoughts on releasing an 0.90-coprocessors-preview next to 0.90, off the
> branch (ie without merging)? I think if we did this, in conjunction with a
> few good blog posts on the hbase blog about example use cases, we could drum
> up some interest and get some feedback, and then merge for 0.92.
>
> -Todd
>
>
>>   - Andy
>>
>> > From: Todd Lipcon <to...@cloudera.com>
>> > Subject: Re: dynamic RPC and coprocessor changes
>> > To: dev@hbase.apache.org
>> > Cc: "apurtell@apache.org" <ap...@apache.org>
>> > Date: Tuesday, October 5, 2010, 7:57 PM
>> > I agree with Jon here.
>> >
>> > It's not a matter of viewing it as second-class, but more
>> > that it's not
>> > necessarily within scope for this exact release -- in
>> > general we have always
>> > talked about 0.90 as a release where we focus on stability
>> > and durability. A
>> > giant new framework (awesome though it is) seems less
>> > important for this
>> > specific dot release. I also agree that we need to have a
>> > few more use cases
>> > developed to flesh out the API and get more exposure before
>> > merging.
>> >
>> > The idea of the development release series was to give
>> > people exposure to
>> > stuff (and get testing) before it ended up in a so-called
>> > "stable" release.
>> > A large merge should definitely go through at least one or
>> > two dev releases
>> > before showing up in an even-numbered .0. I would also
>> > support a
>> > "coprocessors preview" release done in parallel with 0.90,
>> > available on the
>> > Apache download page, that would let interested people get
>> > involved and try
>> > the branch before it's part of trunk.
>> >
>> > For the same reasons, I also wanted to release
>> > 0.89.20100924 as 0.90 and
>> > push off the new master to 92, but I think I lost that one
>> > :)
>> >
>> > I also agree strongly with Jon that we should immediately
>> > start an 0.91 DR
>> > series with coprocessors merged as soon as 0.90 is
>> > released. We have some
>> > good momentum, and moving quickly towards the next bit will
>> > help keep it up.
>> >
>> > -Todd
>> >
>> > On Tue, Oct 5, 2010 at 7:30 PM, Jonathan Gray <jg...@facebook.com>
>> > wrote:
>> >
>> > > Committing this stuff onto trunk the day before a
>> > feature freeze and as we
>> > > move towards stability gives me a little bit of the
>> > fear.
>> > >
>> > > I completely understand that it's been worked on for
>> > quite some time and
>> > > think this stuff is awesome.  But I still wish I
>> > had more time to give it
>> > > further review and to actually take this stuff for a
>> > test spin.  Right now
>> > > that's just not possible with all the work to be done
>> > stabilizing and
>> > > testing trunk (and I think time is best spent right
>> > now stabilizing the
>> > > master/rs versus new features).
>> > >
>> > > Personally, I have a bunch of fairly sweeping
>> > compaction, flush, and split
>> > > changes that have been partially reviewed but I
>> > haven't had the time to push
>> > > them over the finish line.  I hope to get them in
>> > immediately after an 0.90
>> > > branch is cut and trunk becomes 0.92.  This
>> > should be rather soon.  I'd like
>> > > to see 0.92 get released in short order after 0.90 as
>> > there are lots of
>> > > changes that just have not made it into 0.90
>> > yet.  So even if we waited to
>> > > commit, we could work hard towards the next major
>> > release (I don't think
>> > > there are any major rewrites planned)  :)
>> > >
>> > > With this kind of big change and addition of new APIs,
>> > my preference would
>> > > be to have it committed early in a trunk cycle (versus
>> > immediately before a
>> > > release is cut).  That way, we can play with it
>> > ourselves, see how it works,
>> > > try out some of our own ideas for usage of CPs, etc...
>> > In doing that, I
>> > > would expect there would be suggestions for changes in
>> > the API, additions to
>> > > the API, naming changes to be more clear from a
>> > non-implementer POV, etc...
>> > >
>> > > By putting it in immediately before a release, the
>> > original API can't be
>> > > broken, class names can't be changed, all would need
>> > to be deprecated,
>> > > etc...
>> > >
>> > > The other issue I have with the current CP code that I
>> > have read is the
>> > > number of new classes introduced into existing core
>> > packages (especially
>> > > clent).  Looking at some of their names, they are
>> > generic sounding and it's
>> > > not clear to me without digging in that they are part
>> > of coprocessors.  Is
>> > > it possible to move CP stuff into client.cp packages
>> > and the like?  Or
>> > > prefix with CoProc or some way to keep this stuff
>> > separated?
>> > >
>> > > I apologize for dropping this on you now and if no one
>> > else feels the same,
>> > > I am not going to spoil the party.
>> > >
>> > > But is it critical that this gets into 0.90 and into a
>> > release now?  Could
>> > > we wait for 0.92 and get this committed in a couple
>> > weeks and allowed to
>> > > mature a bit on trunk before it's released?
>> > >
>> > > JG
>> > >
>> > > > -----Original Message-----
>> > > > From: Andrew Purtell [mailto:apurtell@apache.org]
>> > > > Sent: Tuesday, October 05, 2010 7:14 PM
>> > > > To: dev@hbase.apache.org
>> > > > Subject: dynamic RPC and coprocessor changes
>> > > >
>> > > > We've been nursing dynamic RPC and coprocessor
>> > changes for a couple of
>> > > > weeks now and don't see any failures beyond what
>> > are already on trunk
>> > > > with them applied.
>> > > >
>> > > > I was going to apply them tonight but will wait
>> > until tomorrow given
>> > > > that trunk is already disrupted a little.
>> > > >
>> > > > Best regards,
>> > > >
>> > > >     - Andy
>> > > >
>> > > >
>> > > >
>> > > >
>> > >
>> > >
>> >
>> >
>> > --
>> > Todd Lipcon
>> > Software Engineer, Cloudera
>> >
>>
>>
>>
>>
>>
>
>
> --
> Todd Lipcon
> Software Engineer, Cloudera
>

Re: dynamic RPC and coprocessor changes

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

> 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



      

Re: dynamic RPC and coprocessor changes

[Todd Lipcon <to...@cloudera.com>]

On Tue, Oct 5, 2010 at 8:17 PM, Andrew Purtell <ap...@apache.org> wrote:

> > It's not a matter of viewing it as second-class, but more
> > that it's not necessarily within scope for this exact
> > release -- in general we have always talked about 0.90 as
> > a release where we focus on stability and durability.
>
> What of replication?
>
> Or HFOF?
>
>
Both of these went into our very first 0.89 dev release this summer, and
have been tried out on clusters for multiple dev releases since. In
replication's case, it's only been used so far at StumbleUpon AFAIK, but the
new HFOF support has been used in real workloads at at least 5 companies off
the top of my head, three of which do not employ any contributors. Like i
said above, I think new APIs and new big features should go in early in a DR
series, not right before the release itself.

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.


> Or the recent Result changes?
>
>
Honestly I've been too swamped to look at these, but if it's a substantial
new API I also think it should be held for 0.92 as well. If it's a few new
function calls to existing classes, it seems OK to put it in late.


> None are in scope for a stability and durability release.
>
> HBASE-2001 has been little changed for 6 months. We've made incremental
> changes to the server side framework but it's been basically as stable as
> possible given the changes around it. Then, Gary added a big push with a lot
> of work on client side support. This part is newer, I grant you that.
>
> That it has not received as much review or experience as perhaps you would
> like means mainly that other HBase committers have had other priorities.
>

That's true - I've been wanting to review it for months but haven't had time
to do so. Apologies for that. 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. I'm pretty
sure I said exactly that on the very first coprocessor patch, and my opinion
is the same- it's an awful lot of code that has the primary purpose of
extensibility, and if we don't have some examples of real extensions, it's
hard to know if it's all good.

For example, I imagine the Lily people could make good use of this
framework. Similarly, Sam Pullara's havrobase might provide some good use
cases. The secondary indexing situation in HBase right now leaves a lot to
be desired - maybe we could try implementing indexing based on CPs?


> That does not mean we do not deserve due consideration.
>
>
Any thoughts on releasing an 0.90-coprocessors-preview next to 0.90, off the
branch (ie without merging)? I think if we did this, in conjunction with a
few good blog posts on the hbase blog about example use cases, we could drum
up some interest and get some feedback, and then merge for 0.92.

-Todd


>   - Andy
>
> > From: Todd Lipcon <to...@cloudera.com>
> > Subject: Re: dynamic RPC and coprocessor changes
> > To: dev@hbase.apache.org
> > Cc: "apurtell@apache.org" <ap...@apache.org>
> > Date: Tuesday, October 5, 2010, 7:57 PM
> > I agree with Jon here.
> >
> > It's not a matter of viewing it as second-class, but more
> > that it's not
> > necessarily within scope for this exact release -- in
> > general we have always
> > talked about 0.90 as a release where we focus on stability
> > and durability. A
> > giant new framework (awesome though it is) seems less
> > important for this
> > specific dot release. I also agree that we need to have a
> > few more use cases
> > developed to flesh out the API and get more exposure before
> > merging.
> >
> > The idea of the development release series was to give
> > people exposure to
> > stuff (and get testing) before it ended up in a so-called
> > "stable" release.
> > A large merge should definitely go through at least one or
> > two dev releases
> > before showing up in an even-numbered .0. I would also
> > support a
> > "coprocessors preview" release done in parallel with 0.90,
> > available on the
> > Apache download page, that would let interested people get
> > involved and try
> > the branch before it's part of trunk.
> >
> > For the same reasons, I also wanted to release
> > 0.89.20100924 as 0.90 and
> > push off the new master to 92, but I think I lost that one
> > :)
> >
> > I also agree strongly with Jon that we should immediately
> > start an 0.91 DR
> > series with coprocessors merged as soon as 0.90 is
> > released. We have some
> > good momentum, and moving quickly towards the next bit will
> > help keep it up.
> >
> > -Todd
> >
> > On Tue, Oct 5, 2010 at 7:30 PM, Jonathan Gray <jg...@facebook.com>
> > wrote:
> >
> > > Committing this stuff onto trunk the day before a
> > feature freeze and as we
> > > move towards stability gives me a little bit of the
> > fear.
> > >
> > > I completely understand that it's been worked on for
> > quite some time and
> > > think this stuff is awesome.  But I still wish I
> > had more time to give it
> > > further review and to actually take this stuff for a
> > test spin.  Right now
> > > that's just not possible with all the work to be done
> > stabilizing and
> > > testing trunk (and I think time is best spent right
> > now stabilizing the
> > > master/rs versus new features).
> > >
> > > Personally, I have a bunch of fairly sweeping
> > compaction, flush, and split
> > > changes that have been partially reviewed but I
> > haven't had the time to push
> > > them over the finish line.  I hope to get them in
> > immediately after an 0.90
> > > branch is cut and trunk becomes 0.92.  This
> > should be rather soon.  I'd like
> > > to see 0.92 get released in short order after 0.90 as
> > there are lots of
> > > changes that just have not made it into 0.90
> > yet.  So even if we waited to
> > > commit, we could work hard towards the next major
> > release (I don't think
> > > there are any major rewrites planned)  :)
> > >
> > > With this kind of big change and addition of new APIs,
> > my preference would
> > > be to have it committed early in a trunk cycle (versus
> > immediately before a
> > > release is cut).  That way, we can play with it
> > ourselves, see how it works,
> > > try out some of our own ideas for usage of CPs, etc...
> > In doing that, I
> > > would expect there would be suggestions for changes in
> > the API, additions to
> > > the API, naming changes to be more clear from a
> > non-implementer POV, etc...
> > >
> > > By putting it in immediately before a release, the
> > original API can't be
> > > broken, class names can't be changed, all would need
> > to be deprecated,
> > > etc...
> > >
> > > The other issue I have with the current CP code that I
> > have read is the
> > > number of new classes introduced into existing core
> > packages (especially
> > > clent).  Looking at some of their names, they are
> > generic sounding and it's
> > > not clear to me without digging in that they are part
> > of coprocessors.  Is
> > > it possible to move CP stuff into client.cp packages
> > and the like?  Or
> > > prefix with CoProc or some way to keep this stuff
> > separated?
> > >
> > > I apologize for dropping this on you now and if no one
> > else feels the same,
> > > I am not going to spoil the party.
> > >
> > > But is it critical that this gets into 0.90 and into a
> > release now?  Could
> > > we wait for 0.92 and get this committed in a couple
> > weeks and allowed to
> > > mature a bit on trunk before it's released?
> > >
> > > JG
> > >
> > > > -----Original Message-----
> > > > From: Andrew Purtell [mailto:apurtell@apache.org]
> > > > Sent: Tuesday, October 05, 2010 7:14 PM
> > > > To: dev@hbase.apache.org
> > > > Subject: dynamic RPC and coprocessor changes
> > > >
> > > > We've been nursing dynamic RPC and coprocessor
> > changes for a couple of
> > > > weeks now and don't see any failures beyond what
> > are already on trunk
> > > > with them applied.
> > > >
> > > > I was going to apply them tonight but will wait
> > until tomorrow given
> > > > that trunk is already disrupted a little.
> > > >
> > > > Best regards,
> > > >
> > > >     - Andy
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
> > --
> > Todd Lipcon
> > Software Engineer, Cloudera
> >
>
>
>
>
>


-- 
Todd Lipcon
Software Engineer, Cloudera

Re: dynamic RPC and coprocessor changes

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

> It's not a matter of viewing it as second-class, but more
> that it's not necessarily within scope for this exact
> release -- in general we have always talked about 0.90 as 
> a release where we focus on stability and durability. 

What of replication?

Or HFOF? 

Or the recent Result changes?

None are in scope for a stability and durability release.

HBASE-2001 has been little changed for 6 months. We've made incremental changes to the server side framework but it's been basically as stable as possible given the changes around it. Then, Gary added a big push with a lot of work on client side support. This part is newer, I grant you that.

That it has not received as much review or experience as perhaps you would like means mainly that other HBase committers have had other priorities. 

That does not mean we do not deserve due consideration.

   - Andy

> From: Todd Lipcon <to...@cloudera.com>
> Subject: Re: dynamic RPC and coprocessor changes
> To: dev@hbase.apache.org
> Cc: "apurtell@apache.org" <ap...@apache.org>
> Date: Tuesday, October 5, 2010, 7:57 PM
> I agree with Jon here.
> 
> It's not a matter of viewing it as second-class, but more
> that it's not
> necessarily within scope for this exact release -- in
> general we have always
> talked about 0.90 as a release where we focus on stability
> and durability. A
> giant new framework (awesome though it is) seems less
> important for this
> specific dot release. I also agree that we need to have a
> few more use cases
> developed to flesh out the API and get more exposure before
> merging.
> 
> The idea of the development release series was to give
> people exposure to
> stuff (and get testing) before it ended up in a so-called
> "stable" release.
> A large merge should definitely go through at least one or
> two dev releases
> before showing up in an even-numbered .0. I would also
> support a
> "coprocessors preview" release done in parallel with 0.90,
> available on the
> Apache download page, that would let interested people get
> involved and try
> the branch before it's part of trunk.
> 
> For the same reasons, I also wanted to release
> 0.89.20100924 as 0.90 and
> push off the new master to 92, but I think I lost that one
> :)
> 
> I also agree strongly with Jon that we should immediately
> start an 0.91 DR
> series with coprocessors merged as soon as 0.90 is
> released. We have some
> good momentum, and moving quickly towards the next bit will
> help keep it up.
> 
> -Todd
> 
> On Tue, Oct 5, 2010 at 7:30 PM, Jonathan Gray <jg...@facebook.com>
> wrote:
> 
> > Committing this stuff onto trunk the day before a
> feature freeze and as we
> > move towards stability gives me a little bit of the
> fear.
> >
> > I completely understand that it's been worked on for
> quite some time and
> > think this stuff is awesome.  But I still wish I
> had more time to give it
> > further review and to actually take this stuff for a
> test spin.  Right now
> > that's just not possible with all the work to be done
> stabilizing and
> > testing trunk (and I think time is best spent right
> now stabilizing the
> > master/rs versus new features).
> >
> > Personally, I have a bunch of fairly sweeping
> compaction, flush, and split
> > changes that have been partially reviewed but I
> haven't had the time to push
> > them over the finish line.  I hope to get them in
> immediately after an 0.90
> > branch is cut and trunk becomes 0.92.  This
> should be rather soon.  I'd like
> > to see 0.92 get released in short order after 0.90 as
> there are lots of
> > changes that just have not made it into 0.90
> yet.  So even if we waited to
> > commit, we could work hard towards the next major
> release (I don't think
> > there are any major rewrites planned)  :)
> >
> > With this kind of big change and addition of new APIs,
> my preference would
> > be to have it committed early in a trunk cycle (versus
> immediately before a
> > release is cut).  That way, we can play with it
> ourselves, see how it works,
> > try out some of our own ideas for usage of CPs, etc...
> In doing that, I
> > would expect there would be suggestions for changes in
> the API, additions to
> > the API, naming changes to be more clear from a
> non-implementer POV, etc...
> >
> > By putting it in immediately before a release, the
> original API can't be
> > broken, class names can't be changed, all would need
> to be deprecated,
> > etc...
> >
> > The other issue I have with the current CP code that I
> have read is the
> > number of new classes introduced into existing core
> packages (especially
> > clent).  Looking at some of their names, they are
> generic sounding and it's
> > not clear to me without digging in that they are part
> of coprocessors.  Is
> > it possible to move CP stuff into client.cp packages
> and the like?  Or
> > prefix with CoProc or some way to keep this stuff
> separated?
> >
> > I apologize for dropping this on you now and if no one
> else feels the same,
> > I am not going to spoil the party.
> >
> > But is it critical that this gets into 0.90 and into a
> release now?  Could
> > we wait for 0.92 and get this committed in a couple
> weeks and allowed to
> > mature a bit on trunk before it's released?
> >
> > JG
> >
> > > -----Original Message-----
> > > From: Andrew Purtell [mailto:apurtell@apache.org]
> > > Sent: Tuesday, October 05, 2010 7:14 PM
> > > To: dev@hbase.apache.org
> > > Subject: dynamic RPC and coprocessor changes
> > >
> > > We've been nursing dynamic RPC and coprocessor
> changes for a couple of
> > > weeks now and don't see any failures beyond what
> are already on trunk
> > > with them applied.
> > >
> > > I was going to apply them tonight but will wait
> until tomorrow given
> > > that trunk is already disrupted a little.
> > >
> > > Best regards,
> > >
> > >     - Andy
> > >
> > >
> > >
> > >
> >
> >
> 
> 
> -- 
> Todd Lipcon
> Software Engineer, Cloudera
> 


      

Re: dynamic RPC and coprocessor changes

[Todd Lipcon <to...@cloudera.com>]

I agree with Jon here.

It's not a matter of viewing it as second-class, but more that it's not
necessarily within scope for this exact release -- in general we have always
talked about 0.90 as a release where we focus on stability and durability. A
giant new framework (awesome though it is) seems less important for this
specific dot release. I also agree that we need to have a few more use cases
developed to flesh out the API and get more exposure before merging.

The idea of the development release series was to give people exposure to
stuff (and get testing) before it ended up in a so-called "stable" release.
A large merge should definitely go through at least one or two dev releases
before showing up in an even-numbered .0. I would also support a
"coprocessors preview" release done in parallel with 0.90, available on the
Apache download page, that would let interested people get involved and try
the branch before it's part of trunk.

For the same reasons, I also wanted to release 0.89.20100924 as 0.90 and
push off the new master to 92, but I think I lost that one :)

I also agree strongly with Jon that we should immediately start an 0.91 DR
series with coprocessors merged as soon as 0.90 is released. We have some
good momentum, and moving quickly towards the next bit will help keep it up.

-Todd

On Tue, Oct 5, 2010 at 7:30 PM, Jonathan Gray <jg...@facebook.com> wrote:

> Committing this stuff onto trunk the day before a feature freeze and as we
> move towards stability gives me a little bit of the fear.
>
> I completely understand that it's been worked on for quite some time and
> think this stuff is awesome.  But I still wish I had more time to give it
> further review and to actually take this stuff for a test spin.  Right now
> that's just not possible with all the work to be done stabilizing and
> testing trunk (and I think time is best spent right now stabilizing the
> master/rs versus new features).
>
> Personally, I have a bunch of fairly sweeping compaction, flush, and split
> changes that have been partially reviewed but I haven't had the time to push
> them over the finish line.  I hope to get them in immediately after an 0.90
> branch is cut and trunk becomes 0.92.  This should be rather soon.  I'd like
> to see 0.92 get released in short order after 0.90 as there are lots of
> changes that just have not made it into 0.90 yet.  So even if we waited to
> commit, we could work hard towards the next major release (I don't think
> there are any major rewrites planned)  :)
>
> With this kind of big change and addition of new APIs, my preference would
> be to have it committed early in a trunk cycle (versus immediately before a
> release is cut).  That way, we can play with it ourselves, see how it works,
> try out some of our own ideas for usage of CPs, etc... In doing that, I
> would expect there would be suggestions for changes in the API, additions to
> the API, naming changes to be more clear from a non-implementer POV, etc...
>
> By putting it in immediately before a release, the original API can't be
> broken, class names can't be changed, all would need to be deprecated,
> etc...
>
> The other issue I have with the current CP code that I have read is the
> number of new classes introduced into existing core packages (especially
> clent).  Looking at some of their names, they are generic sounding and it's
> not clear to me without digging in that they are part of coprocessors.  Is
> it possible to move CP stuff into client.cp packages and the like?  Or
> prefix with CoProc or some way to keep this stuff separated?
>
> I apologize for dropping this on you now and if no one else feels the same,
> I am not going to spoil the party.
>
> But is it critical that this gets into 0.90 and into a release now?  Could
> we wait for 0.92 and get this committed in a couple weeks and allowed to
> mature a bit on trunk before it's released?
>
> JG
>
> > -----Original Message-----
> > From: Andrew Purtell [mailto:apurtell@apache.org]
> > Sent: Tuesday, October 05, 2010 7:14 PM
> > To: dev@hbase.apache.org
> > Subject: dynamic RPC and coprocessor changes
> >
> > We've been nursing dynamic RPC and coprocessor changes for a couple of
> > weeks now and don't see any failures beyond what are already on trunk
> > with them applied.
> >
> > I was going to apply them tonight but will wait until tomorrow given
> > that trunk is already disrupted a little.
> >
> > Best regards,
> >
> >     - Andy
> >
> >
> >
> >
>
>


-- 
Todd Lipcon
Software Engineer, Cloudera

RE: dynamic RPC and coprocessor changes

[Jonathan Gray <jg...@facebook.com>]

This is not at all about seeing CP as "second class".

As you know, I'm extremely excited about them and I think it's absolutely awesome how much work you guys have been putting in to them.  I have a bunch of plans for what I'd like to try to get done utilizing coprocessors.

My issues are about the timing and the nature of coprocessors.  I'd like to see this done in the best way possible.

IMO two weeks is not that much time to have something like this up for review, because it's not just about the code review (though I think that's important and there's been great back-and-forth).  If we were at the start of a new trunk/release cycle, I would actually be fine with committing it this week.  I (and others) would have time to play with it over the coming weeks and changes could still be made as it is out in the wild for a reasonable amount of time.

I just don't think this is the kind of thing that gets nailed with two weeks of code reviews.  It needs to be used, exercised, and different use cases need to be applied to it.

For example, the initial CP implementation underwent a huge amount of change once you guys started to make security work with it.  That's just one use case.  Others will push it in new directions and will have different requirements.

Of course it can still change after the initial release, but it gets much harder to make big changes and you have to worry about breaking compatibility.  We already dealt with this with filters and those are far simpler than coprocessors.


And I disagree strongly that we are going to continue to do yearly releases.  Our previous release rewrote the RS in a major way, changed our on-disk format, etc.   This release introduces appends/no data loss for the first time and the master has been completely redesigned.  And we've only just-now broken from the hadoop release cycle with 0.90.

The 0.92 release does not currently have any big sweeping changes like that planned.  It will/should be a feature release which adds a lot of the stuff we've all been working on in recent months but have not yet finished or polished, plus another month or so of additional work.  I'd like to push to get it out just a couple months after the 0.90 release.

JG

> -----Original Message-----
> From: Andrew Purtell [mailto:apurtell@apache.org]
> Sent: Tuesday, October 05, 2010 7:39 PM
> To: dev@hbase.apache.org
> Subject: RE: dynamic RPC and coprocessor changes
> 
> We have been working on this for a while. It represents a significant
> investment. I see no reason why this work should be viewed as second
> class compared with some of the other work that has already gone in for
> 0.90. The patches have been up on reviewboard for over two weeks now,
> ample time for review.
> 
> 
>   - Andy
> 
> 
> > From: Jonathan Gray <jg...@facebook.com>
> > Subject: RE: dynamic RPC and coprocessor changes
> > To: "dev@hbase.apache.org" <de...@hbase.apache.org>,
> "apurtell@apache.org" <ap...@apache.org>
> > Date: Tuesday, October 5, 2010, 7:30 PM
> > Committing this stuff onto trunk the
> > day before a feature freeze and as we move towards stability
> > gives me a little bit of the fear.
> >
> > I completely understand that it's been worked on for quite
> > some time and think this stuff is awesome.  But I still
> > wish I had more time to give it further review and to
> > actually take this stuff for a test spin.  Right now
> > that's just not possible with all the work to be done
> > stabilizing and testing trunk (and I think time is best
> > spent right now stabilizing the master/rs versus new
> > features).
> >
> > Personally, I have a bunch of fairly sweeping compaction,
> > flush, and split changes that have been partially reviewed
> > but I haven't had the time to push them over the finish
> > line.  I hope to get them in immediately after an 0.90
> > branch is cut and trunk becomes 0.92.  This should be
> > rather soon.  I'd like to see 0.92 get released in
> > short order after 0.90 as there are lots of changes that
> > just have not made it into 0.90 yet.  So even if we
> > waited to commit, we could work hard towards the next major
> > release (I don't think there are any major rewrites
> > planned)  :)
> >
> > With this kind of big change and addition of new APIs, my
> > preference would be to have it committed early in a trunk
> > cycle (versus immediately before a release is cut).
> > That way, we can play with it ourselves, see how it works,
> > try out some of our own ideas for usage of CPs, etc... In
> > doing that, I would expect there would be suggestions for
> > changes in the API, additions to the API, naming changes to
> > be more clear from a non-implementer POV, etc...
> >
> > By putting it in immediately before a release, the original
> > API can't be broken, class names can't be changed, all would
> > need to be deprecated, etc...
> >
> > The other issue I have with the current CP code that I have
> > read is the number of new classes introduced into existing
> > core packages (especially clent).  Looking at some of
> > their names, they are generic sounding and it's not clear to
> > me without digging in that they are part of
> > coprocessors.  Is it possible to move CP stuff into
> > client.cp packages and the like?  Or prefix with CoProc
> > or some way to keep this stuff separated?
> >
> > I apologize for dropping this on you now and if no one else
> > feels the same, I am not going to spoil the party.
> >
> > But is it critical that this gets into 0.90 and into a
> > release now?  Could we wait for 0.92 and get this
> > committed in a couple weeks and allowed to mature a bit on
> > trunk before it's released?
> >
> > JG
> >
> > > -----Original Message-----
> > > From: Andrew Purtell [mailto:apurtell@apache.org]
> > > Sent: Tuesday, October 05, 2010 7:14 PM
> > > To: dev@hbase.apache.org
> > > Subject: dynamic RPC and coprocessor changes
> > >
> > > We've been nursing dynamic RPC and coprocessor changes
> > for a couple of
> > > weeks now and don't see any failures beyond what are
> > already on trunk
> > > with them applied.
> > >
> > > I was going to apply them tonight but will wait until
> > tomorrow given
> > > that trunk is already disrupted a little.
> > >
> > > Best regards,
> > >
> > >     - Andy
> > >
> > >
> > >
> > >
> >
> >
> 
> 
> 

RE: dynamic RPC and coprocessor changes

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

We have been working on this for a while. It represents a significant investment. I see no reason why this work should be viewed as second class compared with some of the other work that has already gone in for 0.90. The patches have been up on reviewboard for over two weeks now, ample time for review. 


  - Andy


> From: Jonathan Gray <jg...@facebook.com>
> Subject: RE: dynamic RPC and coprocessor changes
> To: "dev@hbase.apache.org" <de...@hbase.apache.org>, "apurtell@apache.org" <ap...@apache.org>
> Date: Tuesday, October 5, 2010, 7:30 PM
> Committing this stuff onto trunk the
> day before a feature freeze and as we move towards stability
> gives me a little bit of the fear.
> 
> I completely understand that it's been worked on for quite
> some time and think this stuff is awesome.  But I still
> wish I had more time to give it further review and to
> actually take this stuff for a test spin.  Right now
> that's just not possible with all the work to be done
> stabilizing and testing trunk (and I think time is best
> spent right now stabilizing the master/rs versus new
> features).
> 
> Personally, I have a bunch of fairly sweeping compaction,
> flush, and split changes that have been partially reviewed
> but I haven't had the time to push them over the finish
> line.  I hope to get them in immediately after an 0.90
> branch is cut and trunk becomes 0.92.  This should be
> rather soon.  I'd like to see 0.92 get released in
> short order after 0.90 as there are lots of changes that
> just have not made it into 0.90 yet.  So even if we
> waited to commit, we could work hard towards the next major
> release (I don't think there are any major rewrites
> planned)  :)
> 
> With this kind of big change and addition of new APIs, my
> preference would be to have it committed early in a trunk
> cycle (versus immediately before a release is cut). 
> That way, we can play with it ourselves, see how it works,
> try out some of our own ideas for usage of CPs, etc... In
> doing that, I would expect there would be suggestions for
> changes in the API, additions to the API, naming changes to
> be more clear from a non-implementer POV, etc...
> 
> By putting it in immediately before a release, the original
> API can't be broken, class names can't be changed, all would
> need to be deprecated, etc...
> 
> The other issue I have with the current CP code that I have
> read is the number of new classes introduced into existing
> core packages (especially clent).  Looking at some of
> their names, they are generic sounding and it's not clear to
> me without digging in that they are part of
> coprocessors.  Is it possible to move CP stuff into
> client.cp packages and the like?  Or prefix with CoProc
> or some way to keep this stuff separated?
> 
> I apologize for dropping this on you now and if no one else
> feels the same, I am not going to spoil the party.
> 
> But is it critical that this gets into 0.90 and into a
> release now?  Could we wait for 0.92 and get this
> committed in a couple weeks and allowed to mature a bit on
> trunk before it's released?
> 
> JG 
> 
> > -----Original Message-----
> > From: Andrew Purtell [mailto:apurtell@apache.org]
> > Sent: Tuesday, October 05, 2010 7:14 PM
> > To: dev@hbase.apache.org
> > Subject: dynamic RPC and coprocessor changes
> > 
> > We've been nursing dynamic RPC and coprocessor changes
> for a couple of
> > weeks now and don't see any failures beyond what are
> already on trunk
> > with them applied.
> > 
> > I was going to apply them tonight but will wait until
> tomorrow given
> > that trunk is already disrupted a little.
> > 
> > Best regards,
> > 
> >     - Andy
> > 
> > 
> > 
> > 
> 
> 


      

RE: dynamic RPC and coprocessor changes

[Jonathan Gray <jg...@facebook.com>]

Committing this stuff onto trunk the day before a feature freeze and as we move towards stability gives me a little bit of the fear.

I completely understand that it's been worked on for quite some time and think this stuff is awesome.  But I still wish I had more time to give it further review and to actually take this stuff for a test spin.  Right now that's just not possible with all the work to be done stabilizing and testing trunk (and I think time is best spent right now stabilizing the master/rs versus new features).

Personally, I have a bunch of fairly sweeping compaction, flush, and split changes that have been partially reviewed but I haven't had the time to push them over the finish line.  I hope to get them in immediately after an 0.90 branch is cut and trunk becomes 0.92.  This should be rather soon.  I'd like to see 0.92 get released in short order after 0.90 as there are lots of changes that just have not made it into 0.90 yet.  So even if we waited to commit, we could work hard towards the next major release (I don't think there are any major rewrites planned)  :)

With this kind of big change and addition of new APIs, my preference would be to have it committed early in a trunk cycle (versus immediately before a release is cut).  That way, we can play with it ourselves, see how it works, try out some of our own ideas for usage of CPs, etc... In doing that, I would expect there would be suggestions for changes in the API, additions to the API, naming changes to be more clear from a non-implementer POV, etc...

By putting it in immediately before a release, the original API can't be broken, class names can't be changed, all would need to be deprecated, etc...

The other issue I have with the current CP code that I have read is the number of new classes introduced into existing core packages (especially clent).  Looking at some of their names, they are generic sounding and it's not clear to me without digging in that they are part of coprocessors.  Is it possible to move CP stuff into client.cp packages and the like?  Or prefix with CoProc or some way to keep this stuff separated?

I apologize for dropping this on you now and if no one else feels the same, I am not going to spoil the party.

But is it critical that this gets into 0.90 and into a release now?  Could we wait for 0.92 and get this committed in a couple weeks and allowed to mature a bit on trunk before it's released?

JG 

> -----Original Message-----
> From: Andrew Purtell [mailto:apurtell@apache.org]
> Sent: Tuesday, October 05, 2010 7:14 PM
> To: dev@hbase.apache.org
> Subject: dynamic RPC and coprocessor changes
> 
> We've been nursing dynamic RPC and coprocessor changes for a couple of
> weeks now and don't see any failures beyond what are already on trunk
> with them applied.
> 
> I was going to apply them tonight but will wait until tomorrow given
> that trunk is already disrupted a little.
> 
> Best regards,
> 
>     - Andy
> 
> 
> 
>