Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Thu, 9 Jun 2016 05:16:21 +0000 (UTC)
From: "Matteo Bertozzi (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.12955424.1459547820000.36008.1465449381053@Atlassian.JIRA>
In-Reply-To: <JIRA.12955424.1459547820000@Atlassian.JIRA>
References: <JIRA.12955424.1459547820000@Atlassian.JIRA> <JIRA.12955424.1459547820146@arcas>
Subject: [jira] [Commented] (HBASE-15584) Revisit handling of
 BackupState#CANCELLED
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Thu, 09 Jun 2016 05:16:23 -0000


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

Matteo Bertozzi commented on HBASE-15584:
-----------------------------------------

I don't see an answer to my question about why we need two system that do the same thing and what is the advantage of the backupId over the procId alone. 

if you just want to add an api that does abort(backupId) why the abort(procId) is not enough? how do you find your backupId to pass to the abort()? is there any information/helper that we can add to the listProcedures() that is currently missing? how the user will find which is the backupId that he wants to abort? I guess it will be similar to listProcedures().

can you provide an example with step by step operations that the user will do to abort the backup? are they different from my comment above (20 may)? I still don't have clear picture of what is the advantage/difference of the backupId, so I can't help much at the moment.

> Revisit handling of BackupState#CANCELLED
> -----------------------------------------
>
>                 Key: HBASE-15584
>                 URL: https://issues.apache.org/jira/browse/HBASE-15584
>             Project: HBase
>          Issue Type: Sub-task
>            Reporter: Ted Yu
>            Priority: Minor
>
> During review of HBASE-15411, Enis made the following point:
> {code}
> nobody puts the backup in cancelled state. setCancelled() is not used. So if I abort a backup, who writes to the system table the new state? 
> Not sure whether this is a phase 1 patch issue or due to this patch. We can open a new jira and address it there if you do not want to do it in this patch. 
> Also maybe this should be named ABORTED rather than CANCELLED.
> {code}
> This issue is to decide whether this state should be kept (e.g. through notification from procedure V2 framework in response to abortion).
> If it is to be kept, the state should be renamed ABORTED.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)