[
https://issues.apache.org/jira/browse/HBASE-20682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16506492#comment-16506492
]
stack commented on HBASE-20682:
-------------------------------
bq. The new procedure could still be constructed with an unassign followed by
an assign. What do you folks think?
I'll work on it. We'll need unassign then assign to support old 2.0.0 RSs.
Later we could do an optimization where we add a 'reopen' flag to unassign. If
RS supports this op, it could return true if it succeeded in reopening the
region and we could skip the subsequent assign... but this would be an
optimizattion. For later...
> MoveProcedure can be subtask of
> ModifyTableProcedure/ReopenTableRegionsProcedure; ensure all kosher.
> ----------------------------------------------------------------------------------------------------
>
> Key: HBASE-20682
> URL: https://issues.apache.org/jira/browse/HBASE-20682
> Project: HBase
> Issue Type: Sub-task
> Components: amv2
> Reporter: stack
> Assignee: stack
> Priority: Critical
> Fix For: 2.0.1
>
>
> MoveProcedure is used in at least two places as a means of 'reopening' a
> region after a config has changed. This issue is about review of MP so this
> usage is first-class (and that MP is good procedure citizen running as a
> subprocedure. In question is what should happen if the source server or the
> target servers are offline when we go to run. As of the parent issue, we'll
> skip to the end. Should we instead go ahead with the move (internally, if we
> are asked to assign to an offline server, we'll pick another -- do same for
> unassign? Would help in this reopen use case).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
