hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Purtell (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-12260) MasterServices - remove from coprocessor API (Discuss)
Date Wed, 04 Oct 2017 21:41:00 GMT

    [ https://issues.apache.org/jira/browse/HBASE-12260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16192083#comment-16192083

Andrew Purtell commented on HBASE-12260:

I have seen now in several places that the only consideration for providing or keeping an
interface is if Phoenix or the Timeline Server use it. I think it is fair to ask what is the
consequence of removing these interfaces in terms of what state or behavior *any potential
coprocessor use case* can access or influence. 

The security coprocessors use MasterServices to create their state tables, e.g. in AccessControlLists:

static void createACLTable(MasterServices master) {

Possibly use of the normal admin API would work. Making admin API requests from an embedded
client in the coprocessor might be fine for the majority of reasonable things someone would
want to do with access to master functions from MasterServices. The proposed change eliminates
direct access to AssignmentManager, ProcedureManager, MasterWalManager, ServerManager, SnapshotManager,
TableStateManager, MasterQuotaManager, RegionNormalizer, CatalogJanitor,  and the master's
executor service. There won't be admin API replacements for all of the things one could do
with direct access. It may be fine then to wait until someone writes in with a "I can't do
X with a MasterObserver" type problem, but I'd like to ask we take a quick look at these things
and see if something is worth keeping. 

There is also the same issue I mentioned on the issue for Region interface changes, loss of
access to MasterMetrics. This is a valid user facing interface for coprocessors to manipulate,
just like they are allowed to manipulate user-facing RPC interface functionality and results.
We talked in the context of that JIRA of eliminating the bypass semantic. In that case, functionality
can't be overridden and replaced, only enhanced. So loss of access to system metrics is fine.
If coprocessors can only mix in new functionality they can expose their own custom metrics.
Same considerations apply here.

> MasterServices - remove from coprocessor API (Discuss)
> ------------------------------------------------------
>                 Key: HBASE-12260
>                 URL: https://issues.apache.org/jira/browse/HBASE-12260
>             Project: HBase
>          Issue Type: Sub-task
>          Components: master
>            Reporter: ryan rawson
>            Assignee: stack
>            Priority: Critical
>             Fix For: 2.0.0-alpha-4
>         Attachments: HBASE-12260.master.001.patch
> A major issue with MasterServices is the MasterCoprocessorEnvironment exposes this class
even though MasterServices is tagged with @InterfaceAudience.Private
> This means that the entire internals of the HMaster is essentially part of the coprocessor
API.  Many of the classes returned by the MasterServices API are highly internal, extremely
powerful, and subject to constant change.  
> Perhaps a new API to replace MasterServices that is use-case focused, and justified based
on real world co-processors would suit things better.

This message was sent by Atlassian JIRA

View raw message