[
https://issues.apache.org/jira/browse/HBASE-12260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16203820#comment-16203820
]
stack commented on HBASE-12260:
-------------------------------
First, thanks for the great review [~appy] up on rb. Looking forward to going
through it.
On Mocks vs MasterServices vs RegionServerServices vs
CoprocessRegionServerServices, please see the email on dev list:
http://apache-hbase.679495.n3.nabble.com/Looking-for-input-on-an-alpha-4-thorny-item-td4090953.html.
In synopsis, MasterServices and RegionServerServices have been corrupted and,
among other failings, have become a Coprocessor conduit to our internals that
needs to be shutdown for hbase2 (more background on this below). In this issue,
MS is for CPs only (IA.LP). I write this in the class comment. I then refactor
away any other use of MS putting in place HMaster impl in its stead. Meantime,
Anoop has been on a similar project on the RS side. There he puts in place a
new Interface CPRSS for CPs and RSS continues (though below I argue this
problematic).
Some background. MS and RSS started out as severe subsets of HMaster and
HRegionServer function -- just enough to satisfy 80% need -- and could be
plugged in in a mock form making it so we didn't have to bring up full servers
in tests making them less resource intensive. This was their original intent (I
think I did this).
Over time, lazily, internally, we put in place the Interfaces in place of the
implementations starting up Services and Chores. We also allowed CPs access to
the Interfaces. As we worked on internals, if we needed a facility in an
awkward corner, no problem, just add the needed function to RSS and MS. As time
passed, RSS and MS bulked up because of internal needs. Each time we added to
the Interface, CPs got access such that now, CPs can access all critical
internals via *Service.
How to proceed? Here, I take the radical route of purging the failed Interface
project. Anoop over in the RS side, first wanted to add an 'internal' RSS and
expose a subset to CPs. In review I thought that too ugly
(HRegionServer+RSS+InternalRSS) and didn't think we'd be able to keep it
straight going forward (where should I expose this new method?). Now, after
feedback he has a CPRSS that is dedicated to CPs exclusively. I considered this
a mess in a fashion similar to the HRS+RSS+IRSS noted above and it did not
align w/ the radical retrofit done here.
Options for CPs:
* Give the Interfaces over to CP totally and purge their internal use (as done
here) echoing what we did to the Region+Store Interfaces.
* Introduce YAI (Yet-Another-Interface) either:
** as a cutdown subset of current RSS; the new Interface would assume the RSS
name. Internally we'd have a new more featureful Interface named InternalRSS or
some such (why not just use HRS in this case?)
** Or we build a dedicated Interface for CP usage only giving it the (ugly?)
name of CPRSS so no confusion around who the audience is.
For the latter, we'd still have a cleanup job to do around when HRS and when
use the Interface instead.
Lets figure this out quick so we can cut an alpha4. The CP API is dependent on
this decision. In fact, let me surface this on the dev list.
> MasterServices needs a short-back-and-sides; pare-back exposure of internals
> and IA.Private classes
> ---------------------------------------------------------------------------------------------------
>
> 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,
> HBASE-12260.master.002.patch, HBASE-12260.master.003.patch,
> HBASE-12260.master.004.patch, HBASE-12260.master.005.patch,
> HBASE-12260.master.006.patch, HBASE-12260.master.007.patch,
> HBASE-12260.master.008.patch, HBASE-12260.master.009.patch,
> HBASE-12260.master.010.patch, HBASE-12260.master.011.patch,
> HBASE-12260.master.011.patch, HBASE-12260.master.012.patch,
> HBASE-12260.master.013.patch, HBASE-12260.master.014.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)
