[
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:
{code}
static void createACLTable(MasterServices master) {
...
master.createSystemTable(ACL_TABLEDESC);
}
{code}
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
(v6.4.14#64029)
