region vs regionserver coprocessors

[Matteo Bertozzi <th...@gmail.com>]

Looking at the coprocessor load code, and at the documentation...
I've noticed that coprocessors like AccessController, TokenProvider, ...
are region coprocessors.

This means that for each region there's a new instance of TokenProvider,
AccessController, ...

Is there a reason to not have them as RegionServer coprocessors (loaded
only once per RS)?

also the HRegionServer.getCoprocessors() seems to not print the
regionserver coprocessors but just the hlog + region coprocessors.

Matteo

Re: region vs regionserver coprocessors

[Gary Helmling <gh...@gmail.com>]

Looking at RegionServerObserver, it only defines a single method --
preStopRegionServer().  AccessController mediates access on all normal
client operations on data, which happen on regions and are only represented
in RegionObserver.  So what it sounds like you're asking is if
RegionServerObserver should duplicate in some form pre/post hooks for the
operations already represented in RegionObserver?  I think there are a
couple of problems with this approach:

* confusion in the API through duplicate representation of operations at
multiple layers
* both AccessController and TokenProvider function as endpoints and
coprocessor RPC is only supported against RegionObservers (at the moment)

An alternate approach would be to implement AccessController as something
like an RPC filter at the RPC server layer.  This would again allow loading
only a single instance per server, but you lose a lot of context in the
execution of each operation that allows AccessController to make access
control decisions (things like for wildcard gets or scans the set of
defined column families is filled in).  Without the full execution context,
I think you wind up doing a lot more work in AccessController and lose some
flexibility in the future.

Not everything is loaded for every region either.  The cached
AccessControlLists set of ACLs is shared per-regionserver in a singleton.
 I can see the draw of only having a single AccessController per server,
but I think the current design has actually worked out well.

The fact that RegionServerObservers are not represented in
HRegionServer.getCoprocessors() seems like a bug that was missed when they
were added.


On Tue, May 14, 2013 at 7:13 PM, Matteo Bertozzi <th...@gmail.com>wrote:

> Looking at the coprocessor load code, and at the documentation...
> I've noticed that coprocessors like AccessController, TokenProvider, ...
> are region coprocessors.
>
> This means that for each region there's a new instance of TokenProvider,
> AccessController, ...
>
> Is there a reason to not have them as RegionServer coprocessors (loaded
> only once per RS)?
>
> also the HRegionServer.getCoprocessors() seems to not print the
> regionserver coprocessors but just the hlog + region coprocessors.
>
> Matteo
>

Re: region vs regionserver coprocessors

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

I think as a design exercise, if someone has that kind of bandwidth, this
could be fun. We wouldn't want to duplicate the region level API at the
regionserver level, that will make it interesting. However, like Gary said
in his response, the reason it is not done so now for the AccessController
is because much (most) context for making an access control decision is at
the region level.

For TokenProvider, it could make sense to have only one per RS, however it
is an Endpoint based service and currently only region coprocessors can be
endpoints. Plumbing endpoint invocations to regionserver level observers
and reimplementing TokenProvider as an endpoint service there sounds like a
clean subset of the work to try out.

On Wed, May 15, 2013 at 10:13 AM, Matteo Bertozzi
<th...@gmail.com>wrote:

> Is there a reason to not have them as RegionServer coprocessors (loaded
> only once per RS)?
>




-- 
Best regards,

   - Andy

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