Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 883FB200CD9 for ; Thu, 3 Aug 2017 20:25:04 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id 86BA316C37C; Thu, 3 Aug 2017 18:25:04 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id CD15916C377 for ; Thu, 3 Aug 2017 20:25:03 +0200 (CEST) Received: (qmail 88102 invoked by uid 500); 3 Aug 2017 18:25:02 -0000 Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list issues@hbase.apache.org Received: (qmail 88091 invoked by uid 99); 3 Aug 2017 18:25:02 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 03 Aug 2017 18:25:02 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id 7CDEEC0286 for ; Thu, 3 Aug 2017 18:25:02 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -99.202 X-Spam-Level: X-Spam-Status: No, score=-99.202 tagged_above=-999 required=6.31 tests=[KAM_ASCII_DIVIDERS=0.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=disabled Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id GBZyjNM_thEp for ; Thu, 3 Aug 2017 18:25:01 +0000 (UTC) Received: from mailrelay1-us-west.apache.org (mailrelay1-us-west.apache.org [209.188.14.139]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTP id 680815F6C3 for ; Thu, 3 Aug 2017 18:25:01 +0000 (UTC) Received: from jira-lw-us.apache.org (unknown [207.244.88.139]) by mailrelay1-us-west.apache.org (ASF Mail Server at mailrelay1-us-west.apache.org) with ESMTP id E4D78E0D45 for ; Thu, 3 Aug 2017 18:25:00 +0000 (UTC) Received: from jira-lw-us.apache.org (localhost [127.0.0.1]) by jira-lw-us.apache.org (ASF Mail Server at jira-lw-us.apache.org) with ESMTP id 31EA224652 for ; Thu, 3 Aug 2017 18:25:00 +0000 (UTC) Date: Thu, 3 Aug 2017 18:25:00 +0000 (UTC) From: "Appy (JIRA)" To: issues@hbase.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (HBASE-18231) Deprecate and throw unsupported operation when Admin#closeRegion is called. MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 archived-at: Thu, 03 Aug 2017 18:25:04 -0000 [ https://issues.apache.org/jira/browse/HBASE-18231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16113234#comment-16113234 ] Appy commented on HBASE-18231: ------------------------------ That'll break user clients. From the "hbase 2.0 compatibility expectations" thread: bq. An hbase1 client can run against an hbase2 cluster but it will only be able to do DML (Get/Put/Scan, etc.). We do not allow being able to do admin ops using an hbase1 Admin client against an hbase2 cluster. So we certainly don't have to worry about compat, but am not sure what's the accepted way to fail. Is it fine to just remove the methods, because then the clients might crash? [~stack] > Deprecate and throw unsupported operation when Admin#closeRegion is called. > --------------------------------------------------------------------------- > > Key: HBASE-18231 > URL: https://issues.apache.org/jira/browse/HBASE-18231 > Project: HBase > Issue Type: Sub-task > Components: Admin > Affects Versions: 2.0.0 > Reporter: stack > Assignee: Appy > Priority: Critical > Fix For: 2.0.0, 3.0.0 > > Attachments: HBASE-18231.master.001.patch, HBASE-18231.master.002.patch, HBASE-18231.master.003.patch > > > [~uagashe] tripped over this today. Admin#closeRegion which we used to use in branch-1 will cause damage in AMv2 cluster. Instead you need to call unassign -- i.e. all cluster ops must go via the Master; no more going direct to RegionServer closing regions behind the Master's back. > Review all Admin ops to see what else skirts Master and deprecate and throw unsupported if called. -- This message was sent by Atlassian JIRA (v6.4.14#64029)