hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Purtell <apurt...@apache.org>
Subject Re: On coprocessor API evolution
Date Sat, 17 May 2014 03:48:45 GMT
Thanks Vladimir, I added your points to the discussion on HBASE-11125.


On Sat, May 17, 2014 at 1:59 AM, Vladimir Rodionov
<vladrodionov@gmail.com>wrote:

> 1) Have default implementations (abstract classes) for every interface from
> Coprocessor API.
> 2) Advise coprocessor users not to implement interface directly but sub
> class default impl.
> 3) Preserve backward compatibility by adding only new hooks/methods
> 4) DO NOT CHANGE existing API (no method renaming, method parameter type
> changes etc)
> 5) Have a regression tests to check backward compatibility.
>
> -Vladimir
>
>
>
> On Fri, May 16, 2014 at 9:13 AM, Michael Segel <michael_segel@hotmail.com
> >wrote:
>
> > Until you move the coprocessor out of the RS space and into its own
> > sandbox… saying security and coprocessor in the same sentence is a joke.
> > Oh wait… you were serious… :-(
> >
> > I’d say there’s a significant rethink on coprocessors that’s required.
> >
> > Anyone running a secure (kerberos) cluster, will want to allow system
> > coprocessors but then write a coprocessor that reject user coprocessors.
> >
> > Just putting it out there…
> >
> > On May 15, 2014, at 2:13 AM, Andrew Purtell <apurtell@apache.org> wrote:
> >
> > > Because coprocessor APIs are so tightly bound with internals, if we
> apply
> > > suggested rules like as mentioned on HBASE-11054:
> > >
> > >      I'd say policy should be no changes to method apis across minor
> > > versions
> > >
> > > This will lock coprocessor based components to the limitations of the
> API
> > > as we encounter them. Core code does not suffer this limitation, we are
> > > otherwise free to refactor and change internal methods. For example, if
> > we
> > > apply this policy to the 0.98 branch, then we will have to abandon
> > further
> > > security feature development there and move to trunk only. This is
> > because
> > > we already are aware that coprocessor APIs as they stand are
> insufficient
> > > still.
> > >
> > > Coprocessor APIs are a special class of internal method. We have had a
> > > tension between allowing freedom of movement for developing them out
> and
> > > providing some measure of stability for implementors for a while.
> > >
> > > It is my belief that the way forward is something like HBASE-11125.
> > Perhaps
> > > we can take this discussion to that JIRA and have this long overdue
> > > conversation.
> > >
> > > Regarding security features specifically, I would also like to call
> your
> > > attention to HBASE-11127. I think security has been an optional feature
> > > long enough, it is becoming a core requirement for the project, so
> should
> > > be moved into core. Sure, we can therefore sidestep any issues with
> > > coprocessor API sufficiency for hosting security features. However, in
> my
> > > opinion we should pursue both HBASE-11125 and HBASE-11127; the first to
> > > provide the relative stability long asked for by coprocessor API users,
> > the
> > > latter to cleanly solve emerging issues with concurrency and
> versioning.
> > >
> > >
> > > --
> > > Best regards,
> > >
> > >   - Andy
> > >
> > > Problems worthy of attack prove their worth by hitting back. - Piet
> Hein
> > > (via Tom White)
> >
> >
>



-- 
Best regards,

   - Andy

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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message