Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Thu, 12 Oct 2017 22:45:01 +0000 (UTC)
From: "stack (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.12748181.1413332836000.45729.1507848301219@Atlassian.JIRA>
In-Reply-To: <JIRA.12748181.1413332836000@Atlassian.JIRA>
References: <JIRA.12748181.1413332836000@Atlassian.JIRA> <JIRA.12748181.1413332836154@jira-lw-us.apache.org>
Subject: [jira] [Commented] (HBASE-12260) MasterServices needs a
 short-back-and-sides; pare-back exposure of internals and IA.Private
 classes
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Thu, 12 Oct 2017 23:03:05 -0000


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

stack commented on HBASE-12260:
-------------------------------

On TODOs:
 * Schedule and wait on flush/compaction
 ** This is RegionServer-side, not Master-side. Can schedule Flush or Compaction via Admin on Master side but no means for blocking (AsyncAdmin returns a CompletableFuture but it too is just a request; it does not have the future wait on completion of compaction).
 * Creating system tables (Done via Admin. Testing)
 ** Only Master process can make system tables (while at it, only Master can write hbase:meta). TODO. Tried but the RpcService is unreliable and we want to check that the request comes from same process, not just same IP.
 * Review of RSGroups to see what functionality need to add back into MasterServices
 ** This is blocked on RSGroup work. Will require more exposure I think but already the RSGroup fixup has removed need of our exposing table locks. Thats a big help.
 * Metrics/by-pass
 ** TODO: if bypass is selective and we can update metrics even on bypass, then we won't have to let out metrics.

So, three follow-ons: only master can make system tables, do we have to expose more functionality for CPs (see what RSGroup needs when done), and do bypass to see if we need to let out metrics or not.

> 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
>
>
> 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)